On Wednesday 09 December 2009 08:55:09 michal wrote: > Zack Rusin pisze: > > 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_Va > >>>>l 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 > > ? > > I think a geometry shader should have its own GS_INFO token that would > convey the information it needs, i.e. no overloading of the DCL token. > > GS_INFO PRIM_IN TRIANGLES > GS_INFO PRIM_OUT TRIANGLE_STRIP > GS_INFO MAX_VERTEX_COUNT 3 /* vertices_out for gl */
We'll be adding more of those then. Basically we'll need an extra token for every shader we have. COMPUTE_INFO WORK_GROUP_SIZE 4 4 4 /*x, y, z*/ DS_INFO DOMAIN 3 /*domain shader*/ HS_INFO MAXTESSFACTOR 3 /*hull shader*/ FS_INFO EARLYDEPTSTENCIL 1 etc. To me it looks uglier than a special decleration token that could handle all of them. ------------------------------------------------------------------------------ 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
