Zack Rusin pisze: > 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. > > And I agree with that. Since you provided more SV examples that make sense (though GS_INSTANCE_ID is something SM5 introduces), you should stick with SYSTEM_VALUE register file. There is nothing gross about having INPUT registers two-dimensional, and SYSTEM_VALUE one-dimensional.
------------------------------------------------------------------------------ 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
