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

[Marek Olšák]

On Wed, Sep 28, 2016 at 8:01 PM, Brian Paul <brianp at vmware.com> wrote:
> 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.

Yeah, _IntegerColor comes from the last color buffer and it's not even
re-set to 0 in some cases. The bitmask would indeed fix that.

Marek