This issue is still on. the latest environment:
Kernel_version:		3.2.0_stable_20120112+
Libdrm:		(master)2.4.30-1-g66518ab5653cfdc840cd69e7b653ec05df060584
Mesa:		(8.0)9489ae8938b74551913337876656bcb9178a8905

Same happens for me
OSD: ArchLinux x86_64
Libdrm: 2.4.39-1
Mesa: 8.0.4-3
Xserver: 1.12.4-1
xf86-video-intel: 2.20.6-1

Tested also with latest GIT - same problem persists

This issue is still on Pineview.
environment:
OSD: ArchLinux  i386
Libdrm:  (master)libdrm-2.4.39
Mesa:    (9.0)03785fe360e2e63d1a63a6130e7e44141444c9d8
Xserver: (server-1.13-branch)xorg-server-1.13.0
Xf86_video_intel:  (master)2.20.12
Cairo:             (master)fab6958eff35a94cf46e38f19a7e75e10aa2b182
Libva:             (master)ab06c8cb5d41e21b03c3d17c5898fae8261113e6
Libva_intel_driver:(master)a97403b2b9b5542aa6dd311b23b562a413abd431
Kernel:  3.6.3

This issue occurs on IVB ,too.
Testing Environment:
Libdrm:         (master)libdrm-2.4.39
Mesa:           (9.0)5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0
Xserver:                (server-1.13-branch)xorg-server-1.13.0
Xf86_video_intel:               (master)2.20.12
Cairo:          (master)fab6958eff35a94cf46e38f19a7e75e10aa2b182
Libva:          (master)ab06c8cb5d41e21b03c3d17c5898fae8261113e6
Libva_intel_driver:             (master)a97403b2b9b5542aa6dd311b23b562a413abd431
Kernel:     (linux-3.2.y)9f2a940965286754f3a34d5737c3097c05db8725

The problem still exists on the driver.

environment
--------------------
Libdrm:  (master)libdrm-2.4.42
Mesa:    (9.1)mesa-9.1(git-17493b8)
Xserver: (server-1.13-branch)xorg-server-1.13.2.902
Xf86_video_intel:(master)2.21.3
Cairo:   (master)1.12.14
Libva:   (master)libva-1.1.0
Libva_intel_driver: (master)00f65b78e6de520a4820702207ce098c6b073724
Kernel:  3.8

*** 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.

See: <https://jogamp.org/bugzilla/show_bug.cgi?id=873#c4>

*** Bug 50873 has been marked as a duplicate of this bug. ***

I can attest that this problem would essentially cripple my software on Intel
GPUs.

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.

My environment:
OSD: ArchLinux x86_64
Libdrm: 2.4.61-1
Mesa: 10.5.5-1
Xserver: 1.17.1-5
xf86-video-intel: 2.99.917-5

How come this is marked as low importance?

(In reply to Elvis Stansvik from comment #14)
> I'm curious as well. I'm hitting this issue when trying to run BricsCAD, a
> proprietary CAD software, on my Lenovo X220.
> 
Same on different laptop.

> How come this is marked as low importance?
This was a bug in the bug, fixed.

Got the same issue on my HSW 4200U since only a few days. Hitting it with Steam and Chromium – seems one of them runs fine, then the next one fails. 

Chrome just falls back to software rendering for everything, Steam aborts with "intel_do_flush_locked failed: Invalid argument".

drm-intel-nightly
mesa-git
libdrm-git
xf86-video-intel
(All versions from yesterday.)

(In reply to Andreas Reis from comment #16)
> Got the same issue on my HSW 4200U since only a few days. Hitting it with
> Steam and Chromium – seems one of them runs fine, then the next one fails. 
> 
> Chrome just falls back to software rendering for everything, Steam aborts
> with "intel_do_flush_locked failed: Invalid argument".
> 
> drm-intel-nightly
> mesa-git
> libdrm-git
> xf86-video-intel
> (All versions from yesterday.)

This is a completely different problem. The original ENOENT is likely a very old bug in mesa or libdrm (for example not tracking name reuse). EINVAL is new, and I presume a cmdparser failure, so please file a new bug with a minimal example and the dmesg, you may need to use drm.debug=7.

Still broken:

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.0.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

$ uname -a
Linux copperhead 4.10.13-1-ARCH #1 SMP PREEMPT Thu Apr 27 12:15:09 CEST 2017 x86_64 GNU/Linux

$ manywin 2
2 windows
0, 0
Name: 0
  Display:     0x223e110
  Window:      0x5400002
  Context:     0x22538b0
  GL_VERSION:  3.0 Mesa 17.0.5
  GL_VENDOR:   Intel Open Source Technology Center
  GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile 
100, 0
sharing
Name: 1
  Display:     0x26e1bc0
  Window:      0x5a00002
  Context:     0x26e4080
  GL_VERSION:  3.0 Mesa 17.0.5
  GL_VENDOR:   Intel Open Source Technology Center
  GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile 
intel_do_flush_locked failed: No such file or directory

xorg-bdftopcf 1.0.5-1
xorg-server 1.19.3-2
xorg-server-common 1.19.3-2
xorg-server-xephyr 1.19.3-2
xorg-server-xwayland 1.19.3-2
xorg-xrandr 1.5.0-1
xorg-xrdb 1.1.0-2
libdrm 2.4.80-1

This is still breaking asynchronous texture/mesh/shader loading under JOGL.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1373.