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

[Stefan Dösinger]

Am Montag, 17. März 2008 16:47:39 schrieb 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.
> 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.
> ...
Thinking about a bit more I think I have a better phrasing of this: The API of 
GL_ATI_fragment_shader is very close to the shader API of 
GL_ARB_fragment_program / GLSL, and as far as the global WineD3D design is 
concerend it is equal to the ARBfp one. Contrary to that, the nvrc API is 
comparable to the ARB_texture_env_combine API. We do not care how it works in 
the driver or the hardware, that's all abstracted away from us. API-wise it 
is a shader API, I think that is reason enough to give the atifs code its own 
shader backend.