----- Original Message ----- > On 12/13/2011 03:48 PM, Jose Fonseca wrote: > > ----- Original Message ----- > >> On 12/13/2011 03:25 PM, Jose Fonseca wrote: > >>> ----- Original Message ----- > >>>> On 12/13/2011 03:09 PM, Jose Fonseca wrote: > >>>>> ----- Original Message ----- > >>>>>> On 12/13/2011 12:26 PM, Bryan Cain wrote: > >>>>>>> On 12/13/2011 02:11 PM, Jose Fonseca wrote: > >>>>>>>> ----- Original Message ----- > >>>>>>>>> This is an updated version of the patch set I sent to the > >>>>>>>>> list > >>>>>>>>> a > >>>>>>>>> few > >>>>>>>>> hours > >>>>>>>>> ago. > >>>>>>>>> There is now a TGSI property called > >>>>>>>>> TGSI_PROPERTY_NUM_CLIP_DISTANCES > >>>>>>>>> that drivers can use to determine how many of the 8 > >>>>>>>>> available > >>>>>>>>> clip > >>>>>>>>> distances > >>>>>>>>> are actually used by a shader. > >>>>>>>> Can't the info in TGSI_PROPERTY_NUM_CLIP_DISTANCES be easily > >>>>>>>> derived from the shader, and queried through > >>>>>>>> src/gallium/auxiliary/tgsi/tgsi_scan.h ? > >>>>>>> No. The clip distances can be indirectly addressed (there > >>>>>>> are > >>>>>>> up > >>>>>>> to 2 > >>>>>>> of them in vec4 form for a total of 8 floats), which makes it > >>>>>>> impossible > >>>>>>> to determine which ones are used by analyzing the shader. > >>>>>> The description is almost complete. :) The issue is that the > >>>>>> shader > >>>>>> may > >>>>>> declare > >>>>>> > >>>>>> out float gl_ClipDistance[4]; > >>>>>> > >>>>>> the use non-constant addressing of the array. The compiler > >>>>>> knows > >>>>>> that > >>>>>> gl_ClipDistance has at most 4 elements, but post-hoc analysis > >>>>>> would > >>>>>> not > >>>>>> be able to determine that. Often the fixed-function hardware > >>>>>> (see > >>>>>> below) needs to know which clip distance values are actually > >>>>>> written. > >>>>> But don't all the clip distances written by the shader need to > >>>>> be > >>>>> declared? > >>>>> > >>>>> E.g.: > >>>>> > >>>>> DCL OUT[0], CLIPDIST[0] > >>>>> DCL OUT[1], CLIPDIST[1] > >>>>> DCL OUT[2], CLIPDIST[2] > >>>>> DCL OUT[3], CLIPDIST[3] > >>>>> > >>>>> therefore a trivial analysis of the declarations convey that? > >>>> No. Clip distance is an array of up to 8 floats in GLSL, but > >>>> it's > >>>> represented in the hardware as 2 vec4s. You can tell by > >>>> analyzing > >>>> the > >>>> declarations whether there are more than 4 clip distances in > >>>> use, > >>>> but > >>>> not which components the shader writes to. > >>>> TGSI_PROPERTY_NUM_CLIP_DISTANCES is the number of components in > >>>> use, > >>>> not > >>>> the number of full vectors. > >>> Lets imagine > >>> > >>> out float gl_ClipDistance[6]; > >>> > >>> Each a clip distance is a scalar float. > >>> > >>> Either all hardware represents the 8 clip distances as two 4 > >>> vectors, and we do: > >>> > >>> DCL OUT[0].xywz, CLIPDIST[0] > >>> DCL OUT[1].xy, CLIPDIST[1] > >>> > >>> using the full range of struct tgsi_declaration::UsageMask [1] or > >>> we represent them as as scalars: > >>> > >>> DCL OUT[0].x, CLIPDIST[0] > >>> DCL OUT[1].x, CLIPDIST[1] > >>> DCL OUT[2].x, CLIPDIST[2] > >>> DCL OUT[3].x, CLIPDIST[3] > >>> DCL OUT[4].x, CLIPDIST[4] > >>> DCL OUT[5].x, CLIPDIST[5] > >>> > >>> If indirect addressing is allowed as I read bore, then maybe the > >>> later is better. > >>> > >>> I confess my ignorance about clipping and maybe I'm being dense, > >>> but I still don't see the need for this > >>> TGSI_PROPERTY_NUM_CLIP_DISTANCES. Could you please draft an > >>> example TGSI shader showing this property (or just paste one > >>> generated with your change)? I think that would help a lot. > >>> > >>> > >>> Jose > >>> > >>> > >>> [1] I don't know if tgsi_dump pays much attention to > >>> tgsi_declaration::UsageMask, but it does exist. > >> UsageMask might work, but before that can be considered a viable > >> solution, someone will need to make it possible to actually > >> declare > >> it > >> from ureg. As it is, ureg is hardcoded to set UsageMask to xyzw > >> no > >> matter what on all declared inputs and outputs. > > ureg automatically fills the UsageMask from the destionation > > register masks, since it easy to determine from the opcodes. > > > > Which leads me to my second point, if indirect addressing of > > CLIPDIST is allowed, then we can't really pack the clip distance > > as 4-elem vectors in TGSI: not only the syntax would be very > > weird, but it would create havoc on all tgsi-translating code that > > makes decisions based on indirect addressing of registers. > > > > That is, > > > > float gl_ClipDistance[6]; > > > > gl_ClipDistance[i] = foo; > > > > would become > > > > DCL OUT[0].x, CLIPDIST[0] > > DCL OUT[1].x, CLIPDIST[1] > > DCL OUT[2].x, CLIPDIST[2] > > DCL OUT[3].x, CLIPDIST[3] > > DCL OUT[4].x, CLIPDIST[4] > > DCL OUT[5].x, CLIPDIST[5] > > MOV OUT[ADDR[0].x].x, foo > > > > and the info from TGSI_PROPERTY_NUM_CLIP_DISTANCES can be obtained > > by walking the declaration (which can/should be done only once in > > tgsi_scan). > > > > But this just doesn't look like it would ever work: > > > > DCL OUT[0].xyzw, CLIPDIST[0] > > DCL OUT[1].xy , CLIPDIST[1] > > MOV OUT[ADDR[0].x].????, foo > > > > Jose > > If ureg automatically fills the UsageMask from the accessed > components, > it's probably a better solution than the property. > > About the indirect addressing of components: the GLSL compiler lowers > indirect addressing of the gl_ClipDistance array to indirect > addressing > of the 2 vec4s, combined with conditional moves to the different > components. Which is okay, because although indirect addressing of > gl_ClipDistance is allowed by the GLSL specification, meaning have to > support it, it's not something that's actually useful in practical > situations.
It sounds a bit complicated -- the lowered indirect addressing code will certainly result in inefficient code for software rendering (e.g, draw module + llvm), but that alone is probably not reason to be different. Could everybody confirm that all hardware uses 2 vec4s for clip distances and is not able to natively do indirect addressing? Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
