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

[Ivan Gyurdiev]

> Shader Model 3.0 and earlier versions have different ways to pass varyings 
> from vertex to pixel shader. In the end this means that the pixel shader is 
> dependent on the vertex shader. If the vertex shader is a GLSL shader, it can 
> read either the builtin varyings or the declared ones, the GLSL vertex shader 
> writes both and the driver (should) sort it out. If the vertex shader is not 
> a GLSL shader, we can only write to builtin varyings, so a GLSL pixel shader 
> has to use different code. Currently the GLSL linking code sorts it out, but 
> we have dependencies between vertex and pixel shaders. In the end I think at 
> least the linker object has to know way too many things about the shaders, 
> and the shaders have to know things about each other.
>   
You mean the code in generate_param_reoder_function ? That's exactly the 
kind of thing that should go in a "linker" object - it takes as input a 
vertex and pixel shader, and handles how they talk to each other.  The 
"semantics" map is the interface between them that describes varyings - 
of course the interface has to be available to the linker to read the 
vertex outputs and make decisions as to the pixel inputs . Your "linker" 
could be backend-independent and try to support odd combinations like  
software vs / glsl ps or something like that, or it could be 
glsl-specific, and basically know how to link one glsl vertex shader to 
one glsl pixel shader (you could use a different linker for other things).

Why is the vertex/pixel linkage related to how you generated the vertex 
(or pixel) shader ? Does it matter if your shader was created from the 
fixed or programmable interface on the d3d-side in order to link it to 
the other one?

How will geometry shaders fit into the picture ?

Ivan