JOGL very slow in Linux

OpenGL Development JOGL Development
#1

I’ve been trying to figure out what is wrong but I have no idea what else to try.

All the JOGL apps that I try, the ones I made myself or the demos from the website (like JGears that has a fps counter), run with less than 20 fps.
I’ve tried putting in things like .setSwapInterfall(0) and .setRunAsFastAsPossible(true) but they make no difference.

I’ve looked at VSync settings for the driver as well but it was already deactivated (and other OpenGL apps run at full speed, glxgears shows 7000+ fps).

Tried with Java versions 1.5.0_09-b03 and 1.6.0-rc-b103.
Linux: Fedora Core 6 - 2.6.18
NVidia driver: 9629

Any ideas?

#2

What graphics card do you have?

Please post the output of “glxinfo -v” and run demos.gears.Gears from the command line with -Djogl.debug.X11GLDrawableFactory and post that output as well.

#3

The card is an nVidia 6600GT from XFX.

!!! GLX server vendor : NVIDIA Corporation
!!! GLX server version: 1.4
!!! GLX client vendor : SGI
!!! GLX client version: 1.4
!!! glXChooseVisual recommended visual id 0x26
INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 6600 GT/PCI/SSE2/3DNOW!
GL_VERSION: 1.4 (2.1.0 NVIDIA 96.29)

#4

From this information I don’t see anything obvious wrong. JGears is the only demo with an FPS counter, and it uses a lightweight widget so is not going down the fastest code path. You should definitely be getting more than 20 FPS from your graphics card for things like the Gears demo when maximized, for example. Have you tried running on other machines and are you 100% sure you are getting only ~20 FPS on this one? Could you also post the output of “glxinfo -b”?

#5

glxinfo -b returns 35

And every Jogl app that I have that show FPS return more or less the same number (all the ones that used to run at hundreds of FPS at least).

Anyway, it seems that something that I had ran before had some negative impact on the results, because after restarting the X server the FPS went up to around 60 which would suggest that there might still be some VSync limit? I see the same on a different system (Laptop with NVidia chipset also running FC6).

Is there any way to check if JOGL is somehow still using VSync? (non-java OGL apps like glxgears do run at full speed, so it’s not at the driver level at least)

edit: Forget to tell that a modified Gears that shows FPS returns more or less the same numbers as JGears.

Also, my own Jogl apps all use the GLCanvas.

Still, the code has been the same for quite some time, I only updated the code to use the new JOGL API.

#6

Looking at the man page for glXSetSwapIntervalSGI it looks like calling setSwapInterval(0) on X11 platforms will actually have no effect since 0 is an invalid argument to glXSetSwapIntervalSGI. It also looks like NVidia’s X11 drivers don’t sync to the vertical retrace by default; you have to set the environment variable __GL_SYNC_TO_VBLANK to force it to do so.

Note that the Gears demo calls setSwapInterval(1) internally to prevent it from running too fast.

Sorry but I don’t have any other suggestions at this point. I haven’t seen this kind of slowdown on the X11 machines (both desktop and an older laptop) I have available though I run Solaris/x86 with NVidia’s drivers rather than Linux. You might consider hacking X11GLDrawableFactory.chooseGraphicsConfiguration() to force it to pick the recommendedIndex associated with the XVisualInfo having the visual ID 35 (not sure whether that’s decimal or hex though) – around line 185 in the current source tree.

#7

I had set the setSwapInterval() to 0, but I did’t know it doesn’t do anything on X11 platforms.

I’ve hacked the X11GLDrawableFactory.chooseGraphicsConfiguration() to take the visual id from a system property so I could enter it on the command line. Then I tried all 80+ of them but except for some minor variations it doesn’t seem to make any difference.

So this probably means I am out of options right now, doesn’t it? Damn, just when I was looking forward to putting some more time into my JOGL projects. Ah well.

#8

