Bug 873 - Shared GLContext Usage Causes: 'intel_do_flush_locked: No such file or directory' with Intel's Mesa 9.2.1 Backend for [Sandybridge/Ivybridge] on GNU/Linux
Summary: Shared GLContext Usage Causes: 'intel_do_flush_locked: No such file or direct...
Status: CONFIRMED
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2
Hardware: pc_x86_64 linux
: --- normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks: 776
  Show dependency treegraph
 
Reported: 2013-10-25 15:17 CEST by Stephen Ranger
Modified: 2014-12-05 19:03 CET (History)
2 users (show)

See Also:
Type: ANNOTATION
SCM Refs:
Workaround: ---


Attachments
opengl debug output (233.44 KB, text/plain)
2013-10-25 15:17 CEST, Stephen Ranger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Ranger 2013-10-25 15:17:39 CEST
Created attachment 529 [details]
opengl debug output

When running an OpenGL application with a simple Vertex Buffer Object (single Quad with lighting disabled, color at each point (interpolated by OpenGL) and no shader, once the first frame is completed it crashes with the message "intel_do_flush_locked: No such file or directory". The JOGL VBO demo works fine; not sure what I'm doing differently. Unfortunately it is using an in-house visualization library and not sure what is causing the error. Stepping through the code, it looks like the Class loader is looking for glFinish in the native libraries, finds it, then crashes.

Report posted on Intel Community Forums (couldn't find official bug tracker for Intel)

https://communities.intel.com/thread/45810


Hardware/Software setup
System: Intel NUC DC53427HYE (http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-kit-dc53427hye.html)
CPU: i5-3427U (http://ark.intel.com/products/64903/)
GPU: integrated Intel HD 4000 (in CPU)
GPU Driver: 
   libva-intel-vaapi-driver 1.0.20-2
   xserver-xorg-video-intel 2:2.99.904-0ubuntu2
   mesa 9.2.1-1ubuntu3
Comment 1 Sven Gothel 2013-10-30 22:37:43 CET
Just for reference ..

+++

Yours (buggy:

GL Version     3.0 (Compat profile, arb, ES2 compat, FBO, hardware) - 3.0 Mesa 9.2.1 [GL 3.0.0, vendor 9.2.1 (Mesa 9.2.1)]
Quirks         [NoDoubleBufferedPBuffer, NoSetSwapIntervalPostRetarget]
Impl. class    jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR      Intel Open Source Technology Center
GL_RENDERER    Mesa DRI Intel(R) Ivybridge Mobile
GL_VERSION     3.0 Mesa 9.2.1
GLSL           true, has-compiler-func: true, version: 1.30 / 1.30.0

+++

Mine (buggy as well):

GL Profile     GLProfile[GL2ES2/GL3.hw]
GL Version     3.1 (Core profile, arb, ES2 compat, ES3 compat, FBO, hardware) - 3.1 (Core Profile) Mesa 9.2.1 [GL 3.1.0, vendor 9.2.1 ((Core Profile) Mesa 9.2.1)]
Quirks         [NoDoubleBufferedPBuffer, NoSetSwapIntervalPostRetarget]
Impl. class    jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR      Intel Open Source Technology Center
GL_RENDERER    Mesa DRI Intel(R) Sandybridge Desktop 
GL_VERSION     3.1 (Core Profile) Mesa 9.2.1
GLSL           true, has-compiler-func: true, version: 1.40 / 1.40.0

- Intel(R) Core(TM) i3-2105 CPU @ 3.10GHz
- HD3000 in CPU Sandybridge
- http://ark.intel.com/products/55448/Intel-Core-i3-2105-Processor-3M-Cache-3_10-GHz

- Ubuntu 13.10 (kernel 3.11.0-13-generic)
- mesa 9.2.1

+++
+++

Working w/ GL 3.1 and ES 3.0
  com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT

Buggy:
  com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2NEWT1

  - 1st 'master' context works
  - 2nd 'slave' context does not work - sharing of 'master'!
Comment 2 Sven Gothel 2013-10-30 22:40:38 CET
Last message (as reported):
"intel_do_flush_locked failed: No such file or directory"
Comment 3 Sven Gothel 2013-10-30 23:56:51 CET
http://www.bentasker.co.uk/documentation/linux/157-intel-do-flush-locked-on-kubuntu-12

"What causes it

Basically, the call 'intel_do_flush_locked' isn't supported in earlier kernels (such as the one that ships with K/Ubuntu), so the system is trying to run a command that just doesn't exist (in simple terms)."

This is not the issue on my Ubuntu 13.10 setup I guess,
i.e. the kernel does expose the method/command.
Comment 4 Sven Gothel 2013-10-30 23:57:11 CET
http://dri.freedesktop.org/wiki/Intel/
https://01.org/linuxgraphics/
https://01.org/linuxgraphics/documentation/how-report-bugs-0

Bugs are already reported:
<https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=intel_do_flush_locked>

i.e.:

<https://bugs.freedesktop.org/show_bug.cgi?id=41736>

Especially comment of Eric Anholt (assignee):
  <https://bugs.freedesktop.org/show_bug.cgi?id=41736#c7>
"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."

This matches our test case w/ context sharing in TestSharedContextVBOES2NEWT1,
where we share w/ an explicit offscreen/dummy drawable/context w/ own Display device.

However, even TestSharedContextVBOES2NEWT3 doesn't work,
since NEWT's X11 WindowDriver does create it's own display connection
to decouple X11 display locking:
   /jogl/src/newt/classes/jogamp/newt/driver/x11/WindowDriver.java line 75 (renderDevice).

If this is the final stance of Intel, we have to either claim concurrent context sharing on X11
with Intel's Mesa backend is not supported - or add a sluggish 'same display connection' code-path.

Problem is the 'non-blocking' part. 
We don't use X11 locking, and lock on the application level, which is good.

However, we don't like to block GL rendering w/ windowing commands or input events
hence the extra display connection.
Such display connection shall also be exclusive to one context to not block 
another context - otherwise we would have not proper mult
Comment 5 Sven Gothel 2013-10-31 00:08:03 CET
For reference ..

<https://bugs.freedesktop.org/show_bug.cgi?id=41736#c8>:

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>
Comment 6 Sven Gothel 2013-10-31 00:48:05 CET
Type: ANNOTATION, since this is not our bug.
Comment 7 Sven Gothel 2013-10-31 02:06:44 CET
But 776 is related, i.e. 'convenient context sharing'
Comment 8 Sven Gothel 2013-10-31 02:07:05 CET
(In reply to comment #7)
> But 776 is related, i.e. 'convenient context sharing'

Bug 776
Comment 9 Harvey Harrison 2014-11-12 04:58:54 CET
As a (terrible) workaround if you really need a jogl-using application to work, you can force software rendering and hope for the best.

export LIBGL_ALWAYS_SOFTWARE=1
{start you application}

This has at least made jaamsim usable for some users, be warned that mesa swrast only supports up to OpenGL 2.1 at the moment.

Harvey