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

[Ivan Gyurdiev]

Stefan Dösinger wrote:
> Hi,
>
> Given the past discussion, do you agree with the code now? Alexandre wants 
> your OKs before applying the patches.
>   

I am not familiar with the state table, atifs, or recent developments in 
the d3d codebase. That's why I suggested a diagram, so that everyone can 
understand the discussion. My concern is long-term maintainability of 
the shader API.  I think the problem is with the definition of "shader 
backend".

The original intent, and the way it's currently used is:
    "A backend for the d3d shader pipeline ("d3d shader backend"), which 
happens to be implemented using some kind of gl shader".

The way this patchset is heading is:
    "A (gl shader backend), which implements both d3d shader and ffp 
pipeline, depending on the circumstances, through a mixed api"

I don't mind sharing the GL shader code to implement FFP or D3D shader 
pipelines - whether it's ATIfs, ARBfp/ARBvp, GLSL, or some other thing 
providing the implementation.  What I do mind is sharing that code 
through the same API for both the FFP and D3D pipeline codepaths. This 
leads to combining APIs that don't belong together, and odd multiplexing 
like you have in patch 004 - forcing the shader path through atifs, even 
though atifs currently doesn't support handling shaders properly, and 
has to "borrow code" from other backends, and implement routing to the 
right one based on what flags are set.

Why do you need to reroute the shader path through atifs to support an 
unrelated set of functionality (ffp replacement)? Isn't it possible to 
have an ffp_backend, and a shader_backend (shader being the d3d shader), 
and you can implement both differently, with different APIs?

Ivan