[Mesa-dev] Gallium depth clamp support

[Brian Paul]

On 07/21/2010 05:19 PM, Marek Olšák wrote:
> On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheidegger <sroland at vmware.com
> <mailto:sroland at vmware.com>> wrote:
>
>     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
>
>
>     One thing I was wondering does it actually make sense to call it
>     depth clamp? I think d3d10 name for once (which calls this
>     functionality depth clip though of course this means enable/disable
>     is reversed) makes more sense - this disables near/far plane
>     clipping, hence the necessity to clamp to 0/1.
>     I guess having this in clip state is ok - d3d10 puts depth clip into
>     rasterizer state, but then again d3d10 doesn't have any clip state...
>
>
> Depth clip does sound better to me, but honestly I don't care how we
> call it. If you like the D3D naming, so be it.

There's two aspects to the GL extension:
  - near/far Z clipping
  - fragment Z clamping during interpolation

I think pipe_clip_state::depth_clamp should become 
pipe_clip_state::depth_clip.

Then, I'd probably add the second part of this as 
pipe_rasterizer_state::depth_clamp to enable/disable fragment Z clamping.

GL would set both pieces of state in tandem.  I think we should have 
two pieces of state to avoid interdependencies between clip state and 
rasterization state in the drivers.

I'm not sure how this is expressed in Direct3D.

-Brian