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