Roderick Colenbrander thunderbird2k at gmx.net
Mon Dec 10 02:42:08 CST 2007

> 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
> 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?

The hlsl2glsl project isn't that useful. It was discussed a long time. One of the reasons is that the code is written in C++. Second we would need our parser anyway for the binary path. We agreed it is better to write our own parser to have more control of the code and to avoid NIH problems (not invented here).

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

More information about the wine-devel mailing list