d3dcompiler: Add D3DReadFileToBlob, D3DWriteBlobToFile, , D3DCompileFromFile, D3DCompile2 stubs

Matteo Bruni matteo.mystral at gmail.com
Tue Jun 23 14:47:56 CDT 2015


2015-06-23 10:41 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair at hotmail.com>:
> Currently the code for d3dcompiler_*dll's is in the _43 version.
>
> However these function belong in d3dcompiler_46+
>
> So,
> 1. Is it ok to use private functions?

I don't know all the implications of that but it doesn't seem to be
necessarily wrong.

> If not, how should it be done? Keep in mind that d3d9, d3d10, x_input will
> have the same issue at some point.

Not sure what you mean with d3d9 here. Did you mean d3dx9?

> 2. Could it be done like the msvrt* libraites? However since the structures
> haven't changed between versions maybe this isn't the best way.

There are / have been a few bugs reported for d3dx9 with applications
failing to cope with forwarded functions (e.g.
https://bugs.winehq.org/show_bug.cgi?id=21817) and I imagine similar
problems might also happen with d3dcompiler so that would be a point
in favor of this solution.

Moreover, in general each native d3dcompiler_xx (AND each d3dx9_xx!)
version has a separate copy of the HLSL compiler inside and each one
has a different version of the compiler. That means you will get
things like https://bugs.winehq.org/show_bug.cgi?id=33770#c7 unless we
can generate different code for different d3dcompiler_xx.dll versions.
Another one of those I know of is that functions inside ASCII effect
files can be "overloaded" with multiple implementations for different
shader versions. In older d3dx9 you specify the target version by
spelling it out in the function definition, but that changed at some
point and the older syntax just doesn't work on newer HLSL compiler
versions.

So I think this is the route we want to take eventually. Maybe your
patch is fine for the time being though.

> 3. Move the code the latest DLL.

That would work but notice that the same thing might (will?) repeat
after MS releases new versions of d3dcompiler_xx.dll with new exports.

BTW, I should have asked this earlier: what do you need those newer
d3dcompiler_xx.dlls for? AFAIU those versions > 43 are never installed
in system32 and applications are supposed to just bring a copy in
their application directory (e.g. see the "Redistribution" section in
http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx
or point 6c in https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85%29.aspx).



More information about the wine-devel mailing list