Philipp Klaus Krause wrote:
Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering.
Okay, then the SSE test can't be the problem. The exact same code gets executed in both the R200 driver and software Mesa. Actually, do you mean software Mesa (i.e., the libGL.so built by doing 'make linux-x86' in the Mesa tree) or GLX indirect-rendering? In this particular case they are quite different as the former executes in the application's address space, but the later does not.
I just moved r200_dri.so away.
Is there any way you can figure out where the jvm is terminating?
This is so weird...
Sorry for confusing people on this list, upon closer examination it seems it isn't the SIGFPE that caused the problem but a signal SIGSEGV raised in a glCallList().
If someone else wants to test: I use the glxgears port to jogl that is in the jogl-demos.jar from the jogl Java OpenGL binding (the one that was created by SUN and SGI).
This is part of the error message: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4D4E5A16 Function=(null)+0x4D4E5A16 Library=/usr/X11R6/lib/modules-dri-trunk/dri/r200_dri.so
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.Current Java thread:
at net.java.games.jogl.impl.x11.X11GLImpl.glCallList(Native Method)
at demos.gears.Gears$GearRenderer.display(Gears.java:134)
at net.java.games.jogl.impl.GLDrawableHelper.display(GLDrawableHelper.java:74)
at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:221)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:290)
- locked <0x447898b0> (a net.java.games.jogl.impl.x11.X11OnscreenGLContext)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)
at net.java.games.jogl.Animator$1.run(Animator.java:107)
at java.lang.Thread.run(Thread.java:536)
Just a small note on why I suspected it was the SIGFPE first even though the above log is rather clear: When debugging my C++ applications using OpenGL, gdb halts on a SIGFPE in _mesa_test_os_sse_exception ehen I use the r200 driver, but doesn't with software rendering, so I just noticed that the java program had a problem with a signal that went away when using software instead of the r200 driver, so I though it was the same.
Philipp
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
