Date: Sat, 8 May 1999 05:11:32 +0000 (GMT) From: eagle <eagle@eagle.phc.igs.net> To: Doug Rabson <dfr@nlsystems.com> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Lee Cremeans <lcremeans@erols.com>, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: G200 GLX and SIGFPU Message-ID: <Pine.BSF.3.96.990508051012.1394C-100000@eagle.phc.igs.net> In-Reply-To: <Pine.BSF.4.05.9905081058090.18703-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 May 1999, Doug Rabson wrote: > On Sat, 8 May 1999, John-Mark Gurney wrote: > > > eagle scribbled this message on May 8: > > > > > > > > > On Sat, 8 May 1999, Lee Cremeans wrote: > > > > > > > I'm playing with the GLX (server-side OpenGL-to-hardware interface) drivers > > > > for the Matrox G200 2D/3D chip (very good chip, btw), and the good news is > > > > that they work in FreeBSD. > > > > > > > > Mostly. > > > > > > > > My problem is that sometimes, the driver (which loads into a XFree86 3.3.x > > > > server as a module, and also comes with a Mesa-based libGL.so) likes to kill > > > > the X server with a SIGFPU at a certain point in the code (in the hardware > > > > pixel/texel-smoothing routines, to be exact). When I run the SGI logo.c > > > > demo, it will kill the server, eventually, with SIGFPU, and when I play > > > > q3test through the driver, it'll drop the server at or near the same place > > > > in the code as logo.c. This doesn't happen when Mesa itself is doing the > > > > rendering in software. > > > > > > > > The reason I'm asking here on the FreeBSD lists about this is because I > > > > remember some rumblings a while back about differences in the way FreeBSD > > > > and Linux handle the FPU, and whether they'd be pertinent to this. It'd > > > > appear, from what I've seen, that all development on these drivers (until > > > > now) has been done on Linux, so a lot of these SIGFPU issues would be > > > > "invisible" to them. > > > > > > > > If anyone wants a look at the code, the CVS information is at > > > > > > > > http://lists.openprojects.net/mailman/listinfo/g200-dev > > > > > > > > and I can also get crash dumps and backtraces for anyone who wants them. > > > > > > I've seen similar error messages with mesa in particalur in relation to > > > flightgear, I don't have a solution as of yet though. > > > > use fpsetmask to mask the SIGFPE's that you don't want... usually this > > is all of them as FreeBSD has them turned on my default while other OS's > > don't... if you do a search of the mailing lists on SIGFPR and fpsetmask > > your bound to turn up many postings on the subject... > > This should be done by the GL implementation. At Microsoft, we used to > save/restore the fp flags on entry to Direct3D so that we could force the > correct mode for our maths to work properly. We had all sorts of trouble > before doing that (stupid exceptions enabled, people changing fp > precision etc). > > I think in current versions of D3D, there is an api which you can call to > say 'I agree not to touch the fp flags' which improves performance > slightly. Mesa should be doing something similar, IMHO. > That was my next question shouldn't this be done in the port of MESA since thats whats throwing the sigfpe, disabling it in flightgear wouldn't help the problem at all.. Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990508051012.1394C-100000>