[Bug 92633] FBO creation/destruction issue in brw_meta_resolve_color causing assertion in gen8_emit_null_surface_state

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 23 03:17:37 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=92633

            Bug ID: 92633
           Summary: FBO creation/destruction issue in
                    brw_meta_resolve_color causing assertion in
                    gen8_emit_null_surface_state
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: samuel.maroy at barco.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Created attachment 119137
  --> https://bugs.freedesktop.org/attachment.cgi?id=119137&action=edit
Trace of FBO creation and destruction in brw_meta_resolve_color
(brw_meta_fast_clear.c)

Mesa triggers an assertion in gen8_emit_null_surface_state.

I've traced the issue back to the brw_meta_resolve_color function. There seems
to be a threading issue with the creation/destruction of the FBO when using
multiple contexts.
I've patched brw_meta_resolve_color (I reused _mesa_error() to dump the info)
to print out the generation and deletion of the FBO id's and I have seen the
following after a certain amount of time (sometimes after 10 seconds, sometimes
after a minute,...):

Mesa: User error: GL_FALSE in Generated FBO 2371, ctx: 0x7fff48003fe0, thread:
1933
Mesa: User error: GL_FALSE in Generated FBO 2371, ctx: 0x3765160, thread: 1927
Mesa: User error: GL_FALSE in Deleted FBO 2371, ctx: 0x3765160, thread: 1927

Right after this, the assertion triggers. The problem is probably that both
contexts point to the same FBO and that one context has already deleted the FBO
and that the other context still wants to do stuff with it.

I've included the full trace as an attachment.
I can reproduce this on both the git master and on the 11.0.3 release.

Should there be ways to workaround this issue from within our application,
please let me know. 

Regards,
Samuel


