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?
On 10/12/2007, luis.busquets(a)ilidium.com <luis.busquets(a)ilidium.com> wrote:
What do you all think and in particular David?
In the first place, I think this is all irrelevant without having an actual d3d10 implementation. Second, you'll need a proper implementation of the SM 4.0 implementation either way, because D3D10 still allows binary shaders, and I expect the majority of games to ship those instead of actual source. So it would be an additional path that needs to be maintained, and the most feasible way to implement it I've heard so far would be to embed GLSL code a comment section inside the shader byte code, which would be rather ugly. And finally, the actual hardware has it's own hardware specific language for shaders. HLSL or D3D bytecode isn't really any closer to the actual hardware language than GLSL or ARB asm, so it isn't even guaranteed to gain us much.
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?
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). Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Ok. I get that the program realeased by a private vendor is not good. Nevertheless, what about the philosophy? What about: 1. The implementation shaders of DirectX 10 making the card compile GLSL code generate by transforming the HLSL code. 2. The Implementation for D3DX9 of the "possibility" to store the HLSL source code, transfomr it to GLSL and use the card resources to compile the latter, so that a mor loyal executable in relation to the HLSL is at the video card.
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).
Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Am Montag, 10. Dezember 2007 14:23:46 schrieb luis.busquets(a)ilidium.com:
Ok. I get that the program realeased by a private vendor is not good. Nevertheless, what about the philosophy? What about: 1. The implementation shaders of DirectX 10 making the card compile GLSL code generate by transforming the HLSL code. 2. The Implementation for D3DX9 of the "possibility" to store the HLSL source code, transfomr it to GLSL and use the card resources to compile the latter, so that a mor loyal executable in relation to the HLSL is at the video card. That HLSL2GLSL is written by ATI is absolutely no issue. It is released under an open source license and we can make use of the code. The philosophy you suggest is more of a problem.
Keep in mind that getting shaders translated into GLSL, which we can then send to the card, is only a small part of the whole dx10 topic. We will need our own codepath anyway(HLSL -> d3d asm -> GLSL). We have to investigate wether a direct HLSL -> GLSL path will gain us any performance. We can optimize the HLSL -> d3d asm ourselves, and the d3d asm->GLSL->card native code is lossless in theory. If the GLSL compiler is good, then it will recognise the assembler instructions in our GLSL code and essentially we have d3d asm -> card native then. We will have to investigate what we gain with a 2nd direct HLSL->GLSL translation. I think we won't gain anything, and the effort is better spent elsewhere. Also, the card never compiles shaders. This is always done on the CPU.
Just to add that msdn states that "Direct3D 10 limits the use of assembly language to that of debugging purposes only, therefore any hand written assembly shaders used in Direct3D 9 will need to be converted to HLSL." http://msdn2.microsoft.com/en-us/library/bb205073.aspx#Porting_Shaders I think that the idea is that the dreiver vendor has the possibility to implement its own compiler and adapt the code to the specifics of its hardware. I think that translating HLSL to GLSL for D3D10 is the write path. (For D3D9 obviously not) Therefore I think that it should be wine 's strategy towars the implementation of this next D3D release.
That HLSL2GLSL is written by ATI is absolutely no issue. It is released under an open source license and we can make use of the code. The philosophy you suggest is more of a problem.
Keep in mind that getting shaders translated into GLSL, which we can then send to the card, is only a small part of the whole dx10 topic. We will need our own codepath anyway(HLSL -> d3d asm -> GLSL). We have to investigate wether a direct HLSL -> GLSL path will gain us any performance. We can optimize the HLSL -> d3d asm ourselves, and the d3d asm->GLSL->card native code is lossless in theory. If the GLSL compiler is good, then it will recognise the assembler instructions in our GLSL code and essentially we have d3d asm -> card native then.
We will have to investigate what we gain with a 2nd direct HLSL->GLSL translation. I think we won't gain anything, and the effort is better spent elsewhere.
Also, the card never compiles shaders. This is always done on the CPU.
On 12/12/2007, luis.busquets(a)ilidium.com <luis.busquets(a)ilidium.com> wrote:
Just to add that msdn states that
"Direct3D 10 limits the use of assembly language to that of debugging purposes only, therefore any hand written assembly shaders used in Direct3D 9 will need to be converted to HLSL."
http://msdn2.microsoft.com/en-us/library/bb205073.aspx#Porting_Shaders
I think that the idea is that the dreiver vendor has the possibility to implement its own compiler and adapt the code to the specifics of its hardware. I think that translating HLSL to GLSL for D3D10 is the write path. (For D3D9 obviously not) Therefore I think that it should be wine 's strategy towars the implementation of this next D3D release.
No, that's not how it works. The device functions that create shaders still get fed bytecode, and it would at least in theory be possible to create an assembler for that bytecode. See http://msdn2.microsoft.com/en-us/library/bb205084.aspx and http://msdn2.microsoft.com/en-us/library/bb173562.aspx for example. Also potentially interesting is http://msdn2.microsoft.com/en-us/library/bb310589.aspx
participants (4)
-
H. Verbeet -
luis.busquets＠ilidium.com -
Roderick Colenbrander -
Stefan Dösinger