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

[Mathias Fröhlich]

Hi Roland,

On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote:
> Hmm actually that wasn't right, it does make a difference if the nv or
> core format enums are used, at least for texture specification (nv won't
> clamp, whereas core will) and probably for rasterization too, what a
> mess. I don't think the patches handle that right.
I thought that too and thought that we will need an other internal format
for them. One being clamped and one not.

Then I looked at the closed implementation of the company inventing this.
There, both GL_DEPTH_COMPONENT32F_NV and GL_DEPTH_COMPONENT32F do not
clamp the z values in the viewport transform, means when glDepthRangedNV
is used and n or f are outside of [0, 1], you get depth values between
unclamped n and f.
But if you take a fragment shader that writes gl_FragDepth, the output value
is clamped to [0, 1] past the fragment shader. This is again with both
enum buffer internal formats.
So, the NVidia driver does not distinguish between the buffer types, more between
the uses. And I thought I will try doing the same so far here.

That variant would be easier to achieve, treat buffers like they are
treated with the patch, alias the .._FLOAT with .._FLOAT_NV variant. Then with a
usual projection matrix you will get values that you expect from the
world -> [-1, 1] -> [n, f] range if you're not writing gl_FragDepth.
If you write gl_FragDepth, just continue what you do today - I don't know
if mesa clamps that today.

But yes, I can see the argument for doing that as specified.
So, for the gallium side, introduce a PIPE_FORMAT_Z32_FLOAT_UCLAMP and
PIPE_FORMAT_Z32_FLOAT_UCLAMP_S8X24_UINT? Other names?
What to do?

Greetings

Mathias