[Mesa-dev] shader inputs vs. system values

[Brian Paul]

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?

-Brian