Exception in thread "Thread-3" org.lwjgl.opengl.OpenGLException: Cannot use Buffers when Pixel Unpack Buffer Object is enabled at org.lwjgl.opengl.GLChecks.ensureUnpackPBOdisabled(GLChecks.java:120) at org.lwjgl.opengl.GL11.glTexImage2D(GL11.java:2699) at org.dronus.gl.RenderTexture.<init>(RenderTexture.java:44) at org.dronus.gl.ShaderStage.<init>(ShaderStage.java:33) at Tests$1.run(Tests.java:79)
Exception in thread "Thread-3" org.lwjgl.opengl.OpenGLException: Cannot use Buffers when Pixel Unpack Buffer Object is enabled
QuoteException in thread "Thread-3" org.lwjgl.opengl.OpenGLException: Cannot use Buffers when Pixel Unpack Buffer Object is enabledThat error doesn't appear to have anything to do with threading. Does the program run correctly if you aren't doing multiple threads?
. More importantly, the outcomes of your multithreaded GL code will vary on different platforms and drivers. So don't do it.
I guessed the only valid hook to opengl data is the "context" and handover this would allow shure access within one application.
But I was wrong.. why?
Implement a queue in your main OpenGL thread, that accepts GL commands from other threads and empties (executes) the commands when convenient (e.g. render method).
That is correct, but context switches are usually time consuming so its generally best not to do it that way anyways.
afaik, it has to do with thread local storage being used, which means that depending on which thread calls the gl methods, different (and wrong) values will be in the threads associated context and TLS.
Quote from: Fool Running on February 08, 2008, 15:15:15That is correct, but context switches are usually time consuming so its generally best not to do it that way anyways.Sorry..I don't get it. As threads share same heap memory, why does it matter at all which thread try to invoke an opengl function? I even don't know why different threads have to set the context, as the one static opengl instance shouldn't even notice who calls theire commands. On the java side, threads can only be distinuished by explicitly get their current runtime Thread class..
As a GL context can only be used by one thread at a time, you need to transfer the context to the thread which should do the rendering. This requires that the original thread releases the context, and to make the context current in the new thread.LWJGL provides functions for this - see the Display class for details.So LWJGL does not enforce threading onto your application - OpenGL does this.There is also the possibility of creating a shared context - which shares "heavy" objects like textures, VBOs, display lists - but not container like FBOs. The shared context then can be used in another thread concurrently with the main context. But be aware that you might discover driver bugs much more easily then This is done using the Drawable class, and methods in the Display and Pbuffer classes.Ciao Matthias