hlsl2glsl

[Stefan Dösinger]

Am Montag, 10. Dezember 2007 14:23:46 schrieb luis.busquets at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20071210/f4b996e4/attachment-0001.pgp