On Wednesday 09 December 2009 08:44:20 Keith Whitwell wrote: > On Wed, 2009-12-09 at 04:41 -0800, michal wrote: > > Zack Rusin pisze: > > > Hi, > > > > > > currently Gallium3d shaders predefine all their inputs/outputs. We've > > > handled all inputs/outputs the same way. e.g. > > > VERT > > > DCL IN[0] > > > DCL OUT[0], POSITION > > > DCL OUT[1], COLOR > > > DCL CONST[0..9] > > > DCL TEMP[0..3] > > > or > > > FRAG > > > DCL IN[0], COLOR, LINEAR > > > DCL OUT[0], COLOR > > > > > > There are certain inputs/output which don't really follow the typical > > > rules for inputs/outputs though and we've been imitating those with > > > extra normal semantics (e.g. front face). > > > > > > It all falls apart a bit on anything with shader model 4.x and up. > > > That's because in there we've got what Microsoft calls system-value > > > semantics. ( > > > http://msdn.microsoft.com/en-us/library/ee418355(VS.85).aspx#System_Val > > >ue ). They all represent system-generated inputs/outputs for shaders. > > > And while so far we only really had to handle front-face since shader > > > model 4.x we have to deal with lots of them (geometry shaders, domain > > > shaders, computer shaders... they all have system generated > > > inputs/outputs) > > > > > > I'm thinking of adding something similar to what D3D does to Gallium3d. > > > So just adding a new DCL type, e.g. DCL_SV which takes the vector name > > > and the system-value semantic as its inputs, so > > > FRAG > > > DCL IN[0], COLOR, LINEAR > > > DCL IN[1], COLOR[1], LINEAR > > > DCL IN[2], FACE, CONSTANT > > > would become > > > FRAG > > > DCL IN[0], COLOR, LINEAR > > > DCL IN[1], COLOR[1], LINEAR > > > DCL_SV IN[2], FACE > > > > > > It likely could be done in a more generic fashion though. Opinions? > > > > Zack, > > > > What would be the difference between > > > > DCL IN[2], FACE, CONSTANT > > > > and > > > > DCL_SV IN[2], FACE > > > > then? Maybe the example is bad, but I don't see what DCL_SV would give > > us the existing DCL doesn't. > > I'd have proposed something slightly different where the SV values don't > land in the INPUT file but some new register file. > > The reason is that when we start looking at geometry shaders, the INPUT > register file becomes two-dimensional, but these SV values remain > single-dimensional. That means that for current TGSI we'd have stuff > like: > > DCL IN[0..3][0] POSITION > DCL IN[0..3][1] COLOR > DCL IN[2] SOME_SYSTEM_VALUE > > Which is pretty nasty - half of the input file is one dimensional, half > two-dimensional, and you need to look at the index of the first > dimension to figure out whether the input reg is legal or not. > > So, I'm think some new register file to handle these system-generated > values is one possiblility, as in: > > DCL SV[0], FACE > > or > > DCL SV[1], PRIMITIVE_ID > > Thoughts?
Yea, I like that. And then separate syntax to handle the properties or overloading DCL? i.e. DCL GS_INFO PRIM_IN TRIANGLES vs PROPERTY GS_INFO PRIM_IN TRIANGLES ? ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
