H. Verbeet wrote:
Changelog:
- Select the right shader backend when creating the device
Imho there should be either ps_selected/vs_selected flags, or shader_backend flag, but definitely not both [ does not make sense ]. I'd opt for allowing different backends on pshader vs vshader. Maybe the current drawprim code is implemented to use ARB or GLSL for both, but that's not a good reason to disallow capability by writing future code as if the backend was unified. More importantly, you should be able to mix software shaders, with the other backends.
I'm also not sure replacing all if statements with a function table is a good idea - restructuring code is dangerous, better not to do it unless new features are being added, or the code is being rewritten, or it's completely unmaintainable (I think that's a bit hard to argue).
On 27/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
H. Verbeet wrote: Imho there should be either ps_selected/vs_selected flags, or shader_backend flag, but definitely not both [ does not make sense ].
Well, yes, that's the idea. Unfortunately the ps_selected/vs_selected flags are still used in other parts of the code.
I'd opt for allowing different backends on pshader vs vshader. Maybe the current drawprim code is implemented to use ARB or GLSL for both, but that's not a good reason to disallow capability by writing future code as if the backend was unified. More importantly, you should be able to mix software shaders, with the other backends.
I did consider that, but in the end I don't think it really makes sense. Couple of things to consider: - Software shaders currently simply don't work. If we do get software shaders it'll likely be vertex only. Even if we did have software pixel shaders, we wouldn't be able to mix them with hardware vertex processing, since there's simply no interface to do that. I could see someone using software vertex shaders if he's got no hardware support for shaders, although it's questionable if such a card would be able to effectively run an application that requires them anyway. Mesa is possibly a better option there. Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly. - Mixing ARB and GLSL backends is pretty silly as well. - DX10 introduces another shader type, the geometry shader. Going that way would mean we'd possibly have three different backends to mix. - There is of course the SHADER_NONE setting, but imo that should be orthogonal to the backend being used.
So imo it just adds complexity to the code without giving much of a benefit.
- Software shaders currently simply don't work. If we do get software
shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
I could see someone using software vertex shaders if he's got no hardware support for shaders, although it's questionable if such a card would be able to effectively run an application that requires them anyway.
Software shaders are chosen if (1) there's no support for hardware, (2) the user elected software, or (3) the application elected software, and (3) is required as part of the DirectX spec.
Mesa is possibly a better option there. Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly
Well, I was able to identify at least one bug that way [ improper initialization of vertex shader output register ].
So imo it just adds complexity to the code without giving much of a benefit.
You're taking two logically separate concepts, and merging them together for no good reason at all. I'm just not sure what the purpose is - at the very least you'd be able to turn off pixel and vertex separately as a user override. Once geometry shaders come into play, I think they should get their own flag too.
On 28/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
- Software shaders currently simply don't work. If we do get software
shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
I could see someone using software vertex shaders if he's got no hardware support for shaders, although it's questionable if such a card would be able to effectively run an application that requires them anyway.
Software shaders are chosen if (1) there's no support for hardware, (2) the user elected software, or (3) the application elected software, and (3) is required as part of the DirectX spec.
Software shaders, sure. That doesn't mean you have to be able to mix them with hardware shaders. 1 doesn't apply if there's support for hardware pixel shaders, 2 is silly if there's support for hardware pixel shaders, and 3 selects software shaders for *both* vertex and pixel shaders.
Mesa is possibly a better option there. Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly
Well, I was able to identify at least one bug that way [ improper initialization of vertex shader output register ].
Well, that's nice. However, I don't think that's enough of a reason to be able to mix backends for vs & ps.
So imo it just adds complexity to the code without giving much of a benefit.
You're taking two logically separate concepts, and merging them together for no good reason at all. I'm just not sure what the purpose is - at the very least you'd be able to turn off pixel and vertex separately as a user override. Once geometry shaders come into play, I think they should get their own flag too.
Vertex shaders and pixel shaders are not separate concepts at all. Not in GLSL, not in D3D, and even less so in D3D10. Either way, I still don't see the benefit of mixing different backends.
On 27.11.2006 23:53, H. Verbeet wrote:
Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly.
Fun fact: a lot of Intel chips (up to the i945 I believe) have fragment program silicon but none for vertex programs - reality can be really silly sometimes.
- Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together with multitexturing setups.
So imo it just adds complexity to the code without giving much of a benefit.
Not really. As Ivan said, VPs and FPs are separate concepts, and allowing the mixing of types probably leads to a more complete feature set in the end.
-f.r.
On 28/11/06, Frank Richter frank.richter@gmail.com wrote:
On 27.11.2006 23:53, H. Verbeet wrote:
Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly.
Fun fact: a lot of Intel chips (up to the i945 I believe) have fragment program silicon but none for vertex programs - reality can be really silly sometimes.
Yes, but afaik they still expose the "hardware" OpenGL interfaces, which is what we're talking about here.
- Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together with multitexturing setups.
ARB as in ARB_vertex_program or ARB_fragment_program, I'm not sure what multitexturing has to do with it. You can't, for example, properly use ARB_fragment_program together with a GLSL vertex shader. (You might be able to get away with it due to the way GLSL is implemented on a specific implementation, but you're certainly not supposed to).
allowing the mixing of types probably leads to a more complete feature set in the end.
Except that there are no actual meaningful combinations to make.
- Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together with multitexturing setups.
ARB as in ARB_vertex_program or ARB_fragment_program, I'm not sure what multitexturing has to do with it. You can't, for example, properly use ARB_fragment_program together with a GLSL vertex shader. (You might be able to get away with it due to the way GLSL is implemented on a specific implementation, but you're certainly not supposed to).
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt
Interactions with ARB_vertex_program and ARB_fragment_program
Mixing a high level ARB_vertex_shader shader with a low level ARB_fragment_program shader is allowed. However, a high level ARB_vertex_shader shader and a low level ARB_vertex_program shader cannot be active at the same time.
http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt:
Interactions with ARB_vertex_program and ARB_fragment_program
Mixing a high level ARB_fragment_shader shader with a low level ARB_vertex_program shader is allowed. However, a high level ARB_fragment_shader shader and a low level ARB_fragment_program shader cannot be active at the same time.
allowing the mixing of types probably leads to a more complete feature set in the end.
Except that there are no actual meaningful combinations to make.
Well, at least you can turn the pixel and vertex shaders off individually, rather than turn off shaders completely (using the NONE backend). I think up until a few releases ago pixel shaders were off by default.
On 28/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt
Interactions with ARB_vertex_program and ARB_fragment_program
Mixing a high level ARB_vertex_shader shader with a low level ARB_fragment_program shader is allowed. However, a high level ARB_vertex_shader shader and a low level ARB_vertex_program shader cannot be active at the same time.http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt:
Interactions with ARB_vertex_program and ARB_fragment_program
Mixing a high level ARB_fragment_shader shader with a low level ARB_vertex_program shader is allowed. However, a high level ARB_fragment_shader shader and a low level ARB_fragment_program shader cannot be active at the same time.
"Allowed" is not quite the same as "useful" though.
Another issue that comes up when trying to mix eg a software vertex shader with a hardware pixel shader is that you can't actually pass varyings from the software vertex shader to the hardware pixel shader.
allowing the mixing of types probably leads to a more complete feature set in the end.
Except that there are no actual meaningful combinations to make.
Well, at least you can turn the pixel and vertex shaders off individually, rather than turn off shaders completely (using the NONE backend). I think up until a few releases ago pixel shaders were off by default.
Note, when you read the patch, that the "none" backend is only used when *both* vertex and pixel shaders are disabled. Turning of individual shaders is completely separate from the backend being used. Currently the ps_selected / vs_selected flags are used for that, but the idea is to turn that into a flag specific for turning on/off the respective shader type.
On 28.11.2006 09:48, H. Verbeet wrote:
Another issue that comes up when trying to mix eg a software vertex shader with a hardware pixel shader is that you can't actually pass varyings from the software vertex shader to the hardware pixel shader.
As far as I remember the fixed function pipeline basically passes texture coordinates through. This is at least one way to pass varyings to the FP...
-f.r.
On 28/11/06, Frank Richter frank.richter@gmail.com wrote:
On 28.11.2006 09:48, H. Verbeet wrote:
Another issue that comes up when trying to mix eg a software vertex shader with a hardware pixel shader is that you can't actually pass varyings from the software vertex shader to the hardware pixel shader.
As far as I remember the fixed function pipeline basically passes texture coordinates through. This is at least one way to pass varyings to the FP...
Well ok, that would probably work, but it wouldn't be without its own problems either. It would also require different backends to know about eachother, and generate different code depending on what combination is being used.
-
Frank Richter -
H. Verbeet -
Ivan Gyurdiev