Am Montag, 10. Dezember 2007 14:23:46 schrieb luis.busquets@ilidium.com:
Ok. I get that the program realeased by a private vendor is not good. Nevertheless, what about the philosophy? What about:
- 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.