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. Thanks. ------------------------------------------------------------------------------ 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
