<div class="gmail_quote">On Mon, Jul 26, 2010 at 8:11 PM, Brian Paul <<a href="mailto:brianp@vmware.com">brianp@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5">On 07/23/2010 03:27 PM, Roland Scheidegger wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On 22.07.2010 01:27, Brian Paul wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On 07/21/2010 05:19 PM, Marek Olšák wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheidegger<<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a> <mailto:<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>>> 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. <a href="http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp" target="_blank">http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp</a> 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. </blockquote> 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. </blockquote> 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?). </blockquote> </div></div> 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. </blockquote></div> 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