Am Montag, 17. März 2008 16:22:30 schrieb H. Verbeet:
That's more an issue with the state table design than a reason to create a new shader backend. A more hierarchical state table would probably have helped there, but the general issue you're trying to solve is that you want the state table to change depending on the available extensions and wined3d configuration. I don't think that's limited to shaders or fragment processing. If a GL3 spec ever actually gets released, and actual drivers start implementing it, we'll run into it there as well.
Couldn't we have discussed that one week ago when I sent the patches to wine-devel? ;-)
I think putting the state table into a shader backend is quite reasonable considering the existing opengl spec and extension, even if we do not call atifs/nvrc "shaders". With my patches we set the shader backend using complex conditions based on available extensions. If we keep the state table separate we'd set both that way, and probably need shader specific decisions in either the state handlers, or state table specific considerations in the shaders. I do not see what we would gain by not putting the atifs code into a shader backend, other than moving the temporary uglyness of the 3 backends to a permanent state table selection uglyness.
As far as opengl 3 is concerned, I think they wanted to get rid of the fixed function pipeline, in that case we'd be best of with the shader backend anyway. However, I think trying to find an architecture that deals with future interfaces is a bit of lottery anyway. We don't know what Direct3D 11 will bring either.