Re: [Dri-devel] mga.o still doesn't use AGP memory for g200 ?

2001-05-25 Thread KaLTaN
On Thursday 24 May 2001 11:24, you wrote: > > > > I have been trying your patch against the current XFree86-CVS and it > > seems to work quite well with my G400MAX. running quake2,Q3A and > > xscreensaver hacks. Running at 1600x1200x32 with 32Mb allocated to > > agpsize I did not encounter any in

Re: [Dri-devel] mga.o still doesn't use AGP memory for g200 ?

2001-05-25 Thread ralf willenbacher
"Peter Soetens (KaLTaN)" wrote: > If other people experience similar successes with other mga cards, i think it > would be cool if they (Gareth etc) made it part of the main branch. with xf4.1 knocking on the door this would be a rather bad moment. -- ralf willenbacher ([EMAIL PROTECTED])

[Dri-devel] Question on r128

2001-05-25 Thread Alexander Strohmaier
Hello I have some problems with DRI on my computer for quite a while already. (http://www.xfree86.org/pipermail/xpert/2001-May/008040.html). In particular I can crash my server by using UseCCEFor2D option and things are horribly slow (not useable), though glxinfo says that I have DRI. XFree86 t

Re: [Dri-devel] MGA Driver Performance

2001-05-25 Thread Ben Smith
On Wed, 23 May 2001, Brian Paul wrote: > > We haven't done any real work on the MGA driver in a long time. > Nobody's funding us to do so. > > You may get a bit of a performance improvement when we move > to Mesa 3.5-based driver. (still underway) > > -Brian > > __

Re: [Dri-devel] MGA Driver Performance

2001-05-25 Thread Ben Smith
I'm really sorry about that. I was going to cancel and I(obviously) wasn't paying enough attention. I was going to cancel because I thought I would look at the source some before saying anything, but since I've inadvertently delurked I may as well say it anyway. I have a matrox G400. I have

[Dri-devel] Voodoo5 on FreeBSD

2001-05-25 Thread Eric Anholt
I figured out (kind of) why the v5 causes segfaults in GL apps on FreeBSD. It seems that when we try to dlopen() the extra symbols for v5, the dlopen passes but the subsequent dlsym()s fail, so we end up executing these null pointers at the first glide extension call. By dlopening my libglide