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<[email protected]
<mailto:[email protected]>> 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
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
