Semantics, shaders, and fixups

[Ivan Gyurdiev]

H. Verbeet wrote:
> 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.
So, are the names in the D3DVSD_REGISTER enumeration meaningless?
Why is D3DVSDE_POSITION called that way?

>> 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.
If that works for d3d8, why doesn't it work for d3d9?
D3D9 have types as well on each semantic, and D3DCOLOR is one of the types.

>> 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?
I see - I must have misunderstood that we need the fixup to be applied 
because of the way OpenGL expects the color data after the shader is 
executed. You're saying that's just the standard way to assign a 
D3DCOLOR to x,y,z,w components...