Zack Rusin pisze: > On Monday 14 December 2009 12:49:53 michal wrote: > >> Keith Whitwell pisze: >> >>> On Mon, 2009-12-14 at 06:51 -0800, michal wrote: >>> >>>> Zack Rusin pisze: >>>> >>>>> On Monday 14 December 2009 09:29:03 Keith Whitwell wrote: >>>>> >>>>>> On Mon, 2009-12-14 at 06:23 -0800, michal wrote: >>>>>> >>>>>>> To fully support geometry shaders, we need some means to declare a >>>>>>> two-dimensional register file. The following declaration >>>>>>> >>>>>>> DCL IN[3][0] >>>>>>> >>>>>>> would declare an input register with index 0 (first dimension) and >>>>>>> size 3 (second dimension). Since the second dimension is a size, not >>>>>>> an index (or, for that matter, an index range), a new token has been >>>>>>> added that specifies the declared size of the register. >>>>>>> >>>>>> Is this a good representation? What would happen if there was: >>>>>> >>>>>> DCL IN[4][0] >>>>>> DCL IN[3][1] >>>>>> >>>>>> Presumably the "3" is always going to be "3", and it's a property of >>>>>> the geometry shader - I think Zack has a patch which adds something >>>>>> like: >>>>>> >>>>>> PROP GS_VERTICES_IN 3 >>>>>> >>>>>> Then couldn't we just have the equivalent of: >>>>>> >>>>>> DCL IN[][0] >>>>>> DCL IN[][1] >>>>>> >>>>>> with the size of the first dimension specified by the property? >>>>>> >>>>> Yea, that's what I thought the dimensional arrays should look like for >>>>> GS in TGSI (they already do in GLSL and HLSL). >>>>> >>>> Actually, GS_VERTICES_IN could be derived from GS_INPUT_PRIM property. >>>> >>>> GL_ARB_geometry_shader4 has this mapping: >>>> >>>> " >>>> >>>> Value of built-in >>>> Input primitive type gl_VerticesIn >>>> ----------------------- ----------------- >>>> POINTS 1 >>>> LINES 2 >>>> LINES_ADJACENCY_ARB 4 >>>> TRIANGLES 3 >>>> TRIANGLES_ADJACENCY_ARB 6 >>>> >>>> " >>>> >>>> But that also defeats the purpose of this patch -- INPUT registers would >>>> have implied two-dimensionality when declared inside GS. >>>> >>> We have agreed that, its true... >>> >>> So is this patch necessary? Is it sufficient to simply make the >>> statements that: >>> >>> a) Geometry shader INPUTs are always two dimensional >>> b) The first dimension is determined by the input primitive type? >>> >> Yes, thanks. >> > > k, i'm a bit confused. i can't say it's very pretty but it works so i'm cool > with any form of declarations but where does that leave the problem of > actually accessing those inputs? i mean how will we access the color of the > second vertex if multidimensional arrays don't exist. > will it be > GEOM > PROPERTY GS_INPUT_PRIMITIVE TRIANGLES > This basically says: "The first dimension of IN is 3.
> DCL IN[0], POSITION > This should read DCL IN[][0], POSITION > DCL OUT[0], POSITION > MOV OUT[0], IN[0][0] > EMIT_VERTEX > MOV OUT[0], IN[1][0] > EMIT_VERTEX > MOV OUT[0], IN[2][0] > EMIT_VERTEX > END_PRIMITIVE > END > > And the above can be already expressed with what's inside p_shader_token.h, including 2D INPUT access. ------------------------------------------------------------------------------ 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
