<div dir="ltr"><div>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.<br></div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2019 at 4:59 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a>> wrote:<br>
><br>
> Am Freitag, den 02.08.2019, 15:09 -0400 schrieb Ilia Mirkin:<br>
> > On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a><br>
> > > wrote:<br>
> > > Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:<br>
> > > > Hey Gert,<br>
> > > ><br>
> > > > I'm looking at<br>
> > > > <a href="https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f</a><br>
> > > > , which attempts to implement depth clamping (rather than<br>
> > > > clipping)<br>
> > > > with shader tricks.<br>
> > > ><br>
> > > > You're forcing the final vertex stage's position's depth to 0,<br>
> > > > and<br>
> > > > then making up for it in the frag shader with an extra varying.<br>
> > > > However won't this screw up the barycentric coordinates for<br>
> > > > perspective interpolation? i.e. won't you effectively always just<br>
> > > > get<br>
> > > > noperspective interp everywhere as a result?<br>
> > > That is probably true, I was following @kumas lead [1], in fact<br>
> > > he implemented the initial version of this code, and I only fixed<br>
> > > it up<br>
> > > for ARB_clip_control and GS and TES shaders.<br>
> > ><br>
> > > One fix I could think is maybe clamp the z value to the clip range<br>
> > > [-1,<br>
> > > 1] or [0,1] depending on the clip control z accuracy, so that the<br>
> > > error<br>
> > > only happens only for the clamped areas where the result is<br>
> > > distorted<br>
> > > anyway, what do you think?<br>
> ><br>
> > Unfortunately I can't think of a way to generically emulate it<br>
> > without implementing clipping in a geometry shader.<br>
> Yeah, when I first looked into this, this is also what I thought of.<br>
><br>
><br>
><br>
> > Basically if depth is clipped, the triangle gets split into 2 -- one<br>
> > half which is shown, and one half which isn't. When depth is clamped,<br>
> > the half which isn't shown appears as a different polygon with the<br>
> > clamped depth for all of its vertices instead. An interesting<br>
> > question is whether it should be using the original z coords for its<br>
> > barycentric coords or not -- I have no idea, and the spec doesn't<br>
> > seem to explain it in a manner which is accessible to me.<br>
> I think that the spec suggest to use the original z coords and the<br>
> clamping only happens when the depth test is executed:<br>
><br>
> RESOLUTION: ... Eliminating far and near plane clipping and<br>
> clamping *interpolated* depth values to the depth range is much<br>
> simpler to specify.<br>
><br>
> > If it should be the original z coords, then perhaps you can just<br>
> > disable clipping entirely in that case,<br>
> My guess is that hardware that disables clipping completely also<br>
> supports clamping the depth values. Our use case (virgl on top of e<br>
<br>
Yeah, that's how NVIDIA hardware works. There's a DEPTH_CLAMP_NEAR/FAR<br>
value which you set to a value between 0 and 1, based on the viewport<br>
transform, and that just clamps it prior to being supplied to the frag<br>
shader. (And separately, you disable clipping near/far planes.) Adreno<br>
hw works similarly.<br>
<br>
> GLES host that doesn't support EXT_depth_clamp) repesents the opposite:<br>
> a hardware that doesn't support disabling clipping because OpenGL (ES)<br>
> doesn't allow this and also not doesn't support depth clamping.<br>
><br>
> I still have to think about whether the interpolation really goes<br>
> wrong. I think I need to write another piglit to get an idea.<br>
<br>
Should be easy - take one of the interpolation piglit tests, and<br>
enable depth clamp without doing anything else.<br>
<br>
Cheers,<br>
<br>
-ilia<br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a></blockquote></div>