Bug 91379 - [intel] Unrelated glXSwapBuffers() in other thread causes glReadPixels() to fail
Summary: [intel] Unrelated glXSwapBuffers() in other thread causes glReadPixels() to fail
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.5
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2015-07-18 00:10 UTC by Steinar H. Gunderson
Modified: 2015-07-18 01:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Steinar H. Gunderson 2015-07-18 00:10:56 UTC

I'm trying to get CasparCG (a broadcast graphics system) to work on my Haswell laptop. It is unstable, frequently crashing after a minute or so. I filed a CasparCG bug about it (https://github.com/CasparCG/Server/issues/364), but I am increasingly leaning towards a driver bug.

CasparCG keeps multiple contexts. They are unrelated in that they never communicate (according to upstream) but they share lists (seemingly an artifact of SFML, the windowing system in use).

Essentially, the error is that glReadPixels() (taking the fast path, from a 2D texture to a PBO) fails with GL_INVALID_OPERATION. Empirically, this only happens in the case where another thread is busy doing glXSwapbuffers() (on a different context). I don't understand the full code here, but it seems that glReadPixels() internally needs to resolve a clear in the texture, and internally it needs a renderbuffer to do that, and this renderbuffer somehow ends up becoming the dummy renderbuffer and everything fails. (The _mesa_error being called is the one in fbobject.c:2750, namely “glFramebufferRenderbuffer(renderbuffer %u)”.) It does also seems suspect that the resolve is emitting stuff to the batch buffer while the other thread is busy resetting the batch buffer, although the internals here are beyond me (I don't know if these are the same buffer, for instance).

The backtraces of the two relevant threads, with a breakpoint on fbobject.c:2750:
Thread 4 (Thread 0x7fffc8c9e700 (LWP 29321)):
#0  _mesa_FramebufferRenderbuffer (target=target@entry=36009, attachment=attachment@entry=36064, renderbufferTarget=renderbufferTarget@entry=36161, 
    renderbuffer=14247) at ../../../../src/mesa/main/fbobject.c:2750
#1  0x00007fffc8079d0b in brw_meta_resolve_color (brw=0x114c51d7a028, mt=0x114c4eec3b00) at ../../../../../../../src/mesa/drivers/dri/i965/brw_meta_fast_clear.c:681
#2  0x00007fffc80cec35 in intel_miptree_resolve_color (brw=brw@entry=0x114c51d7a028, mt=<optimized out>)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1613
#3  0x00007fffc80131fc in intel_update_state (ctx=0x114c51d7a028, new_state=<optimized out>) at ../../../../../../../src/mesa/drivers/dri/i965/brw_context.c:187
#4  0x00007fffc7e247dd in _mesa_update_state_locked (ctx=ctx@entry=0x114c51d7a028) at ../../../../src/mesa/main/state.c:453
#5  0x00007fffc7e24ea1 in _mesa_update_state (ctx=ctx@entry=0x114c51d7a028) at ../../../../src/mesa/main/state.c:464
#6  0x00007fffc7e1bdc0 in _mesa_ReadnPixelsARB (x=0, y=0, width=1280, height=720, format=32993, type=33639, bufSize=2147483647, pixels=0x0)
    at ../../../../src/mesa/main/readpix.c:979
#7  0x00007fffc7e1c122 in _mesa_ReadPixels (x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, format=<optimized out>, 
    type=<optimized out>, pixels=0x0) at ../../../../src/mesa/main/readpix.c:1096
#8  0x0000000001dafd60 in caspar::accelerator::ogl::texture::impl::copy_to(caspar::accelerator::ogl::buffer&) ()
[…more casparcg code…]

Thread 5 (Thread 0x7fffbefb7700 (LWP 29334)):
#0  0x00007fffe8736237 in madvise () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffeb582d4c in TCMalloc_SystemRelease(void*, unsigned long) () from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#2  0x00007fffeb57bf08 in tcmalloc::PageHeap::DecommitSpan(tcmalloc::Span*) () from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#3  0x00007fffeb57c121 in tcmalloc::PageHeap::MergeIntoFreeList(tcmalloc::Span*) () from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#4  0x00007fffeb57c6cb in tcmalloc::PageHeap::Delete(tcmalloc::Span*) () from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#5  0x00007fffeb586963 in (anonymous namespace)::do_free_with_callback(void*, void (*)(void*)) [clone .constprop.42] ()
   from /home/sesse/nmu/Server/dependencies64/cef/lib/linux/libcef.so
#6  0x00007fffc7aea7ce in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1
#7  0x00007fffc7aeaa1b in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1
#8  0x00007fffc80c7425 in intel_batchbuffer_reset (brw=brw@entry=0x114c55e3a028) at ../../../../../../../src/mesa/drivers/dri/i965/intel_batchbuffer.c:66
#9  0x00007fffc80c7636 in brw_new_batch (brw=0x114c55e3a028) at ../../../../../../../src/mesa/drivers/dri/i965/intel_batchbuffer.c:173
#10 _intel_batchbuffer_flush (brw=brw@entry=0x114c55e3a028, file=file@entry=0x7fffc81c8ab0 "../../../../../../../src/mesa/drivers/dri/i965/intel_screen.c", 
    line=line@entry=182) at ../../../../../../../src/mesa/drivers/dri/i965/intel_batchbuffer.c:339
#11 0x00007fffc80c7adf in _intel_batchbuffer_flush (brw=brw@entry=0x114c55e3a028, 
    file=file@entry=0x7fffc81c8ab0 "../../../../../../../src/mesa/drivers/dri/i965/intel_screen.c", line=line@entry=182)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_batchbuffer.c:296
#12 0x00007fffc80d5202 in intel_dri2_flush_with_flags (cPriv=<optimized out>, dPriv=0x114c55a2b200, flags=<optimized out>, reason=<optimized out>)
    at ../../../../../../../src/mesa/drivers/dri/i965/intel_screen.c:182
#13 0x00007fffea1d2d02 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 [I believe this is glXSwapBuffers]
#14 0x000000000240a8e8 in sf::Window::display() ()
[…more casparcg code…]

Mesa 10.5.9, Debian unstable (sid).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.