[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