[Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
Jose Fonseca
jfonseca at vmware.com
Tue Dec 13 13:11:10 PST 2011
----- Original Message -----
>
>
> ----- Original Message -----
> > On 12/13/2011 09: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 ?
> > >
> > >
> > > Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful
> > > for the drivers? I personally don't have nothing against it, but
> > > just like to understand why it makes a difference.
> > >
> >
> > Why does TGSI_SEMANTIC_*POSITION* make a difference ?
> >
> > Right, because the position values are consumed by the fixed
> > function
> > rasterizer. So are the clip distances.
> >
> > This is not about pipe_clip_state.ucp but about what this legacy
> > cruft
> > has to be turned into if GL_CLIP_PLANEi is used instead of GLSL
> > 1.3's
> > gl_ClipDistance[i].
>
> I'm just surprised because I thought there was no more fixed function
> clipping.
Don't know what I was thinking. Please ignore.
> Can you give an example of such legacy cruft?
Jose
More information about the mesa-dev
mailing list