Re: d3dcompiler: Add D3DReadFileToBlob, D3DWriteBlobToFile, , D3DCompileFromFile, D3DCompile2 stubs
2015-06-23 10:41 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)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.as... or point 6c in https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85%...).
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 <leslie_alistair(a)hotmail.com>:
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
participants (2)
-
Alistair Leslie-Hughes -
Matteo Bruni