On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger <[email protected]> wrote:
> On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh <[email protected]> > 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
