[Mesa-dev] [PATCH] mesa: Don't clamp GetTexImage results post RGB->L if !ClampReadColor.

[Roland Scheidegger]

Am 28.06.2011 19:21, schrieb Eric Anholt:
> On Sat, 18 Jun 2011 17:43:16 -0700, Eric Anholt <eric at anholt.net> wrote:
>> Fixes oglconform failure about our ARB_texture_float GetTexImage.
>> Note that clamping does not appear in the "Conversion to L" stage of
>> the GL 3.2 spec, and the next stage of "Final conversion" does
>> clamping according to CLAMP_READ_COLOR.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36892
> 
> So, on further thought (after trying to build testcases), I'm not sure
> what the correct answer is here.  Here's a bit I had in the test I was
> writing:
> 
> +/** @file spec/arb_color_buffer_float/getteximage.c
> + *
> + * Tests that read color clamping affects glGetTexImage as
> + * specified by ARB_color_buffer_float.
> + *
> + * From page 373 of the GL 3.2 compatibility spec ("Texture Queries"):
> + *
> + *     "No pixel transfer operations are performed on this image, but
> + *      pixel storage modes that are applicable to ReadPixels are
> + *      applied."
> + *
> + * From page 313 of the GL 3.2 compatibility spec ("Final Conversion"):
> + *
> + *     "Read color clamping is controlled by calling ClampColor (see
> + *      section 3.7.5) with target set to CLAMP_READ_COLOR. If clamp
> + *      is TRUE, read color clamping is enabled; if clamp is FALSE,
> + *      read color clamping is disabled. If clamp is FIXED_ONLY, read
> + *      color clamping is enabled if the selected read color buffer
> + *      has fixed-point components."
> + *
> + * This step of ReadPixels is part of the "pixel storage modes" block
> + * in the diagram on page 309.  However, it doesn't make a lot of
> + * sense for reading of texture components to be clamped according to
> + * whether the color buffer has fixed-point components.  Let's
> + * interpret this as meaning clamping according to whether the texture
> + * storage has fixed-point components.  Also, the interpretation of
> + * read clamping applying to GetTexImage results means that before
> + * ARB_color_buffer_float, there was no way to GetTexImage the
> + * negative components of a snorm texture, which seems odd.
> + */
> 
> Anyone have any guidance here?
>
I stumbled on that as well some time ago, and my interpretation was the
same - the spec says clamping needs to be done, but IMHO it doesn't make
sense. I don't know if this behavior was really intended however. You
could try out proprietary driver stacks to see what they do (though of
course they might not do the right thing...)

Roland