[Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

Roland Scheidegger sroland at vmware.com
Mon Sep 22 07:42:30 PDT 2014


Am 21.09.2014 16:40, schrieb Mathias Fröhlich:
> 
> Hi,
> 
> On Thursday, September 18, 2014 03:56:11 Roland Scheidegger wrote:
>> I agree it is something which would be nice to have in mesa, however I'm
>> not really a big proponent of implementing some half-baked bogus mess
>> extension, which is further more completely different to what the only
>> available implementation actually does.
> Me neither, I initially thought that it's just much more clear what to do.
> 
>> Just to make this clear, are you saying that blob really clamps all
>> float depth values to [0,1] when
>> - using teximage2d
>> - writing depth from fragment shader
>> - using interpolated depth (with depth_clamp enabled maybe?)
> 
> I have never tried the teximage2d claims.
> 
> But I have tried with and without writing the gl_FragDepth.
> I have now rechecked this on nvidia and the amd blob.
> 
> I have to correct the claim somehow - I previously probably only tested gl_FragDepth
> clamping with depthrange set to [0, 1]. But actual behavior is even nicer, as
> NVidia does not make any difference between the two texture
> formats in its behavior. Everything is clamped to be within min(zNear, zFar)
> and max(zNear, zFar) of glDepthRangedNV(zNear, zFar).
> It does not matter if you write the gl_FragmentDepth or use the fixed function
> depth processing. And this is independent of the depth texture format
> being GL_DEPTH_COMPONENT32F or GL_DEPTH_COMPONENT32F_NV.
This is what d3d10 specifies, so I guess this behavior isn't all that
surprising.

> 
>> So I think I'm missing something why can you even clear the depth buffer
>> to a value outside [0,1] then?
> The fixed function depth values are just routed through and they utilize
> in any case the whole range between near and far.
> Or, I may not get your question right ...
Because you said the values are clamped to [0,1] in the depth buffer I
thought it wouldn't make sense. But you clarified it that it is indeed
just clamped to near/far range so yes this makes sense.

> 
>> In any case, I'm not really against this, though I'm not really the
>> right person to judge this in any case. I think though at the very least
>> there should probably be big warning comments in the code mentioning it
>> doesn't actually implement what the extension says and why. It would
>> probably be better though if nvidia would fix up their extension spec
>> (or failing that, someone could make some proper non-vendor extension).
>> I wonder what AMD is doing on their blob. I suspect though they just do
>> the different non-clamping entry points...
> It took some work to convince piglit to think centos 6 is a recent enough system.
> I have now within piglit also done a test program to explore the
> behavior of the implementations. That's attached.
> So, it looks like the AMD blob changes it's behavior based on the
> internal format. The _NV variants behave the same like the nvidia
> driver treats them. The ARB internal formats, behave like if the
> glDepthRangedNV call had behaved like glDepthRange.
> There is a define in the attached test that makes either the amd or the
> nvidia variant succeed.
> 
> The nvidia behavior is more like the last addition to the NV_ spec that
> tells that there should be no difference between the non _NV float formats.
> The AMD blob more tries to model one of the contradicting difference in the
> specs.
> 
> The nvidia behavior looks like the least intrusive for the driver.
> You get the GL standard behavior in the case of the non NV API entry points
> since you are not able to go beyond [0, 1] in the depth range.
> But if you manage to get near and far values beyond [0, 1] into the driver
> by using glDepthRangedNV, you get everything clamped to these.
> 

Yes, that makes sense, except I believe it's not quite true. So, with
ARB_depth_buffer_float, you can never get values outside [0,1] in the
depth buffer no matter what. However, with NV_depth_buffer_float and
clamping to near/far range this is not true even if you don't use the
new entry points - e.g. polygonoffset could get you values outside [0,1]
(*), as could TexImage2D and probably a million other things, thus this
would break backward compatibility.
Though reading the interaction with ARB_depth_buffer_float again
("optionally relaxes the clamping behavior of ARB_depth_buffer_float
when using the NV entry points") I'm really confused. Does that mean you
only get the non-clamping behavior if you've used the new entry points
(so the implementation switches behavior depending on if the last
depthrange called was an nv one or not??? Now that would be just crazy).

This is imho really a big big mess, and apparently amd interpreted it
differently to nvidia. There doesn't seem to be a way to actually do it
right. Maybe nvidia didn't care about backward compatibility (because
with just the ARB extension, float depth buffers are kinda useless
anyway, and of course with fixed function you still get clamping in any
case).

(*) according to OGL rules. I suspect though what nvidia actually does
is d3d10 behavior, that is the near/far clamping is always done (no
matter where the depth value comes from, shader z or interpolated,
regardless of depth_clamp enabled or not) at the time the depth values
enter the depth buffer test. For OGL clamping at that point is only
supposed to happen if depth_clamp is enabled.

Roland



More information about the mesa-dev mailing list