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
