[Mesa-dev] [PATCH] mesa: fix glGet size queries for L/LA/I color buffers

[Marek Olšák]

I'm going to drop this patch and will fix the problematic piglit tests
by not using the framebuffer size queries for intensity and luminance
formats.

Marek

On Mon, Mar 10, 2014 at 11:34 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Mon, Mar 10, 2014 at 6:07 PM, Brian Paul <brianp at vmware.com> wrote:
>> On 03/09/2014 01:03 PM, Marek Olšák wrote:
>>>
>>> Do you have any opinion on this patch, anyone?
>>>
>>> Marek
>>>
>>> On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>
>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>
>>>> There is no API for returning the number of luminance and intensity bits
>>>> and
>>>> the 3.3 spec doesn't seem to specify any behavior for the queries if the
>>>> format
>>>> is one of L, LA, I. It seems to be a spec bug.
>>
>>
>> I'm trying to piece together the background info on this.
>>
>> IIRC, in GL 3.3 core there are no luminance, l/a or intensity textures or
>> surfaces anymore.  And yeah, I don't see a
>> GL_FRAMEBUFFER_ATTACHMENT_LUMINANCE_SIZE query in the 3.3 compat profile
>> spec.
>>
>> So basically your patch will return a non-zero value if, for example,
>> GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE is called on a luminance buffer, right?
>
> Correct.
>
>>
>> Is that what AMD and NVIDIA's drivers do?
>
> For 8-bit luminance and intensity, AMD Catalyst returns
> RED/GREEN/BLUE_BITS=(8,0,0), but the renderbuffer and framebuffer
> attachment queries return (0,0,0).
>
> I don't think (8,0,0) is correct, but the compatibility spec doesn't
> say it's incorrect.
>
> Marek