stefan at codeweavers.com
Mon Dec 10 08:41:49 CST 2007
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
Also, the card never compiles shaders. This is always done on the CPU.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
More information about the wine-devel