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

Stefan Dösinger stefan at codeweavers.com
Fri Mar 21 06:48:27 CDT 2008


Am Freitag, 21. März 2008 03:07:48 schrieb Ivan Gyurdiev:
> However, since there are 3 base things to inherit from (arb, glsl,
> none), you're inheriting each of them and now you have 6 "backends". It
> seems that the base functionality is fairly independent of the derived
> functionality, so that's why I suggested composition over inheritance
> here. I understand you're concerned with linking vertex and fragment
> together - but that should probably go in a separate object.
Thinking about it a bit more I am less convinced that having a separate linker 
object is going to work, thanks to the different varying handling.

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.

(The visual tests suggest that the ATI driver on Windows does not handle 
pre-3.0 <-> 3.0 shader varying passing properly, but it is in violation of 
the refrast. While that suggests that games are unlikely to depend on this 
tricky behavior, I do not like the idea of justifying our design with an ATI 
driver bug)



More information about the wine-devel mailing list