[Mesa-dev] Gallium depth clamp support

[Brian Paul]

On 07/23/2010 03:27 PM, Roland Scheidegger wrote:
> On 22.07.2010 01:27, Brian Paul wrote:
>> 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.
>
> d3d10 always clamps z to viewport min/max depth, regardless if depth
> clipping is enabled or not (hmm does it really make a difference when
> depth clipping is enabled? Maybe only for OGL rasterpos and similar
> legacy stuff?).

I was also thinking of floating point Z buffers which don't 
necessarily clamp Z to [0,1].  You might want to disable Z clipping as 
well as fragment Z clamping.

-Brian