[Bf-committers] OpenMP issues with msvc2013 builds

[Sergey Sharybin]

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 in the scene
evaluation, make blender really granular depsgraph, switching evaluation to
a task-based system. This is the only way you utilize CPU well without
extra threading overhead.

Current state in blender is that threading happens on object level and then
objets starts using openmp which have own task pool and leads to quite
reasonable amount of overhead.

Coomooon, we're adding LIKELY() to get some ghost performance bosot, but
we're using one task scheduler from another one which gives order of
magnitudes bottlenecks than missing LIKELY declarations ;)

Using OpenMP for tools -- tihs is'm not THAT strong about zapping stuff
out. IFit works, let's use it. If not --meeeh, dunno.

But tha't's separate topic, let's get into it after we know how we'll deal
with openmp in upcoming 2.72.


On Thu, Aug 7, 2014 at 11:51 AM, Chad Fraleigh <chadf at triularity.org> wrote:

> On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger <martijn.berger at gmail.com>
> 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 active, which defaults to 0x01).
>
> The prior contents in that area are:
>
> 00016980:    FD 83 8F AF 06 94 7D 11 E4 2D DE 9F CE D2 C8 04
> ......}..-......
> 00016990:    DD A6 D8 0A FF FF FF FF 01 00 00 00 01 00 00 00
> ................
> 000169A0:    01 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> ................
> 000169B0:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
>
>
> I ran an install of 2.71 with a patch dll and it didn't give any errors
> loading it (e.g. checksum/signature mismatch). But since I don't know what
> to look for with the CPU issue manifestation, I couldn't test it further.
>
>
> Since Olly only supports 32-bit code, I couldn't easily identify the
> location for the 64-bit dll. I would have to resort to using WinDbg or
> something (ugg!). But since this is only a proof of concept, I assume it
> shouldn't be needed at this point.
>
>
> -Chad
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin