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

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

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

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

Greetings

Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: depth-range-nv-summary.c
Type: text/x-csrc
Size: 8017 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140921/a06a15ce/attachment-0001.c>