On Wednesday 09 December 2009 07:41:11 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.
It's a lot like the argument of what's the point of having separate IN, OUT, TEMP and CONST registers when everything could be simply using the same kind and then be translated in the drivers to whatever they need - it splits up semantically different things into physically different code-paths. It makes it explicit that system-generated inputs are different than normal inputs (which they are), it gives them distinct semantics (which they have) and makes the code easier to read and understand. Of course the system generated parts are just a part of it. We'll need an extra DCL anyway for shader properties, i.e. properties which define certain aspect of the shader itself and the way it's executed. For example for geometry shader that would be the input primitive they are working on, the maximal number of vertices they can output and the kind of primitive they can output, for compute shader that would be the number of threads within the work-group they are executing in. AMD compute intermediate language recognizes those different decelerations, so those D3D ( http://msdn.microsoft.com/en- us/library/ee418366(VS.85).aspx ). For us, we can either overload DCL or have complete separate DCL's for them, e.g. GEOM DCL GS_INFO PRIM_IN TRIANGLES DCL GS_INFO PRIM_OUT TRIANGLE_STRIP DCL GS_INFO MAX_VERTEX_COUNT 3 /* vertices_out for gl */ DCL SV IN[0].x, PRIMITIVE_ID DCL SV IN[0].y, INSTANCE_ID DCL SV IN[0].z, GSINSTANCE_ID DCL IN[1][0..3], POSITION DCL IN[2][0..3], COLOR or DCL_GS_INFO PRIM_IN TRIANGLES DCL_GS_INFO PRIM_OUT TRIANGLE_STRIP DCL_GS_INFO MAX_VERTEX_COUNT 3 /* vertices_out for gl */ DCL_SV IN[0].x, PRIMITIVE_ID DCL_SV IN[0].y, INSTANCE_ID DCL_SV IN[0].z, GSINSTANCE_ID DCL IN[1][0..3], POSITION DCL IN[2][0..3], COLOR Personally I don't have a preference, the first looks cleaner to me, but the bottom line either way is that the first three can't right now be represented by our DCL at all and the latter three will be imho ugly and hacky without an explicit keyword (SV in the example) signifying that they are in fact special inputs. z ------------------------------------------------------------------------------ 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
