----- 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. > > Wait, where does it do that? When I search through tgsi_ureg.c for > "UsageMask", all it shows are assignments of TGSI_WRITEMASK_XYZW to > the > UsageMask property.
ah. I may be lying. But I'm pretty sure I wrote such code somewhere, sometime. Let me dig it. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
