Hi,
We've spent quite a while trying to solve the upcoming stream of reports
about high CPU usage with builds made with msvs2013 in certain situations.
Root of the issue goes to the change made to OMP inplementation back to
msvc2010 days -- they've forced threads to spin for a while after they did
On Wed, Aug 6, 2014 at 1:23 AM, Sergey Sharybin
wrote:
> We've spent quite a while trying to solve the upcoming stream of reports
> about high CPU usage with builds made with msvs2013 in certain situations.
> Root of the issue goes to the change made to OMP inplementation back to
> msvc2010 days
Inlined some answers,
On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh wrote:
> Here's the list of possible solutions:
> >
> > - Declare msvc full of crap, switch to intel compilers
> >
>
> MinGW still won't do everything, huh? ;)
>
For my knowledge MinGW is still not really ready for production
On Wed, Aug 6, 2014 at 6:23 PM, Sergey Sharybin wrote:
> Hi,
>
> We've spent quite a while trying to solve the upcoming stream of reports
> about high CPU usage with builds made with msvs2013 in certain situations.
> Root of the issue goes to the change made to OMP inplementation back to
> msvc201
Hi Campbell,
I last compiled with intel c++ a few month's ago and without OSL / Collada.
In general it works but as with any change it will again probably expose
lots of little issues once people actually use builds intensively.
Main issue is the compiler is not free to use for windows not even f
Switching to icc wouldn't happen any time soon anyway, so afraid we'll need
to have some shorter-term solution anyway... The question only is what
exactly we'll choose.
P.S. And yeah, there's nothing more permanent as a temporary solution..
On Wed, Aug 6, 2014 at 4:48 PM, Martijn Berger
wrote:
We could also choose to drop OMP in our code (not all at once, but
gradually replacing it with real threading), since it’s also a pile of
crap on OSX currently afaik?
Assuming our BLI_task 'lib' is ready for massive use (iirc Martijn
already had that in mind)…
Or is there some serious issues w
Excellent plan Bastien.
From a semantic standpoint combining different threading strategies and or
support libraries within one project is really far from ideal.
For this to work we would need to write some kind of document or declare
some already implemented part of code "the official way" to do t
Theres been some issues with OpenMP, but am wary of kicking out entire
technology just because we can't set an environment variable? (ok, of
course theres more to it - but seems a weak reasoning still).
Regarding OSX - Clang is preparing to use OpenMP from Intel, so
situation on OSX likely improve
On Wed, Aug 6, 2014 at 5:55 PM, Campbell Barton
wrote:
> Theres been some issues with OpenMP, but am wary of kicking out entire
> technology just because we can't set an environment variable? (ok, of
> course theres more to it - but seems a weak reasoning still).
>
I would not want that to be th
On Wed, Aug 6, 2014 at 2:44 AM, Sergey Sharybin
wrote:
> On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh
> wrote:
>
> > > - Try to hack into vcomp120.dll, trying to figure out the variable,
> > linking
> > > to it and modifying if (so called brain surgery from the blender side).
> > No
> > > id
On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh wrote:
> It's not ideal, and would be coded to each specific vcompXXX.dll (and
> patched/updated versions).
>
> However, assuming the location of that flag is a fixed offset from the dll
> image, the general idea might be:
>
> - Call GetModuleHandle
On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger
wrote:
> On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh
> wrote:
>
> > It's not ideal, and would be coded to each specific vcompXXX.dll (and
> > patched/updated versions).
> >
> > However, assuming the location of that flag is a fixed offset from th
On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger
wrote:
> Main problem is that someone needs to actually try this by implementing it
> :)
For the pre-patch fix, the byte at offset 0x000169A0 in the 32-bit
vcomp120.dll (assuming the same one in 2.71) should be changed to 0x00 (the
'bool' for acti
I'm not that huge fan of modifying dll, because it could backfare for those
who builds blender themselves. But if windows folks are fine with this --
so be it.
Now, addressing Campbell's concern about OpenMP. That's actually a separate
topic, but the point is -- we simply should get rid of openmp
On Thu, Aug 7, 2014 at 9:27 AM, Sergey Sharybin
wrote:
> I'm not that huge fan of modifying dll, because it could backfare for those
> who builds blender themselves. But if windows folks are fine with this --
> so be it.
>
> But it is very cool. Although I understand and kind of agree with you th
We've just committed a wrapper application, so the issue should be rather
solved in short-term way.
Really hope it doesn't cause much trouble and will work just smooth, also
hope it's not gonna to become any more complicated.
On Thu, Aug 7, 2014 at 1:33 PM, Martijn Berger
wrote:
> On Thu, Aug
17 matches
Mail list logo
