Semantics, shaders, and fixups

[H. Verbeet]

On 03/07/06, Ivan Gyurdiev <ivg231 at gmail.com> wrote:
> Demo #2: Many Per Pixel Lights,
> http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip
> This is a d3d8 demo. The shader inputs are not marked with a semantic -
> the declaration data is mapped 1:1 to the shader inputs, so a specific
> register number is designated as the D3DVSDE_DIFFUSE register. Now,
> consider that we use the semantic to implement shader fixup - flipping
> red and blue on color inputs. Previously this fixup did not work at all
> on d3d8 shaders (as far as I can tell),
And it shouldn't. As you said, d3d8 shaders don't have a usage /
semantic defined per register.

> and I just made it work today,
> by storing a fake semantic for d3d8 shaders.
You can't do that. In d3d8 there's no way to figure out how a register
is going to be used. For d3d8 the only way to determine if we need
fixups is to look at the register's data type. That's exactly what the
patch / hack I sent you a while ago did.

> Therefore, how can we rely on a semantic tag for shader fixups? Seems we
> can't do that.
For d3d8 we can't, but for d3d8 the register shouldn't *have* that tag
in the first place, since there's no way we can make up a correct one.
The dolphin demo in the d3d8 sdk is another demo that breaks if you do
this. (It stores texture coordinates in register 6, which happens to
correspond to D3DVSDE_SPECULAR).

> Also, I don't understand why we're applying fixups on shader input
> either. Can someone explain why this fixup is needed exactly? If we need
> to flip red and blue because the format is backwards, shouldn't this be
> done at the end of the pipeline, at the point of interpretation by GL.
> Flipping things at an intermediate point can affect all kinds of
> calculations in the shader. At the end of the pipeline we can also
> reliably tell what's to be interpreted as color data, instead of
> following semantic hints.
It's not an intermediate point, but rather how the data is visible
inside the d3d shader. We don't look at the usage / semantic of the
register as much as we look at the data type that usage implies (for
d3d9 that is, d3d8 has an explicit data types and no usage). For the
"color" datatype, the blue component of the color is the first
component, x. We actually need to do it on input *because* of the
calculations you talk about. Consider this: How would the data look if
we did the fixups on the input data before sending it to the shader?