From owner-freebsd-multimedia Fri Nov 26 19: 0:46 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E9F914F5E for ; Fri, 26 Nov 1999 19:00:40 -0800 (PST) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (unknown@analog13.sq.mntn.net [204.244.200.22]) by tusk.mountain-inter.net (8.9.3/8.9.3) with ESMTP id TAA16403; Fri, 26 Nov 1999 19:00:43 -0800 Received: by grok.localnet (Postfix, from userid 1000) id 61471212E07; Fri, 26 Nov 1999 19:01:38 -0800 (PST) Date: Fri, 26 Nov 1999 19:01:38 -0800 From: Steve Reid To: Marc van Woerkom Cc: multimedia@FreeBSD.ORG Subject: Re: Success: Quake 3 DemoTest under FreeBSD with Matrox G200 Message-ID: <19991126190138.A828@grok.localnet> References: <19991125030328.A476@grok.localnet> <199911270049.BAA02450@oranje.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199911270049.BAA02450@oranje.my.domain>; from Marc van Woerkom on Sat, Nov 27, 1999 at 01:49:08AM +0100 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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