hlsl2glsl is the good solution for implementing shaders on directX 10. Nevertheless, the hlsl compilation to tokens has to be done for d3d9. On the other hand, if we implement d3dx9_xx, it is likely that the application will be using the compile D3DX9CompileShader to get the tokens. Currently it works and we can use the libraries d3dx9_xx and get good results but the following tranfosmations: 1. HLSL is compiled to tokens 2. Tokens are transformed to GLSL. I think that a good addition if the d3dx9_xx libraries are going to be implemented is to put a resource in wined3d that would let know which source HLSL code the tokens are meant to be and add the capability to instead of transform tokens to GLSL, to let wine know which is the HLSL source code the tokens came from. Then, there is the possibility to let wine do if it is available a HLSL2GLSL transfomation directly from the HLSL to GLSL. 1. HLSL is compiled to tokens and the result structure has a pointer to the HLSL source code. 2. If activated the "use HLSL2GLSL for directX9 Shaders when available" and the HLSL source code is available then 2.1. use HLSL2GLSL to transform the HLSL source code 2.2. Compile GLSL. 3. If not 2. then Tokens are transformed to GLSL.
The aim would not be to gain compilation time but to be more loyal to the source HLSL. The final executable instead of making exactly what the ASM is meant to do, it would make exactly what the HLSL is meant to do and probably would be more optimized for the particular system. HLSL --> Tokens --> GLSL --> Executable that performs the actions of the tokens HLSL --> GLSL --> Executable that performs the actions of the HLSL.
Furthermo, taking into consideration the need of HLSL2GLSL for DirectX 10, the hlsl2glsl will have to be set anyway. Therefore, the code needs are not so big but just leaving the door open. What do you all think and in particular David?