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.