[4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend

[Stefan Dösinger]

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.