Remove dependency on d3dcompiler import library.

Remove dependency on d3dcompiler import library.

It is now loaded with LoadLibrary.

Added compile time option of having ANGLE enumerate various versions of d3dcompiler_nn.dll that the application can preload before eglInitialize().
Committed: https://code.google.com/p/angleproject/source/detail?r=1385

[apatrick1, 2012-11-01 20:27:23]

Hi Daniel,

This is a bit of a hack. It will allow Chrome to switch over to the win 8 sdk
and use a more recent version of the D3DCompiler DLL on Vista and later.

PTAL. Al.

[dgkoch, 2012-11-03 17:23:13]

Are you planning to distribute both the _43 and _46 versions? Or only one of
them depending on the target platform?  It might be possible just to use the _43
DLL on all platforms, but you'd have to try using it on Win8 to be sure.

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp
File src/libEGL/Display.cpp (right):

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:397: if (mD3dCompilerModule)
Don't we need to FreeLibrary here if we used LoadLibrary?

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:1272: return mD3DCompileFunc(hlsl, strlen(hlsl), "",
NULL, NULL, "main", profile, flags, 0, binary, errorMessage);
do you want to use g_fakepath in here?  Does the empty string prevent paths from
getting added to error messages?

[apatrick1, 2012-11-05 20:18:52]

Initially at least, I plan to distribute both 43 and 46. I prefer 46 because,
for some shaders, 43's D3DCompile reports success but returns shaders that don't
work. See http://crbug.com/158414.

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp
File src/libEGL/Display.cpp (right):

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:397: if (mD3dCompilerModule)
On 2012/11/03 17:23:13, dgkoch wrote:
> Don't we need to FreeLibrary here if we used LoadLibrary?

Both GetModuleHandleEx and LoadLibrary increase the reference count. I was being
consistent with mD3d9Module above. I don't recall why it is nor freed, possible
just freeing a module is dangerous, e.g. D3D is still doing stuff on another
thread. From the point of view of Chromium, I don't care. Your call.

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:1272: return mD3DCompileFunc(hlsl, strlen(hlsl), "",
NULL, NULL, "main", profile, flags, 0, binary, errorMessage);
On 2012/11/03 17:23:13, dgkoch wrote:
> do you want to use g_fakepath in here?  Does the empty string prevent paths
from
> getting added to error messages?

I don't understand why g_fakepath was added. As far as I can see, the HLSL
source will only be associated with a file if PIX is attached. See the opening
lines of ProgramBinary::compileToBinary and the perfActive() call. If it is not
needed I will happy eliminate g_fakepath.

[dgkoch, 2012-11-05 22:06:10]

On 2012/11/05 20:18:52, apatrick1 wrote:
> Initially at least, I plan to distribute both 43 and 46. I prefer 46 because,
> for some shaders, 43's D3DCompile reports success but returns shaders that
don't
> work. See http://crbug.com/158414.
> 
Interesting -- so there are actually fixes in the 46 DLL for SM3.0 shaders. In
that case we definitely should start using it as much as possible (i.e.
everywhere but XP).

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp
File src/libEGL/Display.cpp (right):

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:397: if (mD3dCompilerModule)
On 2012/11/05 20:18:53, apatrick1 wrote:
> On 2012/11/03 17:23:13, dgkoch wrote:
> > Don't we need to FreeLibrary here if we used LoadLibrary?
> 
> Both GetModuleHandleEx and LoadLibrary increase the reference count. I was
being
> consistent with mD3d9Module above. I don't recall why it is nor freed,
possible
> just freeing a module is dangerous, e.g. D3D is still doing stuff on another
> thread. From the point of view of Chromium, I don't care. Your call.

You are right that GetModuleHandleEx adds a reference.  I hadn't actually
checked.  However GetModuleHandle (which is what we're using for the d3d9
libraries above) does not add a reference.  So we should always FreeLibrary here
then.

https://codereview.appspot.com/6816074/diff/2001/src/libEGL/Display.cpp#newco...
src/libEGL/Display.cpp:1272: return mD3DCompileFunc(hlsl, strlen(hlsl), "",
NULL, NULL, "main", profile, flags, 0, binary, errorMessage);
On 2012/11/05 20:18:53, apatrick1 wrote:
> On 2012/11/03 17:23:13, dgkoch wrote:
> > do you want to use g_fakepath in here?  Does the empty string prevent paths
> from
> > getting added to error messages?
> 
> I don't understand why g_fakepath was added. As far as I can see, the HLSL
> source will only be associated with a file if PIX is attached. See the opening
> lines of ProgramBinary::compileToBinary and the perfActive() call. If it is
not
> needed I will happy eliminate g_fakepath.

See http://code.google.com/p/angleproject/issues/detail?id=162 (It's a security
issue)

[apatrick1, 2012-11-05 22:27:02]

Understood. PTAL.

[dgkoch, 2012-11-06 13:11:25]

LGTM.  Going to cause lots of fun come merge time, but we'll deal with it.