[Mesa-dev] [PATCH] Add support for NV_depth_buffer_float v2.

Mathias Fröhlich Mathias.Froehlich at gmx.net
Wed Sep 10 23:04:16 PDT 2014


Ian,

I will shortly send a changeset incorporating the changes, thanks for summarizing.

On Tuesday, September 09, 2014 16:11:45 Ian Romanick wrote:
> I also second Marek's comment about testing.  My recollection from
> Khronos meetings is that at least AMD GL 3.x-class hardware can only
> handle the clamped version.  That's why GL_ARB_depth_buffer_float exists.
Well, I must say that I have not tested the whole range of possible
use scenarios.
But there is a single use scenario, which is nicely described at
http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html.
So, this whole attempt to include this extension is to be able to avoid
that != 0 offset in the viewport depth transform which indeed destroys your
depth resolution in the described setup. At least the gallium drivers
exactly follow the viewport equation and by that use this (f+n)/2 offset
in the viewport transform which must happen independent of the multiplication
with the projection matrix usually happening in the shader stages.
So, you can only eliminate if you allow for symmetrical ranges,
means n = -f, which is impossible with glDepthRange() due to clamping.

So long story, I have a quick hack test already in my local piglit which
tests about what is needed for the above use case. I can polish this and
post this to piglit.

I have to say, that I am currently short on oss driver test systems.
But llvmpipe works fine with the patch and the test.
Sure others should be tested too...

May be off topic for the patch, but alternatively, since this
implementation is more driven by an application need:
Do you know any other extension that solves the above
use case of a more or less indefinite far projection matrix without
depth partitioning, with simple and fast directly routed z values
and without partially loosing early z test capabilities by
the need of a real logarithmic shader transform before writing and comparing
the depth buffer value?

Greetings

Mathias


More information about the mesa-dev mailing list