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

[Roland Scheidegger]

Am 15.09.2014 16:57, schrieb Roland Scheidegger:
> Am 15.09.2014 16:41, schrieb Roland Scheidegger:
>> Am 14.09.2014 16:07, schrieb Mathias.Froehlich at gmx.net:
>>> From: Mathias Fröhlich <Mathias.Froehlich at gmx.net>
>>>
>>> Will be used in the implementation of NV_depth_buffer_float.
>>>
>>> Signed-off-by: Mathias Froehlich <Mathias.Froehlich at web.de
>>> ---
>>>  src/mesa/main/glformats.c | 18 ++++++++++++++++++
>>>  src/mesa/main/glformats.h |  3 +++
>>>  2 files changed, 21 insertions(+)
>>>
>>> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
>>> index 00478f9..16f7d6b 100644
>>> --- a/src/mesa/main/glformats.c
>>> +++ b/src/mesa/main/glformats.c
>>> @@ -983,6 +983,24 @@ _mesa_is_depth_or_stencil_format(GLenum format)
>>>  
>>>  
>>>  /**
>>> + * Test if the given image format is a float depth format.
>>> + */
>>> +GLboolean
>>> +_mesa_is_float_depth_format(GLenum format)
>>> +{
>>> +   switch (format) {
>>> +      case GL_DEPTH_COMPONENT32F:
>>> +      case GL_DEPTH_COMPONENT32F_NV:
>>> +      case GL_DEPTH32F_STENCIL8:
>>> +      case GL_DEPTH32F_STENCIL8_NV:
>>> +         return GL_TRUE;
>>> +      default:
>>> +         return GL_FALSE;
>>> +   }
>>> +}
>>> +
>>> +
>>> +/**
>>>   * Test if an image format is a supported compressed format.
>>>   * \param format the internal format token provided by the user.
>>>   * \return GL_TRUE if compressed, GL_FALSE if uncompressed
>>> diff --git a/src/mesa/main/glformats.h b/src/mesa/main/glformats.h
>>> index 7b03215..a960786 100644
>>> --- a/src/mesa/main/glformats.h
>>> +++ b/src/mesa/main/glformats.h
>>> @@ -93,6 +93,9 @@ extern GLboolean
>>>  _mesa_is_depth_or_stencil_format(GLenum format);
>>>  
>>>  extern GLboolean
>>> +_mesa_is_float_depth_format(GLenum format);
>>> +
>>> +extern GLboolean
>>>  _mesa_is_compressed_format(struct gl_context *ctx, GLenum format);
>>>  
>>>  extern GLenum
>>>
>>
>> I'm amazed that the format enums are different. ARB_depth_buffer_float
>> claims that's due to incompatible clamping behavior as per the revision
>> history, but since the clamping behavior seems to be entirely controlled
>> by the function entry points I don't see why that makes any sense.
>> In any case the patches make sense to me but someone else should look at
>> them.
>>
>> Roland
> 
> 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.
> 
> Roland
> 

btw I'm not entirely sure everything is really correct with llvmpipe wrt
that extension (the rasterization stuff, gallium isn't involved in the
texture conversion). There's some very annoying differences how things
work between d3d10 and GL there (I suspect there's actually bugs wrt
d3d10 too especially when outputting depth from the pixel shader but so
far we got away with it).
So, with old style GL rendering, you can't actually produce depth values
outside 0/1, due to clipping. But this is no longer true since a while
for various reasons - fragment shader writing depth, ARB_depth_clamp,
clip control... There's various places such values are clamped later -
with ARB_depth_clamp if enabled they are clamped to min/max depth range
(hence not outside 0/1 unless using the nv extension), I'm pretty sure
there's also a 0/1 clamp elsewhere if you output depth from a fragment
shader.
With d3d10, you can likewise disable clipping, but there's no 0/1 clamp
anywhere in sight (just to value range reproducible by depth buffer
format), and the depth clamp is always enabled, regardless any depth
clip enable / disable bits (clamping to the zmin/max range, which is not
limited).
In any case, I think there's a lot of possiblities of subtle bugs when
trying to support this extension.

Roland