|Summary:||Framebuffer considered invalid when a draw call is done before glCheckFramebufferStatus|
|Product:||Mesa||Reporter:||Link Mauve <bugs>|
|Component:||Drivers/DRI/i965||Assignee:||Ian Romanick <idr>|
|Status:||RESOLVED FIXED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|i915 platform:||i915 features:|
Trace reproducing this bug, incriminated call 1916
Description Link Mauve 2016-02-14 18:56:23 UTC
Created attachment 121750 [details] Trace reproducing this bug, incriminated call 1916
Comment 1 Jannik Vogel 2016-04-01 14:55:47 UTC
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)
Comment 2 Marek Olšák 2016-04-05 20:13:04 UTC
It doesn't happen on Mesa master / gallium.
Comment 3 Link Mauve 2016-04-05 20:23:53 UTC
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).
Comment 4 Corentin Wallez 2016-07-04 18:58:54 UTC
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
Comment 5 Ilia Mirkin 2016-07-07 22:37:09 UTC
(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)
Comment 6 Ilia Mirkin 2016-07-08 17:39:23 UTC
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.
Comment 7 Ilia Mirkin 2016-07-08 18:25:10 UTC
https://patchwork.freedesktop.org/patch/97860/ A non-hackpatch.
Comment 8 Corentin Wallez 2016-07-11 12:52:07 UTC
Mesa 12.0 + non-hackpatch doesn't reproduce the failure. Thanks!
Comment 9 Ilia Mirkin 2016-07-12 01:28:48 UTC
Pushed as commit da7223ebdc82609a112aae24003bbdc154c170bf 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 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 <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>