Bug#843425: Fwd: Bug#843425: blender doesn't optimize for amd64 defaults
Hi again, and sorry for too much noise..
I've checked the compiler output of i386 build of blender from [1] and
there's such status print:
-- SSE and SSE2 optimizations are DISABLED!
Meaning, there's no SSE/SSE2 global optimization of i386 builds of
Blender in Debian already (thanks to Matteo i guess :)
Is there anything else here to be solved?
[1] https://buildd.debian.org/status/package.php?p=blender
On Mon, Nov 7, 2016 at 10:52 AM, Sergey Sharybin wrote:
> Ah, it's Pemtium 4 where SSE2 first arrived, for a moment thought it's
> Pentium Pro. My bad..
>
> So for both i386 and i686 SSE2 requirement is not valid.
>
> Currently in Blender upstream we detect SSE/SSE2 flags based on
> current CPU. Meaning, if you're builing on i686 CPU Blender should
> already have global SSE2 optimization disabled. If CPU on the builder
> machine supports SSE2 we can still force SSE/SSE2 optimization to be
> off by passing `-DSUPPORT_SSE_BUILD=OFF -DSUPPORT_SSE2_BUILD=OFF` to
> CMake.
>
> On Mon, Nov 7, 2016 at 10:40 AM, Matthias Klose wrote:
>> On 07.11.2016 10:32, Sergey Sharybin wrote:
>>> Hi,
>>>
>>> Afraid the reply to #843425 was only delivered to the BTS and not easily
>>> visible to you guys.
>>>
>>> Here's the full reply, same as [1]. Just so you know :)
>>>
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843425#10
>>>
>>>
>>> -- Forwarded message --
>>> From: Sergey Sharybin
>>> Date: Mon, Nov 7, 2016 at 9:50 AM
>>> Subject: Bug#843425: blender doesn't optimize for amd64 defaults
>>> To: 843...@bugs.debian.org
>>>
>>>
>>> Hi,
>>>
>>> From the report it's not fully clear what parts Blender those CFLAGS
>>> are referencing to, but because it's all within a context of #843379 i
>>> would guess we are talking about Cycles kernel here (Cycles is the
>>> render engine we use in Blender).
>>>
>>> In this case you're partially correct: we are mainly ignoring default
>>> CFLAGS but we compile 6 different CPU kernels, optimized for various
>>> microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
>>> SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
>>> current CPU microarchitecture and invoke kernel with highest
>>> capabilities allowed on the current processor.
>>>
>>> This is the only way we can guarantee optimal render times on amd64.
>>> Keep in mind, AVX2 can render similar scene like 2x faster than simple
>>> SSE2. This is something we can not ignore for our users.
>>
>> well, the GCC issue was opened with a RC severity, so I assumed that
>> everything
>> was built using these flags. The assumption of amd64 having SSE2 enabled by
>> defaults is valid.
>>
>>> That being said, if you have some tricky setup where we do not detect
>>> capabilities correctly and Cycles tries to use unsupported kernel and
>>> runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
>>> that from our end.
>>>
>>> Now, about forcing microarchitecture in rest of Blender. We do require
>>> SSE2 on amd64 and i686, but that should be all fine as far as i know
>>> (amd64 always have SSE2, 32bit builds will disable SSE2 automatically
>>> if current CPU does not support it).
>>
>> For Debian it is not ok to assume SSE2 on the i386 architecture.
>>
>> Matthias
>>
>
> --
> With best regards, Sergey Sharybin
--
With best regards, Sergey Sharybin
Bug#843425: Fwd: Bug#843425: blender doesn't optimize for amd64 defaults
Ah, it's Pemtium 4 where SSE2 first arrived, for a moment thought it's
Pentium Pro. My bad..
So for both i386 and i686 SSE2 requirement is not valid.
Currently in Blender upstream we detect SSE/SSE2 flags based on
current CPU. Meaning, if you're builing on i686 CPU Blender should
already have global SSE2 optimization disabled. If CPU on the builder
machine supports SSE2 we can still force SSE/SSE2 optimization to be
off by passing `-DSUPPORT_SSE_BUILD=OFF -DSUPPORT_SSE2_BUILD=OFF` to
CMake.
On Mon, Nov 7, 2016 at 10:40 AM, Matthias Klose wrote:
> On 07.11.2016 10:32, Sergey Sharybin wrote:
>> Hi,
>>
>> Afraid the reply to #843425 was only delivered to the BTS and not easily
>> visible to you guys.
>>
>> Here's the full reply, same as [1]. Just so you know :)
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843425#10
>>
>>
>> -- Forwarded message --
>> From: Sergey Sharybin
>> Date: Mon, Nov 7, 2016 at 9:50 AM
>> Subject: Bug#843425: blender doesn't optimize for amd64 defaults
>> To: 843...@bugs.debian.org
>>
>>
>> Hi,
>>
>> From the report it's not fully clear what parts Blender those CFLAGS
>> are referencing to, but because it's all within a context of #843379 i
>> would guess we are talking about Cycles kernel here (Cycles is the
>> render engine we use in Blender).
>>
>> In this case you're partially correct: we are mainly ignoring default
>> CFLAGS but we compile 6 different CPU kernels, optimized for various
>> microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
>> SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
>> current CPU microarchitecture and invoke kernel with highest
>> capabilities allowed on the current processor.
>>
>> This is the only way we can guarantee optimal render times on amd64.
>> Keep in mind, AVX2 can render similar scene like 2x faster than simple
>> SSE2. This is something we can not ignore for our users.
>
> well, the GCC issue was opened with a RC severity, so I assumed that
> everything
> was built using these flags. The assumption of amd64 having SSE2 enabled by
> defaults is valid.
>
>> That being said, if you have some tricky setup where we do not detect
>> capabilities correctly and Cycles tries to use unsupported kernel and
>> runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
>> that from our end.
>>
>> Now, about forcing microarchitecture in rest of Blender. We do require
>> SSE2 on amd64 and i686, but that should be all fine as far as i know
>> (amd64 always have SSE2, 32bit builds will disable SSE2 automatically
>> if current CPU does not support it).
>
> For Debian it is not ok to assume SSE2 on the i386 architecture.
>
> Matthias
>
--
With best regards, Sergey Sharybin
Bug#843425: blender doesn't optimize for amd64 defaults
Hi,
>From the report it's not fully clear what parts Blender those CFLAGS
are referencing to, but because it's all within a context of #843379 i
would guess we are talking about Cycles kernel here (Cycles is the
render engine we use in Blender).
In this case you're partially correct: we are mainly ignoring default
CFLAGS but we compile 6 different CPU kernels, optimized for various
microarchitectures ("native" - no SSE2 on i686 / SSE2 on amd64, forced
SSE2, SSE3, SSE4.1, AVX and AVX2). Then during runtime we detect
current CPU microarchitecture and invoke kernel with highest
capabilities allowed on the current processor.
This is the only way we can guarantee optimal render times on amd64.
Keep in mind, AVX2 can render similar scene like 2x faster than simple
SSE2. This is something we can not ignore for our users.
That being said, if you have some tricky setup where we do not detect
capabilities correctly and Cycles tries to use unsupported kernel and
runs into ILLEGAL INSTRUCTION i'll be happy to look into and solve
that from our end.
Now, about forcing microarchitecture in rest of Blender. We do require
SSE2 on amd64 and i686, but that should be all fine as far as i know
(amd64 always have SSE2, 32bit builds will disable SSE2 automatically
if current CPU does not support it).
--
With best regards, Sergey Sharybin
Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures
Ok, looked through logs. Commited fix (rev43718 in our svn trunk) which should make some platforms work nicer (at least fix currently reported compilation errors). This should help on spark, s390x, s390, mips platforms. Still can see some issues related on REG_EIP and mcontext_t things. Not sure if that build errors happens with 0011-fix_FTBFS_with_libmv applied? Also think error of hurd-i386 should be fixed. At least this function has got valid return value in current trunk. Probably compilation error on powerpc is also fixed in svn rev43719. Would be nice to check for updated build logs after all this my changes. -- With best regards, Sergey Sharybin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures
Hi again, Commited patch to support more platforms to our trunk (http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43716) Hope it'll help make more users and platform maintainers happier, thanks to Kevin for it. I don't have sparc platform at all, so seeing error log would help a lot. Maybe build errors from build servers can be browsed by external users? On Thu, Jan 26, 2012 at 2:31 PM, Matteo F. Vescovi wrote: > > Hi! > > > On 25/01/2012 21:05, Kevin Roy wrote: >> >> As far as I and others have tested the patch, builds are now ok on ARM >> and KFreeBSD. I'm not sure on others but debian buildd servers will tell >> us :) . > > > It builds fine even on ia64... it has been tested last night. > But actually it doesn't build on sparc machines :-( > > Let's see how the buildd-situation evolves. > > Cheers. > > -- > Matteo F. Vescovi > Debian Sponsored Maintainer > e-mail: mfv.deb...@gmail.com > GnuPG KeyID: 83B2CF7A -- With best regards, Sergey Sharybin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures
Hi, Good patch, don't think mine is needed to be added (the same changes are already made). Don't have access to non-i386/amd64 machines, but 0011-fix_FTBFS_with_libmv.patch looks fine and if it's indeed resolves build issues i would be happy to commit it to blender's trunk. On Wed, Jan 25, 2012 at 11:40 PM, Kevin Roy wrote: > I think the patch 0011-fix_FTBFS_with_libmv [1] in git will cover > configs other than i386/amd64 but in doubt, could you look at it and > tell me if yours is need to be added? -- With best regards, Sergey Sharybin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654428: blender: FTBFS: uses i386/amd64 specific register definitions on all architectures
Hi, We've got quite the same error with FreeBSD support. Attached patch should fix this issue. If it will still fail, would be helpful to have config.h generated by configure script of glog itself (which can be found here http://code.google.com/p/google-glog/). But if proposed patch will work fine, it can be commited to trunk. -- With best regards, Sergey Sharybin Index: extern/libmv/third_party/glog/src/config_linux.h === --- extern/libmv/third_party/glog/src/config_linux.h (revision 43691) +++ extern/libmv/third_party/glog/src/config_linux.h (working copy) @@ -133,6 +133,8 @@ /* How to access the PC from a struct ucontext */ #if defined(_M_X64) || defined(__amd64__) || defined(__x86_64__) #define PC_FROM_UCONTEXT uc_mcontext.gregs[REG_RIP] +#elif defined(IA64) + #undef PC_FROM_UCONTEXT #else #define PC_FROM_UCONTEXT uc_mcontext.gregs[REG_EIP] #endif