Sorry. You might want to try the final release of JDK 6 with -Dsun.java2d.opengl=true and see if the GLJPanel works well enough for you in that scenario. If this appears to be a JOGL-specific problem, you might try LWJGL’s AWTGLCanvas to see if it behaves any differently. If it does, please post and we can try to track down what’s going on in the JOGL implementation.

#9

No, the JDK6 doesn’t make any difference (all the above tests have been done with both Java 5 and Java 6, all the same).

Just tried the Gears demo on the JWGL site and it runs at almost 3000 fps (it outputs fps to the console).
Of course I can’t make a 100% correct comparison because the JOGL webstart Gears demo does not show fps (although the Vertex Warp demo does and it shows ~22fps).

If you really need to know the performance as a local application I can download and install JWGL, but at first glance it does seem a JOGL problem.

Hmmm, this is weird, I was going through all the demos on the JOGL website and I got some very strange messages:

High Dynamic Range Rendering - Floating-point pbuffers on X11 currently require NVidia hardware
Vertex Buffer Object - OpenGL extension “GL_ARB_vertex_buffer_object” not available
Vertex Array Range - something similar but it disappears to quickly to be read

but even weirder is that when I run the “JRefract” demo I can start the above demos that don’t work when I run them seperately!

#10

Ok, a little more information: it seems that the Java 6 version does perform a lot better, but I shouldn’t be trying to run it from Eclipse, no matter if I use Java 5 or Java 6, running from Eclipse (without debugging of course) I get ~40 fps on Gears or JGears. Running from the command line I get 3300+ fps on Gears and 200 or 1200 fps on JGears depending on the -Dsun.java2d.opengl option. For Java 5 I seem to get ~40 fps no matter what (this made me check if Eclipse really was using Java 6 when I told it too but the version info I made it print says it does).

So if I can figure out why I don’t get normal performance when running from Eclipse I’m good to go again.

I did notice some other annoying things though: when using the -Dsun.java2d.opengl option to get the best performance my system regularly locks up for a second or two (X unresponsive, music stops playing), especially when doing something with the OpenGL window (moving it, opening a menu). This is especially noticable with the JRefract demo (strange name BTW for that demo), if I open the Loop Gears Demo the hangups occur almost every time the window apears/disappears.

#11

That’s strange. It almost seems like you’re falling back to Mesa-based software rendering in some cases. I’m at a loss why that would happen. I believe we did make some slight changes in how we set up the attribute lists for glXChooseVisual, but these were only correctness changes for things like stereo. Also, Java 5 and Java 6 should perform identically for the Gears demo (at least when run from the command line) if you don’t specify -Dsun.java2d.opengl=true , to the best of my understanding.

The hangs / lockups with -Dsun.java2d.opengl=true may be because the OpenGL pipeline for Java 2D really stresses OpenGL graphics drivers to their limits. I’m not sure whether there’s a more recent version of NVidia’s OpenGL drivers (it may be in beta) but using the latest version should improve stability in that area.

I’ll try to look into this more within a few days. In the meantime it sounds like running with Java 6 from the command line is a workaround, so I’d suggest going with that for now. Also, I don’t know whether Eclipse launches a new JVM to execute programs but you may want to try to see exactly what command line arguments it passes to that JVM and in particular whether you’re loading the SWT as well as the AWT, which I can believe would cause problems.

#12

I’ll try a new driver ASAP, I’ll let you know what the verdict is.

I’ve been looking into any runtime differences that might exist between running an application from the shell when compared to running from Eclipse. First with jps it’s obvious a new VM gets started, then with jconsole I started looking for differences. But both VM version, VM args, classpath and bootclasspath are exactly the same for both cases.

I imagine Eclipse does keep some links to the application (the console get’s redirected to Eclipse for example, but my test app doesn’t print anything to the console), but attaching jconsole to the app hardly makes a difference, you can see a drop in FPS each time the info in jconsole gets updated, but the app quickly recovers.

(Just tried running the app from Eclipse telling it not to redirect the console but it doesn’t make a difference so there must be something else still)

