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

[Gert Wollny]

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
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. 

Best, 
Gert