[Bf-committers] OpenMP issues with msvc2013 builds

[Sergey Sharybin]

Inlined some answers,


On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh <chadf at triularity.org> 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 builds.


> > - 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
> > idea if it's doable.
> >
>
> Base on a quick look with Olly, where it looks up the OMP_WAIT_POLICY
> variable, it then compares it to "active" and "passive" and sets a memory
> byte to 1 or 0, respectively. Then that byte is checked two other places
> just before some calls to GetTickCount() and SwitchToThread(). So figure
> out a way to reference that location by name, and changing a byte might be
> all that is needed. Hypothetically at least.
>

That's kinda hackish and not real sure how to do this. Also not really fan
of investing time in this. Any volunteers to look into? :)

> - Create a small .exe which we put next to blender.exe and will call it
> > blender-launcher.exe or so. This application will modify the environment
> > variable and start blender.exe. We could also make it called blender.exe
> > and rename real blender.exe to blender.bin.exe so all the links and so
> > continues to work. Here's a quick code of this application [2], would
> need
> > to create an icon for it and so but that's details.
> >
>
> Or add a check at the very beginning of blender.exe's main() that checks
> for the variable, and if it isn't set yet, set it, and then exec itself.
> Making sure it is well tested to never get caught in infinite loop (which
> really should only happen if the environment change failed to take hold
> some how).
>

Not really sure it'll work. If you start exe file which is linked against
the DLL, the DLL will be loaded (and hence it'll have a copy of the
environment already) before loader will give it a contorl to your main()
function. You need to modify the enviornment before the dll was loaded.

Maybe i'm wrong and running self from the main will load omp dll again?


> With the separate executable, using the convention blender-bin.exe might be
> better (as I've seen that style with several other applications. Plus bin
> doesn't look like a sub-extension, e.g. .tar.gz).
>

Don't mind this as well.

-- 
With best regards, Sergey Sharybin