[Bf-committers] OpenMP issues with msvc2013 builds

[Chad Fraleigh]

On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger <martijn.berger at gmail.com>
wrote:

> On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh <chadf at triularity.org>
> 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() for each supported target (i.e. vcomp120.dll,
> > vcomp120d.dll), until one is found.
> >
> >  - Calculate the address of the flag from the module base.
> >
> >  - Calculate the address of the code where it does the OMP_WAIT_POLICY
> > active/passive checks and verify a few of the static opcode bytes (either
> > verbatim, or with a checksum/hash).
> >
> We can most likely also just look at specific dll version and see if we
> "know" it.
>

The extra sanity check was just to make sure the wrong address wasn't
accidentally clobbered under unexpected conditions.



> >  - Get the address that code references for the flag, and if it matches
> the
> > earlier calculation, then consider it validated, and change the flag at
> > that address.
> >
> >  - If no supported dll's were found, or couldn't be verified, output a
> > warning to stderr about bad performance.
> >
>
> Looks good on paper. It is good to realize that we re-distribute vcomp and
> thus have pretty good control over what version we use.
>

Yeah.. I was looking at the dll in my system32 directory, so I was thinking
it was a system lib.

Actually, if blender controls the dll being used, and assuming it is
allowed within the distro license when bundled as a private dll, that could
make things far easier. Simply patch the dll (a one byte change) so that it
defaults to the passive value.


-Chad