D3DX shader compiler alternatives?
Author
Are there alternatives to the D3DXCompileShader() function? Best thing would be a static lib. I have to ship the d3dx_XY.dll with my stuff because I use the compiler from D3DX. Since this is the ONLY thing I use from D3DX, it would be nice to have another compiler. Are there any?
Not that I'm aware of... but maybe you have to step back and ask yourself whether you REALLY need dynamic shader compilation?
Its perfectly possible to stream in a precompiled shader (in binary form) and use it for Create*Shader(). In fact, I'd recommend this method out-right as it'll almost certainly be an order of magnitude faster than dynamic compilation.
Look into fxc.exe (or fxc10.exe if you're feeling adventurous) and integrate it with your build process. I do that as a basic feature of my projects so I can get VS to manage my shader compile errors as well as regular C++ coding errors...
I have seen people fall back to pre-Feb'05 SDK's just to get around the D3DX DLL distribution problem - I would strongly recommend you avoid any temptations to do this. The HLSL compiler is one of the D3DX areas that has change significantly over the last 18 months or so - dropping back to such an old SDK is quite likely to cause you other, more subtle, problems.
hth
Jack
Its perfectly possible to stream in a precompiled shader (in binary form) and use it for Create*Shader(). In fact, I'd recommend this method out-right as it'll almost certainly be an order of magnitude faster than dynamic compilation.
Look into fxc.exe (or fxc10.exe if you're feeling adventurous) and integrate it with your build process. I do that as a basic feature of my projects so I can get VS to manage my shader compile errors as well as regular C++ coding errors...
I have seen people fall back to pre-Feb'05 SDK's just to get around the D3DX DLL distribution problem - I would strongly recommend you avoid any temptations to do this. The HLSL compiler is one of the D3DX areas that has change significantly over the last 18 months or so - dropping back to such an old SDK is quite likely to cause you other, more subtle, problems.
hth
Jack
I don't think pre-compiling your shaders with FXC will help you as you still need to call D3DXAssembleShader which is part of the D3DX DLL.
Quote:Original post by griffin2000I'm pretty sure that function is for text-based assembly shaders. Using those doesn't really require the full-blown compilation that HLSL does - just a conversion from text symbols to binary symbols.
I don't think pre-compiling your shaders with FXC will help you as you still need to call D3DXAssembleShader which is part of the D3DX DLL.
The key point is the linkage between the LPD3DXBUFFER ppShader parameter and the corresponding DWORD array input into Create*Shader(). Using your own code you can save out that binary data and read it back in, and fxc.exe should be an identical command-line form of D3DXCompileShader().
Its been a while since i bothered using this route, but I dont remember having any problems with it.
hth
Jack
I didn't know that (I use D3DXCompileShader as it allows be to rebuild my shaders with restarting my app).
Which function do you use to load the pre-compiled shader object file ?
Which function do you use to load the pre-compiled shader object file ?
Quote:Original post by dv
Are there alternatives to the D3DXCompileShader() function? Best thing would be a static lib. I have to ship the d3dx_XY.dll with my stuff because I use the compiler from D3DX. Since this is the ONLY thing I use from D3DX, it would be nice to have another compiler. Are there any?
You don't (and shouldn't) need to compile your shaders on load, you can just use the obj format, or even generate a header file with the /Fh option, e.g. get a dump like (in a header file):
const DWORD g_NULLPS11[] =
{
0xffff0101, 0x0017fffe, 0x42415443, 0x0000001c, 0x00000023, 0xffff0101,
0x00000000, 0x00000000, 0x00000100, 0x0000001c, 0x315f7370, 0x4d00315f,
0x6f726369, 0x74666f73, 0x29522820, 0x44334420, 0x53203958, 0x65646168,
0x6f432072, 0x6c69706d, 0x39207265, 0x2e32312e, 0x2e393835, 0x30303030,
0xababab00, 0x00000051, 0xa00f0000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000001, 0x800f0000, 0xa0e40000, 0x0000ffff
};
Then just say
pDevice->CreatePixelShader(g_NULLPS11 , &pShader );
(This shader is a pixel shader that writes 0 to the output)
Author
Problem is: I use this in an API-independent environment, which also uses Cg. I cannot use binary shaders with Cg, I need the code. In GLSL, I need the code too. Inserting a special path just for D3D shaders would not be nice.
Quote:Original post by dv
Problem is: I use this in an API-independent environment, which also uses Cg. I cannot use binary shaders with Cg, I need the code. In GLSL, I need the code too. Inserting a special path just for D3D shaders would not be nice.
So, why dont you do ALL your shaders in cg?
I always thought the shader compiler would use the display driver in some way to optimize the shader for the hardware.
Reading this thread makes me think my assumption is wrong :)
Would be good to not have to compile shaders at runtime.
Reading this thread makes me think my assumption is wrong :)
Would be good to not have to compile shaders at runtime.
Quote:Original post by Jimfing
I always thought the shader compiler would use the display driver in some way to optimize the shader for the hardware.
Reading this thread makes me think my assumption is wrong :)
That's what happens with GLSL shaders--the driver compiles them. However, with HLSL in D3D9, D3DX does all the work. The driver optimizes the generated code. With Direct3D 10, IIRC, the driver will be the one compiling HLSL.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
