[Mesa-dev] Re mesa/st: add tgsi-lowering code for depth-clamp

Sat Aug 3 04:10:52 UTC 2019

Z is 0 at the near plane and 1 at the far plane, but the planes can have an
arbitrary distance from the viewer, therefore Z Is irrelevant.

W is the real distance from the viewer. The greater W is, the smaller
(farther away) the object is, because W is the divisor (which makes objects
smaller as it increases).

The W=0 plane intersects the viewer. It is exactly in the middle of the
"eye ball".

W < 0 means behind the viewer.

Marek

On Fri., Aug. 2, 2019, 21:22 Ilia Mirkin, <imirkin at alum.mit.edu> wrote:

> Compare
>
>
> generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-other-smooth-none.shader_test
>
> generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-other-smooth-none.shader_test
>
> as you can see, the first one is perspective-interpolated and has a
> lot more red and less blue (due to the depth). The second one is even,
> since depth is ignored. gl_Position.w is the same in both cases, but
> the "other" varying gets interpolated differently.
>
> I think you're right that 1/w plays into it -- you're supposed to
> divide the interpolated result by w in the frag shader. But I think
> the ij coefficients themselves are different? Not sure, it just seems
> like z has to be taken into account *somewhere* otherwise the whole
> thing can't possibly work.
>
>   -ilia
>
> On Fri, Aug 2, 2019 at 8:11 PM Marek Olšák <maraeo at gmail.com> wrote:
> >
> > IIRC, perspective interpolation is driven by W, not Z. Interpolating W
> and then computing barycentric coordinates using 1/W is what causes the
> perspective distortion.
> >
> > Marek
> >
> > On Fri, Aug 2, 2019 at 4:59 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> >>
> >> On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny <gert.wollny at collabora.com>
> wrote:
> >> >
> >> > Am Freitag, den 02.08.2019, 15:09 -0400 schrieb Ilia Mirkin:
> >> > > On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny <
> gert.wollny at collabora.com
> >> > > > wrote:
> >> > > > Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:
> >> > > > > Hey Gert,
> >> > > > >
> >> > > > > I'm looking at
> >> > > > >
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f
> >> > > > > , which attempts to implement depth clamping (rather than
> >> > > > > clipping)
> >> > > > > with shader tricks.
> >> > > > >
> >> > > > > You're forcing the final vertex stage's position's depth to 0,
> >> > > > > and
> >> > > > > then making up for it in the frag shader with an extra varying.
> >> > > > > However won't this screw up the barycentric coordinates for
> >> > > > > perspective interpolation? i.e. won't you effectively always
> just
> >> > > > > get
> >> > > > > noperspective interp everywhere as a result?
> >> > > > That is probably true, I was following @kumas lead [1], in fact
> >> > > > he implemented the initial version of this code, and I only fixed
> >> > > > it up
> >> > > > for ARB_clip_control and GS and TES shaders.
> >> > > >
> >> > > > One fix I could think is maybe clamp the z value to the clip range
> >> > > > [-1,
> >> > > > 1] or [0,1] depending on the clip control z accuracy, so that the
> >> > > > error
> >> > > > only happens only for the clamped areas where the result is
> >> > > > distorted
> >> > > > anyway, what do you think?
> >> > >
> >> > > Unfortunately I can't think of a way to generically emulate it
> >> > > without implementing clipping in a geometry shader.
> >> > Yeah, when I first looked into this, this is also what I thought of.
> >> >
> >> >
> >> >
> >> > > Basically if depth is clipped, the triangle gets split into 2 -- one
> >> > > half which is shown, and one half which isn't. When depth is
> clamped,
> >> > > the half which isn't shown appears as a different polygon with the
> >> > > clamped depth for all of its vertices instead. An interesting
> >> > > question is whether it should be using the original z coords for its
> >> > > barycentric coords or not -- I have no idea, and the spec doesn't
> >> > > seem to explain it in a manner which is accessible to me.
> >> > I think that the spec suggest to use the original z coords and the
> >> > clamping only happens when the depth test is executed:
> >> >
> >> > RESOLUTION:  ...   Eliminating far and near plane clipping and
> >> >       clamping *interpolated* depth values to the depth range is much
> >> >       simpler to specify.
> >> >
> >> > > If it should be the original z coords, then perhaps you can just
> >> > > disable clipping entirely in that case,
> >> > My guess is that hardware that disables clipping completely also
> >> > supports clamping the depth values. Our use case (virgl on top of e
> >>
> >> Yeah, that's how NVIDIA hardware works. There's a DEPTH_CLAMP_NEAR/FAR
> >> value which you set to a value between 0 and 1, based on the viewport
> >> transform, and that just clamps it prior to being supplied to the frag
> >> shader. (And separately, you disable clipping near/far planes.) Adreno
> >> hw works similarly.
> >>
> >> > GLES host that doesn't support EXT_depth_clamp) repesents the
> opposite:
> >> > a hardware that doesn't support disabling clipping because OpenGL (ES)
> >> > doesn't allow this and also not doesn't support depth clamping.
> >> >
> >> > I still have to think about whether the interpolation really goes
> >> > wrong. I think I need to write another piglit to get an idea.
> >>
> >> Should be easy - take one of the interpolation piglit tests, and
> >> enable depth clamp without doing anything else.
> >>
> >> Cheers,
> >>
> >>   -ilia
> >> _______________________________________________
> >> mesa-dev mailing list
> >> mesa-dev at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190803/59079cc9/attachment.html>