Date: Tue, 14 Mar 2000 02:02:05 +0100 (CET) From: Marc van Woerkom <van.woerkom@netcologne.de> To: reg@FreeBSD.ORG Cc: kuku@gilberto.physik.rwth-aachen.de, cokane@one.net, cracauer@cons.org, multimedia@FreeBSD.ORG Subject: Re: GLX Xserver for FreeBSD? Message-ID: <200003140102.CAA10193@oranje.my.domain> In-Reply-To: <20000301085111.F54218@shale.csir.co.za> (message from Jeremy Lea on Wed, 1 Mar 2000 08:51:11 -0800) 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I was about to install /usr/ports/graphics/glx > > when I found in the end that XF336 which I am using under > > 4.0-current is 'too new' for that version of GLX. The version check in the port is just a precaution - the port is very likely to work with 3.3.6 once you change the number in the makefile. > I was playing with Will Andrew's update to the Mesa3 port, which > compiles, and means that you can use later utah-glx code out the box. The development effort went into a couple of directions, with code incarnations showing up on a couple of sites which makes tracking a bit more complicated than usual: - Mesa is gone through a few bumps (could be around 3.2 now) - openprojects.net glx project renamed itself into Utah glx to distinguish itself from the SGI implementation of the glx protocol (which is the glx from XFree86 version 4 and the reason why you can`t use a Utah glx module with XF4) - XFree86 changed from 3.3.x to 4.x branch - Next to indirect rendering via glx (where every command goes through the X protocol) there is work on the direct rendering (DRI) going on - it takes place first on the DRI project at SourceForge and then gets patched into the XFree86 main branch. So far only the Voodoo driver is in, the Matrox one is expected soon. Nothing definitive about nvidia yet, although the are believed to do some binary only release using that new XF4 loader.. It is clear that the XFree86 4.x version and the Direct Rendering Infrastructure will be the stuff that has the largest potential. While 4.0 is labeled as a release, my experiences from Monday and Tuesday (less stable - got a couple of Linux Netscape 4.72 crashes and a brand new Mozilla died too on similiar pages, plus the lack of certain features like the Shape extension used by Windowmaker) let XF 4 feel more like a development version than a stable release. Except maybe for Voodoo people (this stuff has been ported by Doug Rabson to FreeBSD), it makes not much sense using now for the other cards. Thus it worth the effort to polish the existing stuff for the XFree86 3.3.6 line - which I continue tomorrow. > 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. > 2. Verifying that it actually works, What do you use? My own cards are nvidia ones, for Matrox I am sure we find some tester here or in my list of people who helped testing Matrox in the past. > 3. Polishing up the port. The glx update should be possible this week. For The Mesa update I have to look through my mail archives to understand what happened there. > This is just more a pointer, that later (and faster) GLX code can work > with XFree86 3.3.6 and Mesa 3.1. You are right. 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. Regards, Marc 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?200003140102.CAA10193>