Backtrace
---------
gen8_surface_state.c:370: gen8_emit_null_surface_state: Assertion `(fieldval &
~ (((1<<((13)-(0)+1))-1)<<(0))) == 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff5e7fc700 (LWP 4256)]
0x00007fffeee02107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fffeee02107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fffeee034e8 in __GI_abort () at abort.c:89
#2  0x00007fffeedfb226 in __assert_fail_base (fmt=0x7fffeef31ce8 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x7fffd6edddc0
"(fieldval & ~ (((1<<((13)-(0)+1))-1)<<(0))) == 0",
file=file at entry=0x7fffd6edf9af "gen8_surface_state.c", 
    line=line at entry=370, function=function at entry=0x7fffd6edfb70
<__PRETTY_FUNCTION__.45075> "gen8_emit_null_surface_state") at assert.c:92
#3  0x00007fffeedfb2d2 in __GI___assert_fail
(assertion=assertion at entry=0x7fffd6edddc0 "(fieldval & ~
(((1<<((13)-(0)+1))-1)<<(0))) == 0", file=file at entry=0x7fffd6edf9af
"gen8_surface_state.c", line=line at entry=370, 
    function=function at entry=0x7fffd6edfb70 <__PRETTY_FUNCTION__.45075>
"gen8_emit_null_surface_state") at assert.c:101
#4  0x00007fffd6e0c5c7 in gen8_emit_null_surface_state (brw=<optimized out>,
width=0, height=0, samples=<optimized out>, out_offset=<optimized out>) at
gen8_surface_state.c:370
#5  0x00007fffd6df00ff in brw_update_renderbuffer_surfaces (brw=0x7fff48003fe0,
fb=0x7fff48646010, render_target_start=0, surf_offset=0x7fff48028cbc) at
brw_wm_surface_state.c:757
#6  0x00007fffd6df01f1 in update_renderbuffer_surfaces (brw=0x7fff48003fe0) at
brw_wm_surface_state.c:775
#7  0x00007fffd6dc2ff8 in check_and_emit_atom (atom=0x7fff48029400,
state=<synthetic pointer>, brw=0x7fff48003fe0) at brw_state_upload.c:667
#8  brw_upload_pipeline_state (pipeline=BRW_RENDER_PIPELINE,
brw=0x7fff48003fe0) at brw_state_upload.c:768
#9  brw_upload_render_state (brw=0x7fff48003fe0) at brw_state_upload.c:790
#10 0x00007fffd6d48c10 in brw_try_draw_prims (indirect=<optimized out>,
max_index=<optimized out>, min_index=<optimized out>, ib=<optimized out>,
nr_prims=<optimized out>, prims=<optimized out>, arrays=<optimized out>,
ctx=<optimized out>) at brw_draw.c:516
#11 brw_draw_prims (ctx=0x7fff48003fe0, prims=0x7fff5e7fb570, nr_prims=6,
nr_prims at entry=1, ib=0x0, index_bounds_valid=255 '\377',
index_bounds_valid at entry=1 '\001', min_index=0, max_index=2,
unused_tfb_object=0x0, stream=0, indirect=0x0) at brw_draw.c:606
#12 0x00007fffd6dabaf3 in brw_draw_rectlist (ctx=ctx at entry=0x7fff48003fe0,
rect=rect at entry=0x7fff5e7fb5c0, num_instances=num_instances at entry=1) at
brw_meta_fast_clear.c:201
#13 0x00007fffd6dac67f in brw_meta_resolve_color (brw=0x7fff48003fe0,
mt=0x7fff4857a0d0) at brw_meta_fast_clear.c:704
#14 0x00007fffd6e16ff5 in intel_miptree_resolve_color
(brw=brw at entry=0x7fff48003fe0, mt=<optimized out>) at intel_mipmap_tree.c:1933
#15 0x00007fffd6d3f953 in intel_resolve_for_dri2_flush
(brw=brw at entry=0x7fff48003fe0, drawable=drawable at entry=0x7fff48066ed0) at
brw_context.c:1142
#16 0x00007fffd6d41aae in intel_resolve_for_dri2_flush
(brw=brw at entry=0x7fff48003fe0, drawable=drawable at entry=0x7fff48066ed0) at
brw_context.c:1119
#17 0x00007fffd6e1e63b in intel_dri2_flush_with_flags (cPriv=<optimized out>,
dPriv=0x7fff48066ed0, flags=<optimized out>, reason=__DRI2_THROTTLE_SWAPBUFFER)
at intel_screen.c:177
#18 0x00007fffefbf96e3 in dri3_flush (psc=0x1250750, draw=0x7fff48066de0,
throttle_reason=__DRI2_THROTTLE_SWAPBUFFER, flags=3) at dri3_glx.c:572
#19 dri3_swap_buffers (pdraw=0x7fff48066de0, target_msc=0, divisor=0,
remainder=0, flush=1) at dri3_glx.c:1534
#20 0x00007fffdf6d7b52 in QGLXContext::swapBuffers (this=0x7fff48003050,
surface=0x3bbd2e0) at qglxintegration.cpp:403
#21 0x00007ffff06a58d6 in QOpenGLContext::swapBuffers (this=0x7fff48003300,
surface=<optimized out>) at kernel/qopenglcontext.cpp:902


System details
--------------
GPU: Intel(R) HD Graphics 5500 (Broadwell GT2)

OS: Debian Jessie
    mesa: Mesa 11.1.0-devel (git-7182498)
    xf86-video-intel: 2.99.917
    xorg: 1.17.1
    libdrm: 2.4.64


Patched brw_meta_resolve_color function used to generate trace
--------------------------------------------------------------
void
brw_meta_resolve_color(struct brw_context *brw,
                       struct intel_mipmap_tree *mt)
{
   struct gl_context *ctx = &brw->ctx;
   GLuint fbo, rbo;
   struct rect rect;
   pid_t tid;

   brw_emit_mi_flush(brw);

   _mesa_meta_begin(ctx, MESA_META_ALL);

   _mesa_GenFramebuffers(1, &fbo);
   tid = syscall(SYS_gettid);
   _mesa_error(ctx, GL_NO_ERROR, "Generated FBO %d, ctx: %p, thread: %d", fbo,
ctx, tid);    <------------

   rbo = brw_get_rb_for_slice(brw, mt, 0, 0, false);

   _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
   _mesa_FramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
                                 GL_COLOR_ATTACHMENT0,
                                 GL_RENDERBUFFER, rbo);
   _mesa_DrawBuffer(GL_COLOR_ATTACHMENT0);

   brw_fast_clear_init(brw);

   use_rectlist(brw, true);

   brw_bind_rep_write_shader(brw, (float *) fast_clear_color);

   set_fast_clear_op(brw, GEN7_PS_RENDER_TARGET_RESOLVE_ENABLE);

   mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
   get_resolve_rect(brw, mt, &rect);

   brw_draw_rectlist(ctx, &rect, 1);

   set_fast_clear_op(brw, 0);
   use_rectlist(brw, false);

   _mesa_DeleteRenderbuffers(1, &rbo);
   _mesa_DeleteFramebuffers(1, &fbo);
   _mesa_error(ctx, GL_NO_ERROR, "Deleted FBO %d, ctx: %p, thread: %d", fbo,
ctx, tid);   <--------------

   _mesa_meta_end(ctx);

   /* We're typically called from intel_update_state() and we're supposed to
    * return with the state all updated to what it was before
    * brw_meta_resolve_color() was called.  The meta rendering will have
    * messed up the state and we need to call _mesa_update_state() again to
    * get back to where we were supposed to be when resolve was called.
    */
   if (ctx->NewState)
      _mesa_update_state(ctx);
}

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20151023/a2812418/attachment-0001.html>


More information about the intel-3d-bugs mailing list