hlsl2glsl

[luis.busquets at ilidium.com]

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?