[Mesa-dev] Gallium depth clamp support

[Keith Whitwell]

On Wed, 2010-07-21 at 06:54 -0700, Keith Whitwell wrote:
> On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote:
> > Hi,
> > 
> > there is a new branch gallium-depth-clamp in the main repository which
> > implements ARB_depth_clamp in Gallium. Wine uses this extension to
> > disable clipping when it's requested from a D3D9 app, so it's an
> > important one.
> > 
> > There is a new state "depth_clamp" in pipe_clip_state, and a new cap
> > PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in
> > Gallium instead, it's ok with me. There are several reasons I put the
> > enable bit in pipe_clip_state, but the most important one is that Z
> > clipping must be disabled in hardware first for it to work. It also
> > implements depth_clamp handling in cso_cache and wires up
> > ARB_depth_clamp in st/mesa.
> > 
> > The support in Draw has also been implemented, and both softpipe and
> > llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range.
> > 
> > http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp
> > 
> > Please review.
> > 
> > -Marek
> 
> 
> Marek,
> 
> This looks like a useful change. 
> 
> I'm not sure it's actually going go give the expected results for
> softpipe/llvmpipe or other users of the path you've put into the draw
> module.
> 
> In particular it looks like the spec calls for clamping depth on a
> per-pixel basis, where as this is doing it per-vertex.   
> 
> The difference is that the spec would allow a triangle with one distant
> vertex to hit the far plane and then be clamped to it, whereas your
> change means that the triangle as a whole will be altered to be in front
> of the depth plane and touch it at one vertex.
> 
> Basically, I think the draw change needs to reduced to just disabling
> depth clipping, and (if you like) a clamp(depth, 0, 1) introduced into
> softpipe/llvmpipe.  Or just don't advertise the cap for
> softpipe/llvmpipe.
> 
> Keith
> 
> 
> 
> 
> 
>  I would 
> 
>  It adds an extra branch to the clipmask computation, but it's not like
> that code is tuned at this point anyway...  I'

Hmm, random thoughts...  Just ignore, please.

Keith







:)