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 <srol...@vmware.com >> <mailto:srol...@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?). Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
