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? 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
