Hi,
Let me introduce myself, I'm a final year student of Software Engineering from the UK and I'm beginning to take more of an active interest in Wine. I believe that one of the main reasons people stick with Windows over Linux or BSD is because they miss their games. I have an interest in OpenGL and Direct3D and would be interested in helping to get the Shader code up to a nice level of functionality. This is no small task and I'm still figuring things out. It seems we still need a HLSL to GLSL translator for SM 3.0 but that is for future discussion :)
I have noticed that at the moment, shaders are parsed and converted to AFP_FP/VP 1 and if a particular opcode is not supported, a FIXME states a requirement for GLSL.
I was curious as to whether it would be acceptable to provide a compile-time check for OpenGL 2.0? It would be no different than checking for any other dependency, with the only disadvantage being that we can not be sure which version the user has when distributing binaries. We could get by this by distributing binaries for ARB_vertex_program and ARB_fragment_program 1 support and requiring a compile for users who want OpenGL 2.0 functionality.
I think it would have to be compile-time because we need to know whether we can use the GL 2.0 shader methods at that point.
If it is supported, we could then leave the current code in place for OpenGL < 2.0 Then we could use "#ifdef GL_VERSION_2" or similar to allow linking to the GL 2.0 shader loading interfaces and define and make use of a function to convert the shader ASM for versions less than 2.0 straight to GLSL at runtime, skipping the current issue of beginning to convert to ARB shaders, hitting a GLSL-requiring opcode and having to start again with GLSL.
I could have this all wrong so a little guidance and feedback on the proposal would be very helpful!
Kind Regards, Phil Costin
On 23/04/06, Phil Costin philcostin@hotmail.com wrote:
It seems we still need a HLSL to GLSL translator for SM 3.0 but that is for future discussion :)
Well, no, not directly. In Direct3D9 HLSL is compiled to the same kind of code as assembly shaders by the d3d9x library. The d3d9 dll never sees HLSL or assembly, just compiled shaders. Direct3D10 does contain a "D3D10CompileShader" function, but that's shader model 4.0.
I was curious as to whether it would be acceptable to provide a compile-time check for OpenGL 2.0?
No, and it's not required either. GLSL is an extension just like any other, and should be checked runtime, just like all the other extensions.
H. Verbeet wrote:
On 23/04/06, Phil Costin philcostin@hotmail.com wrote:
It seems we still need a HLSL to GLSL translator for SM 3.0 but that is for future discussion :)
Well, no, not directly. In Direct3D9 HLSL is compiled to the same kind of code as assembly shaders by the d3d9x library. The d3d9 dll never sees HLSL or assembly, just compiled shaders. Direct3D10 does contain a "D3D10CompileShader" function, but that's shader model 4.0.
I was curious as to whether it would be acceptable to provide a
compile-time
check for OpenGL 2.0?
No, and it's not required either. GLSL is an extension just like any other, and should be checked runtime, just like all the other extensions.
Thanks for the reply. I was assuming that it would be impossible to link against methods that may not exist in the user's OpenGL implementation. I still have a lot to brush up on!
Regards, Phil Costin
-
H. Verbeet -
Phil Costin