Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Mar 2000 14:06:10 -0800
From:      Steve Reid <sreid@sea-to-sky.net>
To:        Marc van Woerkom <van.woerkom@netcologne.de>
Cc:        reg@FreeBSD.ORG, kuku@gilberto.physik.rwth-aachen.de, cokane@one.net, cracauer@cons.org, multimedia@FreeBSD.ORG
Subject:   Re: GLX Xserver for FreeBSD?
Message-ID:  <20000314140610.A408@grok.localnet>
In-Reply-To: <200003140102.CAA10193@oranje.my.domain>; from Marc van Woerkom on Tue, Mar 14, 2000 at 02:02:05AM %2B0100
References:  <200003011009.LAA37864@gil.physik.rwth-aachen.de> <20000301113408.A79072@cons.org> <20000301104653.A11506@evil.2y.net> <20000301165323.A40061@gil.physik.rwth-aachen.de> <20000301085111.F54218@shale.csir.co.za> <200003140102.CAA10193@oranje.my.domain>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 14, 2000 at 02:02:05AM +0100, Marc van Woerkom wrote:
> > managed to update the glx port to a later snapshot, but haven't been
> > able to get around to 1. Getting a good (ie stable) tarball on a fixed
> > distribution site,
> 
> This can be put on the FreeBSD site once we agree on what
> Utah glx snapshot to use.

Sometime in January they switched to a unified model where support for
all chipsets is compiled into glx.so and dlopen() is used to select the
right driver once the chipset is determined. Allegedly there is a bug in
FreeBSD's dlclose() (in 3.2 at least). This caused the X server to sig11
when it loaded the glx.so module at startup.

The current version skips the dlclose() #ifdef __FreeBSD__ which is a
kludge but at least allows GLX to work here. Unfortunately I haven't
been able to get direct rendering to work with Linux Q3A using recent
Linux-compiled libGL.so/glx.so from matroxusers.com (Linux binaries
requires Linux libs). Q3 reports an undefined symbol error and reverts
to indirect rendering (which works but takes a large FPS hit).

So IMHO the best version is from late December / early January. The date
flag to CVS can get the right version.

BTW, I'm using a Matrox G200. Other chipsets may have different results.
Currently I'm using FreeBSD-compiled GLX cvs'ed December 23rd and to
play Quake 3 with direct rendering I've extracted libGL.so/glx.so from
glxMesa-19991222-1.i586.rpm and placed them in my /compat/linux. The
.rpm file I got from matroxusers.com; it's no longer there but I still
have a copy if anyone needs it. For direct rendering with Linux binaries
the Linux libGL.so needs to be slightly hacked to load the Linux glx.so
instead of the FreeBSD glx.so. I get around 21 FPS on demo001 using
default settings, which is about the same as Win9x users are reporting.

> > This is just more a pointer, that later (and faster) GLX code can work
> > with XFree86 3.3.6 and Mesa 3.1. 

Recent GLX requires Mesa 3.2 (there is a release tarball) or the
mesa_3_2_dev branch in order to compile.

> The speed increase has been reported for Matrox users primarily,
> the nvidia source did see only some bug fixes - the reason is 
> that Matrox released real specs and nvidia not.

Support for a few other chipsets has been added. 



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?20000314140610.A408>