On Wed, 2009-12-09 at 10:19 -0800, Keith Whitwell wrote: > On Wed, 2009-12-09 at 07:18 -0800, Zack Rusin wrote: > > On Wednesday 09 December 2009 10:05:13 michal wrote: > > > Zack Rusin pisze: > > > > 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. > > > > > > Can you propose a patch against p_shader_tokens.h that introduces a > > > PROPERTY token? > > > > I could do that but only if we agree it's in the name of love. > > > > So is everyone ok with a new register SV for system generated values and > > new > > declaration token called PROPERTY for shader specific properties (btw, d3d > > calls those attributes, but since attributes already have a meaning in glsl > > I > > think it'd probably wise to not try to redefine it). > > I'm OK with this general plan, though I'm not sure about these FS > properties - early depth/stencil depends on more than just the shader as > long as we continue to support legacy alphatest, for instance. This is > probably something the driver has to figure out for itself based on the > peculiarities of the hardware - some hardware may not even have such a > concept. > > In terms of the SV register file, what do we do with the existing system > values -- I'm guessing things like the FACE input semantic in fragment > shaders is now a SV, right? > > Also, how are the semantics of the SV regs specified? Is it with the > existing semantic tags? > > Finally, some APIs distinguish between system-generated values (like > face, vertex-id, etc) and system-consumed values. We use semantics tags > on outputs to denote system-consumed values, and these SVs are more like > system-generated values, right?
Another question is whether it's really a problem to have some GS inputs be 2-dimensional and some be only 1-dimensional. It looks ugly to me, but I'm a bit concerned about introducing a new register file as a response to that. Michal - do you have any feeling on how other APIs handle this? Keith ------------------------------------------------------------------------------ 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
