[Bf-committers] OpenMP issues with msvc2013 builds

Chad Fraleigh chadf at triularity.org
Wed Aug 6 11:32:59 CEST 2014


On Wed, Aug 6, 2014 at 1:23 AM, Sergey Sharybin <sergey.vfx at gmail.com>
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 -- they've forced threads to spin for a while after they did
> a work. This is a know issue in the library and nobody actually gonna to
> fix it [1].
>
>
There's one woekaround to solve the issue which is to set OMP_WAIT_POLICY
> environment variable to PASSIVE. Unfortunately, since openmp is a dynamic
> library and can't be linked statically at all we can't modify environment
> variables from within blender using putenv(), this is to be done
> externally, before blender.exe starts.
>


Here's the list of possible solutions:
>
> - Declare msvc full of crap, switch to intel compilers
>

MinGW still won't do everything, huh? ;)



> - 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.



> - Ask users to set this variable in their environment (Control Panel ->
> System -> Environment Variables). For this we can create a .bat script.
>
> - Same as mentioned above, make it a step of the blender installation
> process Or make it so blender.exe modivies the registry. Personally i don't
> really like this approach.
>



> - 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).

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).


-Chad


More information about the Bf-committers mailing list