Anyway, thanks for the help so far :slight_smile:

#13

Ok! I haven’t figured out why yet, but at least I know where to look for the cause of the slowdown:

I was using the java-1.5.0-sun-compat package from JPackage (www.jpackage.org) which basically adds a lot of links to make the Sun version of the JDK compatible with the Fedora Core file system layout.

I just switched to the java-1.6.0-sun-compat package … and now it’s Java 6 that is the slow one and Java 5 is fast!

So somewhere in that bunch of links is something that is “off”, I’ll try to figure out what it is.

…

Ok, found it. The compatibility package adds a link from /usr/java/jdk1.6.0/lib/i386 to /usr/lib, if I remove that link everything works just fine (even from Eclipse!).

I’ll contact the JPackage people to tell them about this and see what they have to say.

#14

Nice detective work. I don’t understand how that particular symlink could work (at least in the face of multiple Java versions installed on the same system) but thanks for tracking it down.

#15

FYI, I see no problems running the HDR, VAR or VBO demos from the jogl-demos page using Java Web Start on Solaris/x86 with the NVidia drivers. I think the problems you were seeing were caused by the JPackage distribution.

#16

Ah yes, sorry, I had noticed that as well but forgot to mention it.

Absolutely no response from my question on the JPackage list though (it seems very low-traffic anyhow) so I’m not sure if I’ll ever get an answer.

#17

Hi Ken,

just to let you know that the problem is back if I install the latest nightly build.

Made sure that I removed any other builds before using the nightly but fps was down to ~40 again while just putting back the jars and .so from the release version made the fps jump back to 800+ fps.

Any idea what could be causing this?

#18

What are the two JOGL versions you’re comparing? How do 1.0.0, 1.1.0-rc1, and the latest nightly build compare?

#19

Haven’t had time yet to look at the versions you mention but I did get a response to my mail to the JPackage.org mailing list. I’ll repeat it here to see what you think (I have to little experience with these things to be able to determine if what he says is reasonable or not):

[quote]> I haven’t figured out why but I did find what was causing the

slowdown: the symbolic link from /usr/java/jdk1.6.0/lib/i386 to
/usr/lib

Isn’t this link necessary? It seems a bit too much to include all
libraries from /usr/lib to the Java native library path

I disagree about this - IMO system libraries should be available to Java just
like all other languages. The alternative without the symlink is to play
$LD_LIBRARY_PATH tricks which are even worse, and would most likely lead to
the same plus possibly other problems. And they possibly need to be made on
per application basis (which sucks when we’re dealing with a jar-only thing
that requires those native libs - there’s no way to do the equivalent of
$LD_LIBRARY_PATH eg. in jar manifests).

This is an area which has some room for standardization, and I hope the
GPL’ing of Java will let vendors to ship VM’s sanely configured with regards
to native system libs. I believe some (GCJ, IBM, Blackdown) already are
though - the symlink added in the -compat package brings the Sun VM up to par
with the mentioned others.

although I
must admit I don’t see why it causes problems in this particular case
because the JOGL libraries cannot be found there. It must be some
other library that causes a problem.

Just a guess, but perhaps there’s a vendor specific hardware accelerated
OpenGL library somewhere else than /usr/lib (but still in the runtime
linker’s default path, maybe through /etc/ld.so.conf*), and the symlink above
causes the JVM load an unaccelerated software implementation from /usr/lib.
If this is the case, I suppose adding the dir where the hardware accelerated
one is to $LD_LIBRARY_PATH could help.
[/quote]

#20

There have been some issues raised recently about the so-called “DRI hack” in JOGL and the fact that it’s causing the Mesa OpenGL implementation to be loaded in some situations. We’re looking into this in the context of ATI’s OpenGL drivers and will try to figure out within the next week or so what’s going on. In the meantime as a workaround you can force driHackNeeded to false in DRIHack.java and rebuild JOGL. We’ll add a way to do this via a system property; -Djogl.drihack.disable will do this in tomorrow’s nightly build.