OpenGL error 1282 at GLContext.release()

Hello,

I just updated the 3D renderer in Processing from an older version of jogl2 (rc2, I think) to rc5. Things were working quite well with rc2, the only annoying issue was an OpenGL error 1282 (invalid value), apparently triggered by a contest.release() call at the end of my drawing loop. It seems that this error doesn't have any observable consequence, but I still would like this message to go away.

After the update to rc5, I still get the error. I create my OpenGL context as follows:

profile = GLProfile.getMaxFixedFunc();

capabilities = new GLCapabilities(profile);
capabilities.setSampleBuffers(true);
capabilities.setNumSamples(4);

AWTGraphicsScreen screen = (AWTGraphicsScreen)AWTGraphicsScreen.createDefault();
AWTGraphicsConfiguration config = (AWTGraphicsConfiguration)GraphicsConfigurationFactory
  .getFactory(AWTGraphicsDevice.class).chooseGraphicsConfiguration(capabilities, capabilities, null, screen);
NativeWindow win = NativeWindowFactory.getNativeWindow(pg.parent, config);    
   
GLDrawableFactory factory = GLDrawableFactory.getFactory(profile);
drawable = factory.createGLDrawable(win);
context = drawable.createContext(null);

Any suggestions?

forgot to mention, I observed this issue only on windows (win7 64 bits)

On 02/14/2012 04:44 AM, ac [via jogamp] wrote:
>
>

well .. the code snippet doesn't tell me a thing (no obvious bug).

> forgot to mention, I observed this issue only on windows (win7 64 bits)

This is a poor bug report, see Wiki/FAQ Bugreport.

You may also attach/provide a working sample code reproducing the behavior,
since you cannot expect people to decorate your lines to attempt to
reproduce anything. Sorry to be harsh.

You may also try running with the properties

      -Djogl.debug.DebugGL -Djogl.debug.TraceGL

and if GLSL is involved

      -Djogl.debug.GLSLCode (in case you use our ShaderUtils)

this will help pinpoint the offending GL command, hopefully.

~Sven

Hi

Please follow Sven's suggestion:
http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

At least, enable the debug.

sorry  guys, I will follow the bug reporting guidelines and will post more info about this soon

I was not able to create a small application that reproduces this issue, perhaps is the result of how the gl context and threads are initialized in Processing. Simple jogl apps running on the same system, like the gears example, don't show the opengl error. The system specs are:

Windows 7 professional, SP1
NVidia geforce GTX 570 with driver version 285.62

I enabled debugging and the output is here: http://pastebin.com/GSk0YJn2

The OpenGL error 1282 (which I get with glGetError) appears between the lines

"ExtensionAvailabilityCache: getGLExtensions() called"

and

"setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true"

I see a couple of exceptions being thrown a bit earlier. Removing the context.release() call at the end of my rendering loop makes the OpenGL error disappear, but the debug output seems identical (http://pastebin.com/qikRUmzq).

On 02/15/2012 02:36 AM, ac [via jogamp] wrote: Hmm .. I just have fixed bugs in this area :),
maybe it's related.

Pls try the latest JOGL/Gluegen autobuild,
I have just aggregated here:

<http://jogamp.org/deployment/archive/master/gluegen_493-joal_285-jogl_660-jocl_561/archive/jogamp-all-platforms.7z>

~Sven

Cool, thanks. I will give it a try and will let you know how it goes.

BTW, I'm also trying to re-work the jogl initialization in Processing, (see this other post http://forum.jogamp.org/need-to-create-GLCanvas-twice-td3745696.html), so this issue might become irrelevant eventually.

The OpenGL error 1282 still shows up, between the "ExtensionAvailabilityCache: getGLExtensions() called" and the before the program starts spitting "setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true" continuously:

...
GLDebugMessageHandler.init(false)
GLDebugMessageHandler: GL DEBUG not set in ARB ctx options: 4.2 (Compatibility profile, arb, ES2 compatible, hardware) - 4.2.0
GLDebugMessageHandler.init(false) .. n/a
ExtensionAvailabilityCache: getGLExtensions() called
OpenGL error 1282 at bot endDraw(): invalid operation
setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true
setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true
setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true
setRealized: jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable true == true
...

Again, to have this error printing out everytime the app starts it is not a major problem but more like an annoyance. It might be pointing to some error we have in Processing regarding thread handling...

On 02/15/2012 04:09 PM, ac [via jogamp] wrote: Hmm ..

so pls run with the DebugGL and TraceGL props as I have recommended.
        -Djogl.debug.DebugGL -Djogl.debug.TraceGL

and do a println("lala "+gl.getGLError()); right after JOGL init,
you may force such via the no more required GLProfile.initSingletion();

Then let's see who causes the gl error.

If it's within our initialization, ie glGetExtensions() etc ..
it's funny. Check the output of TestGLProfile01NEWT with the debug flags.
Do all profiles have extensions listed ?

https://jogamp.org/chuck/view/fwd/job/jogl/661/label=win7-x86_64-nvida/testReport/com.jogamp.opengl.test.junit.jogl.acore/TestGLProfile01NEWT/testGLProfileDefault/?

