Re: exception testing in r200 driver
On Sad, 2004-09-25 at 04:41, Patrick McFarland wrote: Not to sound ignorant, but isn't that a bug in the mobo/bios/chipset/processors? That shouldn't even be possible, should it? (And if it 'is', shouldn't Linux disable SSE usage on both processors?) You can mix PII and PIII processors in a system and get that sort of a result. The kernel correctly handles this for its own use, but user space apps aren't always smart enough. --- 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
Re: exception testing in r200 driver
On Thu, 23 Sep 2004 16:50:26 +0100, Alan Cox [EMAIL PROTECTED] wrote: Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. Not to sound ignorant, but isn't that a bug in the mobo/bios/chipset/processors? That shouldn't even be possible, should it? (And if it 'is', shouldn't Linux disable SSE usage on both processors?) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- 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
Re: exception testing in r200 driver
At the time the code was written (fall 1999?) the only way Gareth found that he could reliably determine that SSE was fully supported (by CPU and kernel) was to try executing an SSE instruction and catching the exception if it failed. If there's a better way of doing that nowadays, we could update Mesa. A work-around might be for Phillip to set the MESA_NO_SSE env var. Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. 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
Re: exception testing in r200 driver
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. Is there any way you can figure out where the jvm is terminating? This is so weird... --- 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
Re: exception testing in r200 driver
On Mer, 2004-09-22 at 22:14, Eric Anholt wrote: 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. Ask the processor or ask the kernel (cpuid or /proc/cpuinfo). All modern kernels support SSE so the exception case should only occur for 2.2 (ie unsupported). Alan --- 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
Re: exception testing in r200 driver
Ian Romanick schrieb: 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
Re: exception testing in r200 driver
Alan Cox wrote: On Mer, 2004-09-22 at 22:14, Eric Anholt wrote: 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. Ask the processor or ask the kernel (cpuid or /proc/cpuinfo). All modern kernels support SSE so the exception case should only occur for 2.2 (ie unsupported). The folks on #freedesktop suggested parsing cpuinfo, and I wrote some simple code to do that. Are you saying that, if CPUID returns the SSE bit set and we're on a 2.4 or later kernel, we're good to go? That would make me very happy because we already test the CPUID bit, and DRI isn't supported on 2.2. :) --- 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
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:22, Ian Romanick wrote: The folks on #freedesktop suggested parsing cpuinfo, and I wrote some simple code to do that. Are you saying that, if CPUID returns the SSE bit set and we're on a 2.4 or later kernel, we're good to go? That would make me very happy because we already test the CPUID bit, and DRI isn't supported on 2.2. :) Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. The more thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each processor but I'm not sure thats neccessary in reality --- 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
Re: exception testing in r200 driver
Alan Cox wrote: Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. The more thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each processor but I'm not sure thats neccessary in reality I had that issue in the back of my mind as well. I ran into this problem while working at Sequent when we got the first quads with MMX capable CPUs. There was no way in ptx to find out which CPUs supported which features. That was particularly annoying to me because we ended up with some engineering development servers that had PentiumPro, Pentium II Xeon, and Pentium III Xeon quads. Anyway, those days are almost as long gone as my Amiga days... ;) --- 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
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:21, Philipp Klaus Krause wrote: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4D4E5A16 Function=(null)+0x4D4E5A16 Looks like a buffer overrun or memory corruption. Are you trying to use mesa very threaded ?[at least 0x4D4E5A16 looks like text...] --- 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
Re: exception testing in r200 driver
On Wed, 2004-09-22 at 13:21, Ian Romanick wrote: Philipp Klaus Krause wrote: _mesa_test_os_sse_exception, executed upon start of any OpenGL application raises SIGFPE. Normally this is not a problem, applications continue to execute normally. However when using the jogl OpenGL Java binding programs exit. I tried both with Java 1.4 from Sun and sablevm. That's annoying. It seems like it must be a bug somewhere, but it's not obvious to me where. Can you track down why / where the program terminates? I looked at the code in check_os_sse_support (src/mesa/x86/common_x86.c, line 143), and it doesn't look like there should be any way for the signal to get past Mesa. Beyond that, the code in there *is* really awful. Is there a better way on modern-ish Linux systems to do this? Comments in the code indicate that a lot of the uglyness there is to workaround issues with certain 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- 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
exception testing in r200 driver
_mesa_test_os_sse_exception, executed upon start of any OpenGL application raises SIGFPE. Normally this is not a problem, applications continue to execute normally. However when using the jogl OpenGL Java binding programs exit. I tried both with Java 1.4 from Sun and sablevm. 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
