Date: Fri, 26 Nov 1999 19:01:38 -0800 From: Steve Reid <sreid@sea-to-sky.net> To: Marc van Woerkom <van.woerkom@netcologne.de> Cc: multimedia@FreeBSD.ORG Subject: Re: Success: Quake 3 DemoTest under FreeBSD with Matrox G200 Message-ID: <19991126190138.A828@grok.localnet> In-Reply-To: <199911270049.BAA02450@oranje.my.domain>; from Marc van Woerkom on Sat, Nov 27, 1999 at 01:49:08AM %2B0100 References: <19991125030328.A476@grok.localnet> <199911270049.BAA02450@oranje.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 27, 1999 at 01:49:08AM +0100, Marc van Woerkom wrote: > Last time I checked, the code started to improve for G200/400 but > got slower for RIVA (some optimizations to Mesa 3.0 got lost in the > upgrade to Mesa 3.1). That was one reason why I did not upgrade > to latest glx sources, as I have just RIVA based cards to test. I don't have any RIVA based cards to test, only an MGA G200. But I've been watching the glx-dev list and I don't think there's been much development on the RIVA front. Nearly all of the development seems to be on the Matrox cards because their specs are open. > > With all that taken care of GLX should compile and run without > > modifications > > OK, I will have a look at the latest version. Sounds like the > CVS version improved. Possibly I have to separate things for Matrox > and nvidia users. Again, I haven't tried it with a Riva, so I don't know how well or even if it will compile for that code. If my experience with the MGA code is any indication, any problems should be easily solvable by #ifdef'ing out the Linux-specific parts. > From the description in LINT I was not sure that MAXMEM overrides > the values from the memory probe routines, in case they notice > memory above 64 MB. Did you test it? I've only tested it on my 64MB machine, "MAXMEM=(56*1024)". From dmesg: real memory = 58720256 (57344K bytes) avail memory = 54362112 (53088K bytes) I don't see anything in LINT suggesting any probe overriding MAXMEM, just that you may need to use MAXMEM to override a faulty probe. > In your running q3, is the glx module used a Linux or a native FreeBSD > binary? Same question for the X Server - Linux or native? The GLX module was compiled under FreeBSD using the egcs port (gcc295). The X server is a FreeBSD binary, from ftp.freebsd.org. FreeBSD binaries use the FreeBSD-compiled libGL.so, and Linux binaries use the Linux-compiled libGL.so, exactly as you would expect. They shouldn't (and apparently don't) care what type of binary the server is because of the normal X client/server separation. I'm not sure how that equation will change when direct rendering becomes available under FreeBSD. > > The key was to update the Linux libs. Linux user Ralph Giles sent me > > the libs from his system. > > Are these any different from the libraries which are installed by > ports/emulators/linux_base? I haven't updated my linux_base since I installed FBSD 3.2-R, but I'm quite certain linux_base doesn't include the extras required for 3D. Specificly, all of the 3D stuff requires libGL at a minimum, and some things require libGLU and libglut. I haven't checked but I don't think those are included in linux_base. If they are, they'd do software rendering instead of talking GLX, else they wouldn't work for people who have no GLX module. Some things (both Linux and FreeBSD) expect libMesa(GL|GLU|glut), but I've had no problem just using symlinks to lib(GL|GLU|glut). It seems that the libGL does have to match the glx.so version in some way. I think they just need to both be built with an equivalent version of Mesa so that they both use all of the same data structures. I could not successfully run Q3 using old Mesa-3.0-compiled Linux libs with a Mesa_3_2_dev-compiled FreeBSD glx.so, but it worked without a hitch when Ralph Giles sent me his Mesa_3_2_dev-compiled(I think?) Linux libs. Mesa 3.2-dev is the stabilizing-for-release version of Mesa 3.1, in case you're wondering. The unstable development version is now 3.3. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991126190138.A828>