On 09/28/2016 10:29 AM, Marek Olšák wrote:
On Wed, Sep 28, 2016 at 5:14 PM, Brian Paul <[email protected]> wrote:
On 09/28/2016 07:44 AM, Marek Olšák wrote:
From: Marek Olšák <[email protected]>
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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
