[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