Hi,
I have only recently started using DebugGL3 to automatically check for OGL errors in my code. However, this introduced a very significant and progressive slowdown, where every couple of frame, the execution time to some of the OGL operations rises for no apparent reason. I use the following piece of code GL3 gl = new DebugGL3(drawable.getGL().getGL3()); drawable.setGL(gl);at the beginning of the display(GLAutoDrawable drawable) method (this call's time stays constant) to get a debug "context". It seems that among the GL calls that cause this behaviour are glGetAttribLocation, glBindBuffer, glVertexAttribPointer, and glEnableVertexAttribArray (probably not an exhaustive list, but the slowdown happens for all of those). Without any change to the rendered scene, the execution time for each of these calls goes 0ms, 1ms, 3ms, 5ms, 12ms, 24ms, 49ms, 95ms etc, with each slowdown occurring after a couple of rendered frames. This might indicate a problem in the error checking mechanism common to all of these functions. Why I think it is unlikely that the issue is on my side: 1) I made several check to see that not data-structures are growing (e.g. I'm trying to render more and more geometry) and some of these calls' execution time should be constant anyway 2) no apparent problem with a NON-DebugGL "context" 3) remember letting the app run (non-DebugGL) for a few hours without a decrease in performance. My questions are: Has this happened to anyone else (under the development versions or even the release ones)? Do you have an idea or a wild guess at what might be causing this? I tried with both RC12 and the current latest revision (gluegen: 3ceb32fb505363ccc02fc4cce1362257ca98a3e5, jogl: 433e3914324b90c910b018bb7d9d80e814c67123), with the issues being manifested under both versions. I'm running a Mac OS 10.8.2 with Renderer: NVIDIA GeForce GTX 680MX OpenGL Engine OpenGL version: 3.2 NVIDIA-8.6.22 GLSL version: 1.50 Thanks! |
Administrator
|
On 07/07/2013 11:38 PM, JanBenes [via jogamp] wrote:
> Hi, > > I have only recently started using DebugGL3 to automatically check for OGL > errors in my code. However, this introduced a very significant and progressive > slowdown, where *every couple of frame*, the *execution time* to some of the > OGL operations rises for no apparent reason. I use the following piece of code > > GL3 gl = new DebugGL3(drawable.getGL().getGL3()); > drawable.setGL(gl); > > at the beginning of the display(GLAutoDrawable drawable) method (this call's > time stays constant) to get a debug "context". It seems that among the *GL > calls that cause this* behaviour are glGetAttribLocation, glBindBuffer, > glVertexAttribPointer, and glEnableVertexAttribArray (probably not an > exhaustive list, but the slowdown happens for all of those). > > Without any change to the rendered scene, the* execution time *for each of > these calls goes 0ms, 1ms, 3ms, 5ms, 12ms, 24ms, 49ms, 95ms etc, with each > slowdown occurring after a couple of rendered frames. This might indicate a > problem in the error checking mechanism common to all of these functions. > > Why I think it is *unlikely that the issue is on my side*: 1) I made several > check to see that not data-structures are growing (e.g. I'm trying to render > more and more geometry) and some of these calls' execution time should be > constant anyway 2) no apparent problem with a NON-DebugGL "context" 3) > remember letting the app run (non-DebugGL) for a few hours without a decrease > in performance. > > *My questions are: *Has this happened to anyone else (under the development > versions or even the release ones)? Do you have an idea or a wild guess at > what might be causing this? > GL3 gl = new DebugGL3(drawable.getGL().getGL3()); > drawable.setGL(gl); shall only add a constant period of time to the execution time, this is correct. Further more, you could use the property jogl.debug.DebugGL, which would additionally enable the OpenGL debug context if available - besides adding the DebugGL3 pipeline. This seems not to be the case here. Impl. of DebugGL3 does check for GL errors after each function call and throws an exception. It shall not use and increase heap usage etc. If you can demonstrate your case w/ a unit tests and file a bug report, that would be very helpful. Pls add the performance measurement for each call, or the whole frame, demonstrating the increased costs per call / frame. Pls add all this information in the bug report, since forum information is considered transient only. ~Sven > > I tried with both *RC12* and the *current latest revision* (gluegen: > 3ceb32fb505363ccc02fc4cce1362257ca98a3e5, jogl: > 433e3914324b90c910b018bb7d9d80e814c67123), with the issues being manifested > under both versions. > > I'm running a Mac OS 10.8.2 with > Renderer: NVIDIA GeForce GTX 680MX OpenGL Engine > OpenGL version: 3.2 NVIDIA-8.6.22 > GLSL version: 1.50 > > Thanks! signature.asc (911 bytes) Download Attachment |
Hi,
The application causing this issue isn't exactly trivial, so isolating the behavior into a MWE/Test could be rather tedious. But I agree it's worth al least looking into. I'll see if I can get to it over the weekend and let you know. |
Free forum by Nabble | Edit this page |