See the 'raw console output' (link) and go to 'testGLProfileDefault'

You should see things like:
GL_EXTENSIONS  265
  .....
GLX_EXTENSIONS 25
  .....

~Sven

Ok, with the debug and trace options enabled, I get the following:

glGetString(<int> 0x1F00) = NVIDIA Corporation
glGetError() = 0
glGetString(<int> 0x1F00) = NVIDIA Corporation
glGetString(<int> 0x1F01) = GeForce GTX 570/PCI/SSE2
glGetString(<int> 0x1F02) = 4.2.0
glGetString(<int> 0x1F03) = GL_ARB_base_instance <snip> ...
glBlendEquation(<int> 0x8006)
glGetIntegerv(<int> 0xD33, <[I>, <int> 0x0)
glGetIntegerv(<int> 0x846E, <[I>, <int> 0x0)
glGetIntegerv(<int> 0x846D, <[I>, <int> 0x0)
glGetIntegerv(<int> 0x80A9, <[I>, <int> 0x0)
glClearColor(<float> 0.0, <float> 0.0, <float> 0.0, <float> 0.0)
glClear(<int> 0x100)
glClearColor(<float> 0.8, <float> 0.8, <float> 0.8, <float> 1.0)
glClear(<int> 0x4000)
glBindFramebuffer(<int> 0x8D40, <int> 0x0)
glGetError() = 0
glEnable(<int> 0xBE2)
glBlendEquation(<int> 0x8006)
glBlendFunc(<int> 0x302, <int> 0x303)
glEnable(<int> 0xB71)
glDepthFunc(<int> 0x203)
glDepthMask(<boolean> true)
glGetIntegerv(<int> 0xBA2, <[I>, <int> 0x0)
glViewport(<int> 0x0, <int> 0x0, <int> 0x280, <int> 0x1E0)
glFrontFace(<int> 0x900)
glActiveTexture(<int> 0x84C0)
glClearColor(<float> 0.0, <float> 0.0, <float> 0.0, <float> 0.0)
glClear(<int> 0x500)
glGetError() = 0
glGetError() = 0
glViewport(<int> 0x0, <int> 0x0, <int> 0x280, <int> 0x1E0)
glFlush()
glGetError()Exception in thread "Animation Thread" javax.media.opengl.GLException: No OpenGL context is current on this thread
        at javax.media.opengl.DebugGL4bc.checkContext(DebugGL4bc.java:25888)
        at javax.media.opengl.DebugGL4bc.glGetError(DebugGL4bc.java:9485)
        at javax.media.opengl.TraceGL4bc.glGetError(TraceGL4bc.java:6434)
        at processing.opengl.PGL.glGetError(PGL.java:465)
        at processing.opengl.PGraphicsOpenGL.report(PGraphicsOpenGL.java:4342)
        at processing.opengl.PGraphicsOpenGL.endDraw(PGraphicsOpenGL.java:1523)
        at processing.core.PApplet.handleDraw(PApplet.java:1936)
        at processing.core.PApplet.run(PApplet.java:1812)
        at java.lang.Thread.run(Unknown Source)

So, the first time the renderer tries to release the context, at the end of the first frame, it turns out that it is not current, but... I can assure that we call context.makeCurrent() at the beginning, so it is not clear to me why the context is not current.

On the other hand, until now in Processing we were using a rendering mechanism where the opengl context was manually created inside Processing's animation thread (so we didn't use any GLCanvas object)... this approach was working (although with the error in windows), but from what I read it is recommended that OpenGL runs within AWT's EDT thread. I just changed the rendering logic in Processing, this time using GLCanvas, GLEventListener and no explicit GLContext, and everything appears to work fine, this time without any error.

On 02/15/2012 09:12 PM, ac [via jogamp] wrote:
>
>
> Ok, with the debug and trace options enabled, I get the following:
>

<snip/>
very good!

> So, the first time the renderer tries to release the context, at the end of
> the first frame, it turns out that it is not current, but... I can assure
> that we call context.makeCurrent() at the beginning, so it is not clear to
> me why the context is not current.

It depends, w/o seeing source code, how can we tell?

>
> On the other hand, until now in Processing we were using a rendering
> mechanism where the opengl context was manually created inside Processing's
> animation thread (so we didn't use any GLCanvas object)...

I was just about to get the idea, that you have left the 'save' and 'sane'
path and doing your own GLAutoDrawable logic - here we are :)

> this approach was
> working (although with the error in windows),

Well, it's 'just' a bug in your code.
Impl. the GLAutoDrawable is not easy.

do a:
draw_a_thing:
 makeCurrent()
 try {
    lalal
 } finalize {
    release()
 }

that should always work.

> but from what I read it is
> recommended that OpenGL runs within AWT's EDT thread.

If you use AWT, yes. But have a look at NEWT and our drop-in NEWT Applets
(applet test site -> unit tests etc).

> I just changed the
> rendering logic in Processing, this time using GLCanvas, GLEventListener and
> no explicit GLContext, and everything appears to work fine, this time
> without any error.

yup, see above.

writing your own 'sane' path (GLAutoDrawable) is not that easy, but doable.

~Sven