[Mesa-dev] [PATCH 1/3] mesa: add gl_framebuffer::_Color0IsInteger

[Brian Paul]

On 09/28/2016 10:29 AM, Marek Olšák wrote:
> On Wed, Sep 28, 2016 at 5:14 PM, Brian Paul <brianp at vmware.com> wrote:
>> On 09/28/2016 07:44 AM, Marek Olšák wrote:
>>>
>>> From: Marek Olšák <marek.olsak at amd.com>
>>>
>>> The other flag seems to have a slightly different meaning.
>>
>>
>> I don't recall what the GL spec says w.r.t. mixing floating point and
>> integer color buffers.  I suspect it may be implementation dependent.
>
> Mixing float and integer color buffers is allowed.
>
>>
>> I wonder if we should replace _IntegerColor and _Color0IsInteger with a
>> bitmask indicating which color buffers are integer-valued.  That is:
>>
>> struct gl_framebuffer {
>>     ...
>>     GLbitfield _IntegerColorBuffers;
>>     ...
>> };
>>
>>
>> _mesa_test_framebuffer_completeness()
>> ...
>> if (_mesa_is_format_integer_color(attFormat))
>>      fb->_IntegerColorBuffers |= (1 << i);
>>
>>
>> What do you think?
>
> It depends on what it would be good for. Alpha-test,
> alpha-to-coverage, and alpha-to-one only apply to color buffer 0.

The point is to not have two similar but slightly different fields 
(_IntegerColor and _Color0IsInteger).

I just hacked up a piglit test to see what's returned by the 
glGetBooleanv(GL_RGBA_INTEGER_MODE_EXT) query. nvidia returns true if 
any attachment in a mixed float/int fbo is integer valued.  Mesa gets 
this wrong and returns 0 for (int,float) but 1 for (float,int).  The 
logic for computing _IntegerColor in 
_mesa_test_framebuffer_completeness() is wrong.

The bitmask would fix this.

-Brian