[Mesa-dev] Gallium depth clamp support
Keith Whitwell
keithw at vmware.com
Fri Aug 6 09:06:47 PDT 2010
On Fri, 2010-08-06 at 08:29 -0700, Marek Olšák wrote:
> 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.
I took my eye off the ball slightly here. I'd generally argue that
there is no distinction between clipping and the rest of rasterization,
at least in the abstraction of the graphics pipeline we're using in
gallium.
At the highest level, the pipeline is a set of programmable units (ie
the VS, GS and FS) separated by chunks of fixed-functionality. We
really shouldn't try to further subdivide those chunks as various
different hardware will chop them up differently. But the
fixed-function/programmable barrier is fairly universal.
So we just give a single name to each bit of fixed-functionality between
each pair of shader units, plus those at the beginning and end of the
pipeline.
Then, rasterizer is just the name we give to the fixed-function unit
which comes between the end of the geometry shader and the beginning of
the fragment shader.
With that definition, it can be seen to include clipping, viewport
transformation, RHW divide, etc, etc. It's a fairly large set of state
largely because GL has so much legacy functionality in this area.
So basically I'd argue to put these flags into the rasterizer CSO (which
is a CSO), and continue to view pipe_clip_state as data parameterizing
that CSO.
We might want to consider having a user_clip_enable bit in
pipe_rasterizer_state to indicate whether pipe_clip_state should be
examined.
Keith
More information about the mesa-dev
mailing list