Created attachment 121750 [details]
Trace reproducing this bug, incriminated call 1916
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
> texture-half-float.html that is flaky about 2/3 of the time. A standalone
> repro case is available here:
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]
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.
Mesa 12.0 + non-hackpatch doesn't reproduce the failure. Thanks!
Author: Ilia Mirkin <firstname.lastname@example.org>
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
Also while we're at it, fix the fb parameter passed in to the eventual
Signed-off-by: Ilia Mirkin <email@example.com>
Cc: "11.2 12.0" <firstname.lastname@example.org>
Reviewed-by: Marek Olšák <email@example.com>
Tested-by: Emmanuel Gil Peyrot <firstname.lastname@example.org>
on Feb 24, 2017 at 21:51:01.
(provided by the Example extension).