Bug 94148

I'm on intel HD 4000, Mesa 11.1.2

I also get "API ERROR 23: GL_INVALID_FRAMEBUFFER_OPERATION in glDrawArrays(incomplete framebuffer)" errors in glDrawArrays.

However, as soon as I add glCheckFramebufferStatus(GL_FRAMEBUFFER) before the glDrawArrays the error is gone.

The problem does not exist with LIBGL_ALWAYS_SOFTWARE=1.
(with my own apitrace file which is too large to attach, I did not test it with the file provided by Link Mauve)

It doesn't happen on Mesa master / gallium.

Indeed, it appears to be specific to i965 (hence the component), I didn’t test it on llvmpipe at first but like Jannik I can’t reproduce it there.

I should also note that this makes some games fail to render some scenes, even though the trace doesn’t show that (I have a 5 GiB one which does, but it is a *bit* too large to include here).

I believe I stumbled on the same bug when running the WebGL CTS on Mesa 11.2's core 3.3 context. The specific failing case is https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/oes-texture-half-float.html that is flaky about 2/3 of the time. A standalone repro case is available here: https://github.com/Kangz/GLDriverBugs/blob/master/fbo_completness_caching/Main.cpp

(In reply to Corentin Wallez from comment #4)
> I believe I stumbled on the same bug when running the WebGL CTS on Mesa
> 11.2's core 3.3 context. The specific failing case is
> https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/oes-
> texture-half-float.html that is flaky about 2/3 of the time. A standalone
> repro case is available here:
> https://github.com/Kangz/GLDriverBugs/blob/master/fbo_completness_caching/
> Main.cpp

I can confirm that this happens with the repro on mesa mainline with i965/SKL, but not any st/mesa-based drivers. The error I get is

User error: GL_INVALID_FRAMEBUFFER_OPERATION in glReadPixels(incomplete framebuffer)

Created attachment 124959 [details] [review]
hackfix

The attached patch fixes both the issue in the repro program and in the originally attached trace. Perhaps more needs to be done there though.

Not 100% sure what the right fix is, but basically after you do glTexImage() on a texture attached to a fbo, we never set _NEW_BUFFERS, which in turn never triggers the fb (re)validation logic. We do basically the same thing in st_render_texture in st/mesa.

https://patchwork.freedesktop.org/patch/97860/

A non-hackpatch.

Mesa 12.0 + non-hackpatch doesn't reproduce the failure. Thanks!

Pushed as

commit da7223ebdc82609a112aae24003bbdc154c170bf
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Fri Jul 8 14:24:38 2016 -0400

    mesa: set _NEW_BUFFERS when updating texture bound to current buffers
    
    When a glTexImage call updates the parameters of a currently bound
    framebuffer, we might miss out on revalidating whether it is complete.
    Make sure to set _NEW_BUFFERS which will trigger the revalidation in
    that case.
    
    Also while we're at it, fix the fb parameter passed in to the eventual
    RenderTexture call.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94148
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>