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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev