Bugzilla – Bug 41736
mesa xdemo manywin aborts with intel_do_flush_locked error
Last modified: 2015-05-22 16:18:18 UTC
Mesa xdemo manywin fails with following commits on the both IVB and SNB platform, the case finished unexpectly,end report a message:
intel_do_flush_locked failed: No such file or directory
OSD: Fedora release 13 (Goddard)
Bug detailed description:
start X,then run manywin n(n>1), the case finished unexpectly, end report a message:intel_do_flush_locked failed: No such file or directory.
1. xinit &
2. ./manywin 8
This issue is still on. the latest environment:
Same happens for me
OSD: ArchLinux x86_64
Tested also with latest GIT - same problem persists
This issue is still on Pineview.
OSD: ArchLinux i386
This issue occurs on IVB ,too.
The problem still exists on the driver.
*** Bug 18262 has been marked as a duplicate of this bug. ***
This app is doing context sharing between multiple xlib Displays, which is crazy. We don't support that. If we were to support that, we would need some even-more-global structure than the per-Display intel_screen in which to store things like the bufmgr.
Re comment 7: Eric, how else can one achieve non-blocking rendering w/ I/O,
if not using exclusive X11 display connections for multiple shared GL context and X11 events ?
Using one X11 display connection for the many shared context, one would need to add
synchronization for the X11 display commands, which is bogus.
For JOGL, we explicitly use exclusive display connections to achieve block-free multithreading.
We would love to see this fixed to enable shared GL context in a concurrent use-case,
since it is essential to many applications of our user base.
Note: The described mechanism works flawless on all other OpenGL driver implementations,
including other Mesa backends, as well with NV and AMD proprietary drivers.
Further more, the spec does not disclose such scenario, as long the display connection
references the 'same' display.
*** Bug 50873 has been marked as a duplicate of this bug. ***
I can attest that this problem would essentially cripple my software on Intel
I've worked hard to ensure that the rendering code works on every OpenGL
context I can find, but the engine itself is heavily dependent on being able
to constantly stream resources in a manner that won't block the main renderer.
Without the ability to do this, I'm essentially left with the option of not supporting Intel, which would be silly!
RE: comment 7: Eric, maybe you can store these buffer details
in a storage space accessible via a [hash] map on the unique X11 display connection name.
This is one way how we (JOGL) mitigate other issues and cache unique details regarding
the display device as referenced by multiple connections.
Sort of a display-local-storage, similar to TLS. Since I don't know Mesa's or DRM's infrastructure
I don't know whether such thing already exists.
re comment 11: .. maybe only as a slow path, if you cannot find the reference locally .. where you exit w/ said error message.
I'm curious if there has been any movement on this issue. I've gotten a few reports of this now from external users and all I can tell them is that we do not support the linux Intel driver at this time.
We require the shared context as we load all of our resources async into a master context, trying not to block the individual display rendering while we do so.
I'm curious as well. I'm hitting this issue when trying to run BricsCAD, a proprietary CAD software, on my Lenovo X220.
OSD: ArchLinux x86_64
How come this is marked as low importance?