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

[Matteo Bruni]

2015-06-23 10:41 GMT+02:00 Alistair Leslie-Hughes :
> Currently the code for d3dcompiler_*dll's is in the _43 version.
>
> However these function belong in d3dcompiler_46+
>
> So,
> - 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?
> - 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.
> - 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.as...
or point 6c in https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85%...).

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

[Alistair Leslie-Hughes]

Hi Matteo,

Thanks for you feedback.

On 24/06/2015 5:47 AM, Matteo Bruni wrote:
> 2015-06-23 10:41 GMT+02:00 Alistair Leslie-Hughes :
> > Currently the code for d3dcompiler_*dll's is in the _43 version.
> So I think this is the route we want to take eventually. Maybe your
> patch is fine for the time being though.

I'm fine with changing the patch to reflect how it should be done, as
long as I know what is correct.

I'll update the patch to reflect this new direction.
> 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.as...
> or point 6c in https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85%...).

I was using fxc.exe from Visual Studio 2012/13 which does indeed have 
this dll in the same directory.  I'm a purist as much as possible when
using applications.

Best Regards
  Alistair Leslie-Hughes