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

[Roland Scheidegger]

Am 15.09.2014 18:28, schrieb 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 even if the depth range values are outside 0,1? Odd. Doesn't match
what nvidia claims to do in its depth buffer float spec (under shader
exeuction) at all. Maybe that's because they can't really distinguish
the should-clamp (ARB_depth_buffer_float) and don't-clamp
(NV_depth_buffer_float) cases properly neither...

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

No, different formats don't really make sense imho. Since the format is
really the same what might change is just some clamping behavior at
certain places.
I think though for texture specification you might need to do different
clamping depending on the type. Don't know though if nvidia does that...

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

Roland


> Greetings
> 
> Mathias
>