> The patch essentially adds a version to the constants and throws them > in a queue. The disadvantage is that setting a constant becomes a bit > more expensive, and cache usage becomes a bit worse if you have to > load constants from deeper in the tree, but it still gives me about 10 > extra fps in the CSS stress test. Whoa, that's an impressive improvement! I didn't see that much room for improvement in the CS:S performance at all.
How expensive is a shader_glsl_load_constant call if no constant was changed? I assume that no GL call is made in that case, > I don't see how setting vertex and fragment shaders at the same time > hurts us that much, it just gives the shader backend a certain degree > of freedom. I'd argue that my patch gives the shader backend more freedom. A backend implementation is free to use the same function for vertexshader_select and fragmentshader_select, as we use the same prototype. All it has to do(or better, should do) is checking wether it will be called again via a isStateDirty check. However, this check is done in the current code already, just outside of the shader backend(ie, it is forced onto the backend even if it is not needed) > Please also keep issue 20 from ARB_geometry_shader4 in > mind. While it's possible to do crazy stuff like mixing > ARB_vertex_program with fragment shaders, you can't mix > ARB_vertex_program with a geometry shader. I don't care too much about mixing ARB with GLSL. It might be a neat trick for MacOS, but it doesn't work in the way we need it in the current architecture anyway. To work around those MacOS GLSL bugs we'd have to select the backend based on the concrete shader. Having a ARBvp+GLSLfrag shader backend selected at library load isn't any better than what we have now in terms of MacOS bugdodgeability. > On the other hand, if you > really wanted to do that kind of mixing, you could just create two > backends and always pass FALSE for usePS to one backend, and always > pass FALSE for useVS to the other. It's not impossible, just ugly. > Splitting the shader backend doesn't change anything there. I'll come back to this should I ever send in an ATIfs or NVTS shader backend :-) . That solution is fine with me. > I do have an opinion on how the shader backend should fit in with the > rest of the code. So far, I haven't heard anything that would make me > change that opinion. I think we have a different understanding of what the gobal state table infrastructure is supposed to be. I didn't intend it as a "fixed function" state table, but rather a tool for managing all sorts of states. It includes things like blending, the scissor test or even the index buffer, which are not affected by shaders at all(since they're neither part of the vertex, fragment or geometry pipeline). So I don't think limiting the state table to the fixed function pipeline would be correct, even if shaders sat on top of it. (yes, there are many fixed function states and just a few shader states, but that's due to the nature of the two pipelines) I don't think that the vertex shader bypasses the fixed function vertex pipeline argument works here either. We have such a relationship between states elsewhere, e.g. D3DRS_LIGHTING overrides the lights, D3DRS_ALPHABLENDENABLE overrides various alpha states etc. I'm not convinced that shaders are special in any way. There's also the point about skipping applying fixed function states when the shader is active. I really think this should be up to the fragment pipeline implementation. The ARB fragment pipeline replacement skips the states(because it has to), the fixed function GL pipeline doesn't. Functionally it doesn't make any difference for the ffp pipeline. Performance wise you can argue both. If we apply the states it makes switching the shader on and off cheaper, if we do not apply them it helps broken games.
