Bug 1160 - Context sharing between offscreen drawable and external GL context results in "createImpl ctx !ARB but ARB is used"
Summary: Context sharing between offscreen drawable and external GL context results in...
Status: RESOLVED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2.3.2
Hardware: All windows
: --- normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2015-06-01 15:41 CEST by Tom Nuydens
Modified: 2015-09-27 01:30 CEST (History)
0 users

See Also:
Type: ---
SCM Refs:
daf23d57f2f1b68c8733d3bcea23843ce5a58bfb ff90b5405b253a820643d4de820728aad37fdf8e e50190e6d300e05f083974938a4d7cc8b38ddd62 6436b49405a7436d7df4ffd83602615cb9ae10a0
Workaround: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Nuydens 2015-06-01 15:41:01 CEST 
(Originally posted in http://forum.jogamp.org/Context-sharing-between-offscreen-drawable-and-external-GL-context-td4034536.html)

My setup is as follows. I have a Java library which renders into an offscreen drawable. This library needs to be integrated into a native host application (C++, C#, ...). To do so, the Java code renders into a texture, which I then want to make available to a GL context created by the native code. I set this up as follows:

* The native code creates a GL context and makes it current
* The Java code creates an external GL context (corresponding to the native one)
* On a different thread, the Java code then creates an offscreen drawable which shares with the external GL context

For various reasons, it would be convenient if the "different thread" above could be the EDT. However, on Windows systems with NVidia GPUs, that doesn't work. After the offscreen drawable is created, the first call to display() results in an exception:

  com.jogamp.opengl.GLException: AWT-EventQueue-0: createImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.1). Requested: GLProfile[GL4bc/GL4bc.hw], current: 4.5 (Compat profile, compat[ES2, ES3, ES31], FBO, hardware) - 4.5.0 NVIDIA 347.52
    at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:377)
    at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:757)
    at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:642)
    at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:580)
    at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1263)
    at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1131)
    at jogamp.opengl.GLAutoDrawableBase.defaultDisplay(GLAutoDrawableBase.java:475)
    at com.jogamp.opengl.GLAutoDrawableDelegate.display(GLAutoDrawableDelegate.java:190)

When I use a dedicated (non-EDT) thread, this error does not occur. On an AMD GPU, either approach works fine.

I have a unit test for this issue, which I will also submit (ShareWithExternalContextTest).
Comment 1 Sven Gothel 2015-07-24 22:57:57 CEST 
See commits:
  daf23d57f2f1b68c8733d3bcea23843ce5a58bfb
  ff90b5405b253a820643d4de820728aad37fdf8e
  e50190e6d300e05f083974938a4d7cc8b38ddd62
  6436b49405a7436d7df4ffd83602615cb9ae10a0

So far the unit test passes, while using AWT-EDT
invoke later, not blocking the current GLEventListener.

However, this exposes a weakness in sharing w/ an external context,
since we cannot guarantee the state of the external master context.
The latter should be locked while creating the slave context,
which is guaranteed if using pure JOGL context/drawable semantics.

Note: The non AWT-EDT path in the test is also non-blocking.

Hence the result is sort of unstable, even if it passes.

+++

You will also note the 'masterLock' in the test code,
which does _not_ work when using AWT-EDT - reason unknown.