Are you saying that the above results from JOGL and LWJGL both came from runs done witn DRI enabled? I have a really hard time believing that JOGL would produce an indirect rendering context in the same situation that LWJGL would produce a direct one. The visual selection code is almost identical in the two libraries.
Here are my results.
JOGLTest: GL_VENDOR: Mesa project: www.mesa3d.org
JOGLTest: GL_RENDERER: Mesa GLX Indirect
JOGLTest: GL_VERSION: 1.2 (1.5 Mesa 6.2.1)
LWJGLTest: GL_VENDOR: Tungsten Graphics, Inc.
LWJGLTest: GL_RENDERER: Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL
LWJGLTest: GL_VERSION: 1.2 Mesa 6.3.2
I noticed our lines are pretty much identical, my xorg line is pretty well the same too, so I will not post it.
This is on ubuntu breezy, stock kernel, dri, radeon not fglrx kernel module, and glxinfo reports yes on the direct rendering line. I have a radeon mobility U1.
Once I finish setting up slackware on the other partition, I may try a kernel recompile and see what happens. I do have my slackware box nearly set up for testing this on the same computer, so I am going to do that right now.
I just completed both tests on slackware.
Both were hardware accelerated, the only difference was GL_VERSION.
Both were: 1.2 Mesa 6.2.1
I am using a compiled 2.6.13 kernel with dropline gnome, radeon kernel module, dri, and the same hardware as before.
My initial guess is that it has something to do with the default GLCapabilities requesting a color depth larger than your screen’s depth. Could you please try the attached JOGLTest2 and see whether it changes the behavior?
Hi
The new test gave me the same indirect rendering lines.
I will continue running test cases as long as I need to.
Thanks
Greg Tedder
I’m still trying to figure out what the heck could be going on. Could you please run the attached test cases? For each one, once it’s running, start a new terminal, figure out the process ID of the java process (or one of them) via e.g. “ps -elf | grep java”, and “cat /proc/pid/maps > lwjgl-output.txt” or “cat /proc/pid/maps > jogl-output.txt” depending on the test case and where pid is the process id (or one of them) from the Java process. Also could you please send the output of “ls -l /usr/lib/libGL*” and the full output from glxinfo?
I will probably need to ask you to run at least one more test in addition to all of this. Sorry and thanks in advance.
OK
If I have forgotten something let me know.
Thanks
Thanks for the output.
Could you please download and test a new build of JOGL?
http://download.java.net/media/jogl/builds/tmp/jogl-linux.tar.gz
I think there’s a chance this may fix the problem, but if not it should provide some more information to help us track down what is happening. If you could please run the above JOGLTest3 again and post the output I’d appreciate it. (There should be additional lines printing the GLX_VERSION for the client and server, etc.)
The changes here are a change to how JOGL was linked (due to a recent build change the Linux library had grown massive and may have had some things incorrectly statically linked in to it) as well as a change to load the GLU library more lazily, since it isn’t used by default. I think the GLU change has a chance at changing the behavior.
Sorry it took so long, busy week.
Here is the output of JOGLTest3.
!!! GLX server vendor : SGI
!!! GLX server version: 1.2
!!! GLX client vendor : SGI
!!! GLX client version: 1.4
!!! glXChooseVisual recommended visual id 0x27
!!! Fetched XVisualInfo for visual ID 0x27
!!! Resulting XVisualInfo: visualid = 0x27
JOGLTest3: GL_VENDOR: Mesa project: www.mesa3d.org
JOGLTest3: GL_RENDERER: Mesa GLX Indirect
JOGLTest3: GL_VERSION: 1.2 (1.5 Mesa 6.2.1)
And attached is the process information.
Thanks for doing the run. I’m still pretty mystified as to what is going on. Could you please do a couple more runs?
For the JOGL run, could you please “setenv LIBGL_DEBUG verbose” before doing the run and post the output? That should give some information about why the DRI drivers aren’t getting loaded for the JOGL case.
For the LWJGL run, could you please run with -Dorg.lwjgl.util.Debug=true ? That should print out what visual ID LWJGL is choosing, I think.
The /proc output isn’t necessary for these runs, thanks.
I’m guessing that in your glxinfo output some of the visuals are supplied by Mesa and some by the DRI drivers, though I don’t understand how that is possible. The visual ID selected when running the JOGL test claims it has no caveats like “slow”, but obviously that’s not correct since it doesn’t support direct rendering…
Hmm, I just had a bad thought. Unlike LWJGL, JOGL links against libGL.so rather than dlopen’ing it at run time. I’m aware that the JDK dlopens libraries like libjogl.so with RTLD_LOCAL rather than RTLD_GLOBAL specified, and I’ll bet that due to transivity this means that libGL.so.1.2 only has local symbol visibility with JOGL. Knowing that the DRI drivers require libGL.so.1.2 to have RTLD_GLOBAL visibility, I’m guessing this is the fundamental difference between the two configurations. The output from your run with LIBGL_DEBUG set should be enough to confirm this.
Actually, before you go to all of that effort, could you try a new JOGL build?
http://download.java.net/media/jogl/builds/tmp/jogl-linux-drihack.tar.gz
As far as I understand it, that build should fix the problem. Please let me know whether it does. If so, we have some work to do on the JOGL side to be able to implement this cleanly.
Well, heres the output before the new build. I will post the new immediately after
JOGL OUTPUT:
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so
libGL error: dlopen /usr/lib/dri/radeon_dri.so failed (/usr/lib/dri/radeon_dri.so: undefined symbol: _glapi_Dispatch)
libGL error: unable to find driver: radeon_dri.so
!!! GLX server vendor : SGI
!!! GLX server version: 1.2
!!! GLX client vendor : SGI
!!! GLX client version: 1.4
!!! glXChooseVisual recommended visual id 0x27
!!! Fetched XVisualInfo for visual ID 0x27
!!! Resulting XVisualInfo: visualid = 0x27
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so
libGL error: dlopen /usr/lib/dri/radeon_dri.so failed (/usr/lib/dri/radeon_dri.so: undefined symbol: _glapi_Dispatch)
libGL error: unable to find driver: radeon_dri.so
JOGLTest3: GL_VENDOR: Mesa project: www.mesa3d.org
JOGLTest3: GL_RENDERER: Mesa GLX Indirect
JOGLTest3: GL_VERSION: 1.2 (1.5 Mesa 6.2.1)
LWJGL OUTPUT:
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so
drmOpenByBusid: Searching for BusID pci:0000:01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
drmOpenByBusid: Searching for BusID pci:0000:01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0
libGL error:
Can’t open configuration file /etc/drirc: No such file or directory.
libGL error:
Can’t open configuration file /home/project/.drirc: No such file or directory.
LWJGLTest3: GL_VENDOR: Tungsten Graphics, Inc.
LWJGLTest3: GL_RENDERER: Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL
LWJGLTest3: GL_VERSION: 1.2 Mesa 6.3.2
It seems to have worked. This is great. It has also brought the performance of my code up to par.
JOGL Output:
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so
drmOpenByBusid: Searching for BusID pci:0000:01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
drmOpenByBusid: Searching for BusID pci:0000:01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0
libGL error:
Can’t open configuration file /etc/drirc: No such file or directory.
libGL error:
Can’t open configuration file /home/project/.drirc: No such file or directory.
JOGLTest3: GL_VENDOR: Tungsten Graphics, Inc.
JOGLTest3: GL_RENDERER: Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL
JOGLTest3: GL_VERSION: 1.2 Mesa 6.3.2
I am about to post another error I have been having in both operating systems. It has to do with glReadPixels. I will put this in a new thread. This hack has not fixed this one issue. Everything else seems to be working great!
Greg
Great. Thanks for patiently running all of these test cases. I’ll get this fix into the JOGL tree as soon as possible.