[Mesa-dev] Gallium depth clamp support

[Marek Olšák]

On Mon, Jul 26, 2010 at 8:11 PM, Brian Paul <brianp at vmware.com> wrote:

> 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.
>

Some new thoughts.

ARB_depth_buffer_float says there is always Z clamping to [0, 1], but the
range can be changed to pretty much anything using glDepthRange, and
ARB_depth_clamp doesn't specify any interaction with floating-point
zbuffers, meaning that Z clamping cannot be disabled in OpenGL. Furthermore,
I think all hardware clamps depth as it's more or less mandatory for polygon
offset, right?

So it's either to clip or not to clip, and clamping is enabled all the time,
regardless of the underlying zbuffer format.

Therefore, I will change pipe_clip_state::depth_clamp to depth_clip, as
Roland suggested, ok?

FWIW Draw clamps per-vertex depth in the offset stage (that's probably where
I saw it first), which, as we discussed, should be done per-fragment
instead.

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100806/dd4a03d1/attachment.htm>