On Wednesday 09 December 2009 15:07:45 michal wrote: > Keith Whitwell pisze: > > 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#Sys > >>>>>>>>>>tem_ 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? > > For geometry shaders to work, you just need a separate register file for > PRIMITIVE_ID. Everything else is either 2D (and can overload existing > register files) or doesn't make sense in GS (can we have FACE semantic > there?). > > Unless Zack knows about other 1D registers that can be used in GS that > he will need, I say rename the new SYSTEM_VALUE register file to > PRIMITIVE_ID and be done with it.
There's gs_instance_id which specifies the id of the instance of the geometry shader (which is different than the global draw instance). There's also the number of vertices that the geometry shader works on (1 points, 2 lines, 3 triangles, 6 triangle adjacency etc) (which although is a readable variable in glsl, is something that is encoded in D3D by the way of encoding the input primitive in the shader). (plus of course there are the properties of the shader e.g. input primitive, output primitive and max number of vertices that it emits). What Keith is referring though is the fact that our input layout is going to be a bit difficult because for geometry shader it's DCL SV[0].x, PRIMITIVE_ID DCL SV[1].y, GS_INSTANCE_ID DCL IN[0][0..n], POSITION DCL IN[1][0..n], COLOR so whether you have SV or not is not the issue, it's the fact that we have different dimensional inputs that is not ideal. Right now I don't really see a way of getting rid of that. 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
