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.