[Mesa-dev] shader inputs vs. system values

[Zack Rusin]

On Wednesday 01 December 2010 19:46:42 Brian Paul wrote:
> I was working on finishing up instanced drawing in Mesa/gallium last
> week.  The one stumbling block was how to handle the instance ID.
> 
> The instance ID is an integer accessible by the vertex shader that
> only changes per drawing instance, not per vertex.  For that reason it
> seems a little funny to declare it as a Mesa PROGRAM_INPUT or Gallium
> TGSI_FILE_INPUT variable.
> 
> Similarly, there's other shader inputs that don't change per-vertex or
> per-fragment that perhaps should be "system values" instead.
> gl_FrontFacing, for example.
> 
> Here's a list of shader inputs (current and upcoming) that don't fit
> in with regular attributes like position, texcoords or colors:
> 
> bool gl_FrontFacing - fragment shader, per triangle
> int gl_InstanceID  - vertex shaders, per instance
> int gl_PrimitiveIDIn  - geom/frag shader input, per primitive
> int gl_PrimitiveID  - geom shader output, per vertex
> int gl_Layer - geom shader output per vertex, frag shader input per
> primitive
> int gl_VertexID - vertex shader input, per vertex
> int gl_SampleID - fragment shader, per sample
> vec2 gl_SamplePosition - fragment shader, per sample
> int gl_ViewportIndex - geom shader output, per vertex
> 
> (There's more for tessellation, hull and compute shaders)
> 
> 
> When I prototyped instanceID as a per-vertex input it caused the draw
> module and softpipe to blow up because it doesn't correspond to a
> vertex attribute.  There seem to be some assumptions in a few places
> about vertex shader inputs directly corresponding to vertex arrays/
> attributes.
> 
> I think we need to decide which of the above are system values vs.
> per-vertex/fragment inputs.
> 
> DX10's system values encompasses the above variables plus others such
> as clip distance and fragment position, BTW.
> 
> Zack, I think had started looking at system values about a year ago.
> What are/were your thoughts on this?

The conclusion was pretty much exactly as you describe above I ended up adding 
the TGSI_FILE_SYSTEM_VALUE register for it.

The system generated values are fundamentally different to shader inputs and 
one either needs to special case all of them on a case by case basis (bonkers) 
or group them all together as a special input type. The latter just makes more 
sense.

In terms of a list of them going with something similar to d3d probably makes 
sense:
http://msdn.microsoft.com/en-us/library/bb509647(VS.85).aspx#System_Value

z