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

Mon Aug 5 10:02:08 UTC 2019

Am Samstag, den 03.08.2019, 13:01 -0400 schrieb Ilia Mirkin:
> 
> Gert - your change should be all good from what I can tell
> experimentally. Although I still don't understand why.

Thanks for testing, and I think Mareks explanation is spot on.

Best, 
Gert 

> 
>   -ilia
> 
> On Sat, Aug 3, 2019 at 12:11 AM Marek Olšák <maraeo at gmail.com> wrote:
> > 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev