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

[Mathias Fröhlich]

Good Morning,

On Monday, September 15, 2014 20:33:17 Roland Scheidegger wrote:
> I don't really know what to do though. It looks like the implementation
> doesn't really do what the nv spec claims anyway, so it's difficult to
> even figure out what should be done...

That all gets much more interesting than I thought initially.

Yes, it would be good if somebody knowing the history can shed more light on this.

In the mean time I have just made a diff of the two specs and tried
to look at the difference. The diff file is attached and is taken from NV_ to ARB_.

IMO the most important differences are:
1. The clamping for the *NV API entrypoints.
2. The different enum values for internal formats.
3. Clamping of fragment depths with is done in ARB and current GL standard
   and avoided in NV.
4. Clamping of shader fragment depth outputs with is done in ARB and
   current GL standard and avoided in NV.
5. Interactions with ARB_depth_buffer_float:
<taken from NV_depth_buffer_float>
    The ARB and NV internal formats for floating-point depth buffers
    behave identically.  This extension optionally relaxes the clamping
    behavior of ARB_depth_buffer_float when using the NV entry points.
    If an ARB internal format is used to define a depth buffer, the
    values passed to DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV
    are not clamped to [0,1].

    Additionally, querying DEPTH_BUFFER_FLOAT_MODE_NV is allowed on a
    floating-point depth buffer created with an ARB internal format.


Lets put this together from the spec side:

Point 1 and 2 are clear IMO.
Point 5 contradicts somehow with 3 and 4 since the specified behavior
in 3 and 4 makes a difference in clamping based on the used internal
format enum. But I read in point 5 that there is no difference in these
except that the NV api entry points don't clamp their arguments.


The behavior of existing implementations:

Then there is an implementation in the wild which adheres to point 5.
Means closed NVidia does not distinguish between the two differently
speced behaviors of the internal formats and just treats them the same
like their ARB counterparts, but additionally provides the entry points
that don't clamp the input values.


So, now my interpretation:

Initially there was the NV stuff, now there are floats in the depth buffer,
so why clamp. Then, there were objections, clamping was reestablished
and we got an extension that was widely accepted and that made it into the standard.
So, people should use the new standard/ARB stuff which does what you need.
Now, there is one thing missing in ARB/plain GL. You can get way better depth
buffer resolutions for perspective projection if you would be able to get rid
of the non zero bias in the view point transform. See
http://outerra.blogspot.co.uk/2012/11/maximizing-depth-buffer-range-and.html
And you can achieve this using the NV_depth_buffer_float api entry points
that do not clip their inputs. So, from the above I would think that the
NV_depth_buffer_float variant is more or less superseded by the
ARB_depth_buffer_float variant if the depth precision issue would be solvable
without the NV api entry points. So, therefore and to cope with the conflicts,
point 5 from above was probably added to NV_depth_buffer_float:
Just use the now standard behavior like described in ARB_depth_buffer_float but
additionally provide the *NV api entry points to get rid of the non zero bias.

BTW: That's one of the reasons of the ARB_clip_control's GL_ZERO_TO_ONE
behavior - the above blog article is cited also in ARB_clip_control.

I may be biased because I am after the depth issue which is then solvable
without larger problems and on a large base of GL implementations.
We have a statement in NV_depth_buffer_float that was added close to the end
of its history that tells that is behavior should not differ that much
from ARB_depth_buffer_float.
Additionally we find an existing implementation that behaves about this way.

I would vote for implementing that, which should be mostly what the current
series implements.
But if we want to model more of the subtle differences in the specs,
I would need some directions which heading and how far to go.
Alternatively, saying that we don't want to cope with this mess in mesa
would be sad but an option.

Thoughts?

Thanks so far and Greetings

Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: depth_buffer_float.diff
Type: text/x-patch
Size: 31281 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140917/d19cb9ba/attachment-0001.bin>