Bug 94148 - Framebuffer considered invalid when a draw call is done before glCheckFramebufferStatus
Summary: Framebuffer considered invalid when a draw call is done before glCheckFramebu...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-14 18:56 UTC by Link Mauve
Modified: 2016-07-12 01:28 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Trace reproducing this bug, incriminated call 1916 (65.06 KB, application/x-xz)
2016-02-14 18:56 UTC, Link Mauve
Details
hackfix (508 bytes, patch)
2016-07-08 17:39 UTC, Ilia Mirkin
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 <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>


bug/show.html.tmpl processed on Jan 16, 2017 at 19:18:35.
(provided by the Example extension).