On Wed, Sep 28, 2016 at 8:01 PM, Brian Paul <[email protected]> wrote: > 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.
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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
