I've done the tests to satisfy my own curiousity... it all works correctly as-is, it would seem. I need to go back and re-look at barycentric coordinates generation.
Gert - your change should be all good from what I can tell experimentally. Although I still don't understand why. -ilia On Sat, Aug 3, 2019 at 12:11 AM Marek Olšák <mar...@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, <imir...@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 <mar...@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 <imir...@alum.mit.edu> wrote: >> >> >> >> On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny <gert.wol...@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.wol...@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@lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
