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_Value >>> ). >>> 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?
I like this too. I believe many SV values would be constant per primitive (unlike other inputs which change per pixel). In some cases we might be able to do additional optimizations in our shader code-gen with that information, at least in fragment programs. -Brian ------------------------------------------------------------------------------ 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
