JOGL Indirect on Unichrome?

OpenGL Development JOGL Development
#1

Hello,
I’m using the Via UniChrome (KM400) chipset for graphics acceleration. Using c/c++ graphics acceleration works, glxinfo reports:

OpenGL vendor string: VIA Technology
OpenGL renderer string: Mesa DRI UniChrome (KM400) 20050526 x86/MMX+/3DNow!+/SSEOpenGL version string: 1.2 Mesa 6.3

However when I run jogl (demos.gears.Gears), it reports:

INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: Mesa project: www.mesa3d.org
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.2 (1.5 Mesa 6.2.1)

And from the framerate difference between demos.gears.Gears and glxgears shows that it is definitely doing software rendering. Any ideas as to what the problem is?

I’m running the Feb. 17th release. (the latest snapshot breaks w/ an XLib async error)
Thanks!
–brendan

#2

We’ve had some problems with DRI support in the past (see this thread), but I thought they should all have been fixed in JSR-231 beta 3. Could you please “setenv LIBGL_DEBUG verbose”, run demos.gears.Gears and post the output?

#3

Thanks for the respons, here’s the output from demos.gears.Gears

[bburns@localhost Desktop]$ java -classpath ./jogl.jar:./jogl-demos.jar demos.gears.Gears
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/unichrome_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/unichrome_dri.so failed (/usr/X11R6/lib/modules/dri/unichrome_dri.so: undefined symbol: _glapi_add_entrypoint)
libGL error: unable to find driver: unichrome_dri.so
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/unichrome_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/unichrome_dri.so failed (/usr/X11R6/lib/modules/dri/unichrome_dri.so: undefined symbol: _glapi_add_entrypoint)
libGL error: unable to find driver: unichrome_dri.so
INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: Mesa project: www.mesa3d.org
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.2 (1.5 Mesa 6.2.1)

and glxgears.

[bburns@localhost Desktop]$ glxgears
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/unichrome_dri.so
drmOpenByBusid: Searching for BusID PCI:1:0:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
__driCreateNewScreen - succeeded
libGL error:
Can’t open configuration file /etc/drirc: No such file or directory.
libGL error:
Can’t open configuration file /home/bburns/.drirc: No such file or directory.
2323 frames in 5.0 seconds = 464.600 FPS

/usr/X11R6/lib/modules/dri/unichrome_dri.so exists…

Thanks!
–brendan

#4

It looks like the “DRI hack” in JOGL was not detecting that it needed to be activated in your situation. I’ve augmented DRIHack.java in the JOGL tree to look for the presence of /usr/X11R6/lib/modules/dri as well as /usr/lib/dri. Please either try again with a nightly build dated 3/9 or later, or build JOGL from the CVS repository (not that hard to do), and post to let us know whether that has fixed the problem.

#5

Thanks,
I built from CVS, and it now loads and renders. However the minute there is any window activity (mouse over, moving the window, etc.) I get the XLib async error (see below). Here’s the complete output:

[bburns@localhost build]$ java -classpath ./jogl.jar:/home/bburns/Desktop/jogl-demos.jar demos.gears.Gears
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/unichrome_dri.so
drmOpenByBusid: Searching for BusID PCI:1:0:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
__driCreateNewScreen - succeeded
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
drmOpenByBusid: Searching for BusID PCI:1:0:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
__driCreateNewScreen - succeeded
libGL error:
Can’t open configuration file /etc/drirc: No such file or directory.
libGL error:
Can’t open configuration file /home/bburns/.drirc: No such file or directory.
INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: VIA Technology
GL_RENDERER: Mesa DRI UniChrome (KM400) 20050526 x86/MMX+/3DNow!+/SSE
GL_VERSION: 1.2 Mesa 6.3
Xlib: unexpected async reply (sequence 0xd39)!

Thanks
–brendan

#6

Hmm. I assume you’re getting a direct rendering context so in theory JOGL’s internal X11 locking should be correct for your case. There are problems with the current Mustang builds when running JOGL on X11 platforms, so if you’ve been experimenting with them you should switch back to 5.0u6 for development probably until build 77 comes out. We will also be adding back in the more strict locking from previous JOGL builds so in a day or two there should at least be a workaround for this in the source tree. I’ll try to remember to post about this when the work is done.

#7

Thanks,
I’ll look forward to the more strict locking. FYI, I’m not using mustang, here’s my java version:

[bburns@localhost ~]$ java -version
java version “1.5.0_06”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot™ Client VM (build 1.5.0_06-b05, mixed mode, sharing)

In the meantime, I will also backport your DRIHack modifications to the Feb 17th source release and see if that fixes things. I’ll let you know what happens.

Thanks!
–brendan

#8

Hey Ken,
I tried the Feb 17th release with a backport of your DRIHack.java patch and it works correctly with accelerated graphics.
If I can be of any help figuring out what is broken in the CVS version, let me know (I’m a reasonably adept programmer…)
Thanks!
–brendan

#9

Could you please try things again with the current JOGL nightly build and see whether they are working? Some changes have recently been made in this area and I think the current code should work. If not, I’d like to get to the bottom of why not.