[Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium

[Jose Fonseca]

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