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

[Stefan Dösinger]

Am Freitag, 21. März 2008 16:22:41 schrieb 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 ?
No, I mean pshader_glsl_input_pack, or rather its callers. As for the 
generate_param_reoder_function you're perfectly right, it is part of the 
linking code.

> 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?
It matters wether or not the vertex shader writes to the implicit opengl 
varyings(gl_TexCoord[], gl_Color, gl_SecondaryColor, ... in GLSL terms,  
output.* in ARB terms) or custom varyings("varying vec4 foo" in GLSL). If 
both shaders are GLSL, everything's fine, the vertex shader writes to both 
and lets the linker and the driver sort things out. But if the vertex 
processing is non-GLSL(fixed function, ARB or whatever), and the D3D pixel 
shader needs custom varyings(3.0 shader), then the GLSL fragment shader has 
to fetch them from the implicit varyings.