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