Re: [Dri-devel] DRI on mach64
El Sáb 12 Ene 2002 18:04, David Goodyear escribió: Hi all, Hello. I finally have DRI running with an ati rage mobility mach64 based card. I have run the glxgears benchmark with and without DRI. It seems that there is a huge increase in fps ie without dri 60-70 fps and with dri 200-230 fps. However, I have no ability to change AGPMode. Is this option available for mach64? The driver is not using AGP memory at this stage AFAIK. So, no matter what AGPMode are you saying in the conf file. Additionally, it seems that I cannot run in either mode except 800x600 and 640x480. Is it possible to run at 1024x768? I have tried but no luck. glxinfo says dri is not running and you can easily tell this from the output of glxgears. My card has 4mb ram and I could run gl stuff no problem using utah-glx but it was no where near as stable as the DRI stuff. What is the X log file saying you? I think that you've not enough memory for DRI at 1024x768x16. Anyway I think that 3D at 1024x768 is too much for the old Mach64. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI on mach64
El Dom 13 Ene 2002 01:10, [EMAIL PROTECTED] escribió: El Sáb 12 Ene 2002 18:04, David Goodyear wrote: I finally have DRI running with an ati rage mobility mach64 based card. I have run the glxgears benchmark with and without DRI. It seems that there is a huge increase in fps ie without dri 60-70 fps and with dri 200-230 fps. [also can't run 1024x786] On Sat, Jan 12, 2002 at 08:27:30PM +0100, Manuel Teira wrote: What is the X log file saying you? I think that you've not enough memory for DRI at 1024x768x16. Anyway I think that 3D at 1024x768 is too much for the old Mach64. It's not. I'm running with 8MB, and the mach64 branch runs 1024x768 fine. But, are you able to play Quake3 decently at 1024x768 with your mach64? That's what I wanted to mean, perhaps it's too work for our little rage. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 DMA
Hello again. First of all, happy new year to everybody. Well, after the holidays, I would like to recover the development in the mach64 branch. I started today to investigate the DMA stuff because I think that perhaps Frank is very busy and he has no time to do this work. The DMA problem was discovered aprox. Oct 21th and we have no news about any progress in DMA. I'm sure that Frank would do it better than me, but I can try. And now, the questions: I've been looking at the r128 freelist implementation, so I've derived that the register called R128_LAST_DISPATCH_REG (actually R128_GUI_SCRATCH_REG1) is used to store the age of the last discarded buffer. So, the r128_freelist_get is able to wait for a discarded buffer if there's no free buffer available. Could this be made in the mach64 driver, say with MACH64_SCRATCH_REG1 ? In my register reference it says that these registers can be for exchanging information between the BIOS and card drivers, so, is sane to use them for this task? I've also seen that there's no r128_freelist_put (it's present in mga driver, for example). Isn't it necessary? And, when is a buffer supposed to be discarded. Is this situation produced in the client side? Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
El Mar 11 Dic 2001 15:51, Michael Thaler escribió: On Tue, Dec 11, 2001 at 12:45:59PM +, Jose Fonseca wrote: Me neither. That's not a problem, just login as anonymous: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login Press enter for password and then cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc I start to feel really stupid. I tryed it again and again I got errors. I followed your instructions and did: mkdir DRI-CVS cd DRI-CVS cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co -r mach64-0-0-2-branch xc ln -s xc XFree40 mkdir build cd build lndir -silent -ignorelinks ../XFree40 cd ~/DRI-CVS/build/xc/ make World World.LOG + gcc -o ./libGL.so.1.2~ -shared -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/glapinoop.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -L/usr/X11R6-DRI/lib -lXext -lX11 -ldl -lc /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[5]: *** [libGL.so.1.2] Error 1 I've checked and Xext is not built after all. It must be already available. For that you need to make the 'lndir' stuff _before_ building so that the linker finds it (note the -L/usr/X11R6-DRI/lib in the command line). How do I have to do that? I don't think that lndir'ing from /usr/X11R6 to /usr/X11R6-DRI will do any good. Xext is not builded in the DRI compilation process. This is because the dri trunk (branch) is a stripped-out version of the XFree source code. This is because you MUST lndir your existing XFree distro files to the /usr/X11R6-DRI directory, where DRI compilation is trying to find the libs, as you can read in the line: ... -L/usr/X11R6-DRI/lib -lXext ... So, the first thing that you have to do is check if there is a libXext.so.* in your /usr/X11R6-DRI/lib. If you have that library there, I don't understand your problem, and in the other case, you know what to do now. As soon as I managed to compile this I will write a short compilation guide because I think the compilation guide on the webpage is really outdated and there are probably a lot of people who want to get the mach64 working. I think that compiling the mach64 branch is as difficult as compiling another branch or the trunk. All of them are stripped-source versions (I'm not sure now about the mach64-0-0-1, perhaps this was a complete X source tree ) and you need an starting XFree install. Best regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] First experience with binary shapshot
El Mié 05 Dic 2001 15:02, escribiste: Sergey V. Udaltsov wrote: Hi all Thanks to Jose, I got some binary stuff to test: lib/modules/2.4.9-13/kernel/drivers/char/drm/mach64.o usr/X11R6/lib/modules/drivers/ati_drv.o usr/X11R6/lib/modules/drivers/atimisc_drv.o usr/X11R6/lib/modules/drivers/r128_drv.o usr/X11R6/lib/modules/drivers/radeon_drv.o But I did not have much success: 1. The kernel module loaded perfectly. No complains. 2. The driver uses ABI v 5 but XFree 4.1.0 gives ABI version 4. First I had a similar problem until recognizing that I alwas started the old X-Server with the new modules because I just edited the /etc/X11/XF86Config file. Try to start e.g. /usr/X11R6-DRI/bin/XFree86 explictly... Just a thought ;-) BTW my X-Server is running now but I get strange authentification failures: the DRM module isn't allowed to write to X while I'm not logged in as root. kdm also fails on startup with XDM-AUTHENTIFICATION failure Does anybody know how to fix this quick ( I haven't had time yet to read something about that issue ) --Andreas Karrenbauer PS: Because of a new job I haven't had much time the past month, but congratulations to Manuel Teira. He's done very well. I'm listening to the list and hope to find time to contribute in any way Thank you, Andreas. It's nice to hear about you again. I think we're on the way for an stable DRI support for our Mach64 cards. What I use to do for testing the unstable driver is using a different init script for the DRI XServer. Something like: #!/bin/bash export LD_LIBRARY_PATH=/usr/X11R6-DRI/lib xinit /home/mteira/bin/xinitdri -- /usr/X11R6-DRI/bin/XFree86 I call this script: XDRI.sh And /home/mteira/bin/xinitdri is just an .xinitrc init script for starting the window manager, something like: #!/bin/bash WMANAGER=wmaker xmodmap ~/.Xmodmap xrdb ~/.Xresources if [$WMANAGER = wmaker \ -o $WMANAGER = icewm \ -o $WMANAGER = blackbox \ -o $WMANAGER = pwm ]; then xconsole -bg black -fg green -geometry 600x150+0+0 -fn 6x10 -file /dev/xconsole aterm -geometry 80x24+0+180 -sl 500 -bg black -fg yellow -fn fixed fi exec $WMANAGER In this way, I have a different window manager (WindowMaker) for my 3D tests, than the one I have for my everyday work (KDE). BTW, Leif, have you investigated any further on the VT change locks. Perhaps we have forgot to lock some other function... And Frank. when do you estimate we could play with your DMA code? Sorry, but I've been busy at work lately and also thought that it would be better for me to keep my strength for the new DMA code. Go on, Frank! ;-) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
El Dom 28 Oct 2001 00:10, Leif Delgass escribió: On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 21:40, Leif Delgass escribió: On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 19:49, Leif Delgass escribió: Well, I just got my box to hang hard (like with the vt switching) when running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes defined in my config and the hang happened when looping back to the original mode, i.e. the third switch), so I think the answer is yes, it needs locking. I really should use a journalling filesystem, all this fsck-ing is getting a bit tedious. ;) OK. I have added the DRILock/Unlock to the AtiModeSet function in the atimode.c file. I've added another condition (also to the locks in the aticonsole.c file for vt changing) in this way: It looks like ATIEnter/LeaveVT calls ATIEnter/LeaveGraphics, which in turn calls ATIModeSet. Won't this lead to trying to obtain a lock when the lock is already secured? It might be better to put the lock in aticonsole.c in the ATIModeSwitch function. You are right, I was deadlocking the server. Anyway, the idea is that ATIModeSet has to Lock and Unlock, but ATIEnterVT(LeaveVT) has only to Unlock(Lock) the DRM. We could Lock/Unlock in ATISwitchMode, but I think that we are locking more that needed, because the ATIModeCalculate that is also called from ATISwitchMode doesn't need to be locked. I think that the better way to do this is: ATIEnterVT: Unlock at the end of the Function (to avoid interlocks) Well, here I wanted to say 'at the beginning of the Function'. Sorry. ATILeaveVT: Lock at the end of the Function (to avoid interlocks) ATIModeSet: Lock at the beginning and Unlock at the end. What do you thing about this? Well, let's look at the sequence assuming what you suggest. This is as much for me to get it straight in my head as anything else... Xserver is running. We switch to text mode: 1. ATILeaveVT is called, which calls ATILeaveGraphics 2.ATIModeSave 3.ATIModeSet (DRILock,DRIUnlock) 4.ATILock, return from ATILeaveGraphics 5. DRILock I'm not sure it's worth unlocking just to lock again here. Text mode is running. We switch to graphics mode: 1. ATIEnterVT is called, which calls ATIEnterGraphics 2.ATIUnlock 3.ATIModeCalculate 4.ATIModeSave 5.ATIModeSet (DRILock,DRIUnlock), return from ATIEnterGraphics Oops!, at this point we still hold the DRILock, so again we'll be trying to lock twice, right? 6. DRIUnlock Here we've already unlocked. Yes, you're right. Too late to think yesterday. Well, we could unlock at the _beginning_ of ATIEnterVT, but here's what I would suggest... Don't do locking/unlocking in ATIModeSet, but do the locking in the three functions in aticonsole.c: ATILeaveVT() 1. DRILock, then call ATILeaveGraphics 2. ATIModeSave 3. ATIModeSet (ok, we've got the lock already) 4. ATILock, return from ATILeaveGraphics 5. return ATIEnterVT() 1. call ATIEnterGraphics 2. ATIUnlock 3. ATIModeCalculate 4. ATIModeSave 5. ATIModeSet (we still hold the DRILock), return 6. DRIUnlock, return ATISwitchMode() 1. ATIModeCalculate 2. DRILock 3. ATIModeSet 4. DRIUnlock, return At a first glance, it looks that this aproximation is the best. The idea is use for the locking the upper functions to avoid interlock problems. We do not want to use our locks from 2 levels of functions. In this way, I think there is no problem. Here you can still avoid locking until after the mode calculate. Also ATIModeSet is called by ATIClockPreInit, and I don't think DRI locking is necessary at that point (in fact, I think it happens before the DRI initialization?). Of course, this is my high-level view (I haven't followed all the code in the sequence in detail) and I could be missing something. I'm also not sure exactly _where_ the lockup happens and so I'm not sure how fine grained the locking can get. What do you think? My idea is that we don't need more detail. We just need to lock when a mode change is made (both for going to text mode or changing the screen mode) and that changes are made with the API defined in aticonsole.c. snip src=from your other mail OK, I actually looked at the definition of DRILock/DRIUnlock (programs/Xserver/GL/dri/dri.c), and it does reference counting, so locking twice might not be an issue, it just increments the reference count. What I haven't found yet is where the DRM_LOCK/DRM_UNLOCK macros used in DRILock/DRIUnlock are defined, and I'm not sure how contention is handled either. So I'm going to try and get a better idea of how the locking is actually implemented, and hopefully I know what I'm talking about next time. /snip I still think that we should avoid more than one consecutive locks. It has nonsense from my point of view, at least in this case. The DRM_LOCK
Re: [Dri-devel] Mach64 locking on mode switches
El Dom 28 Oct 2001 19:17, Leif Delgass escribió: snip OK. I did test it out doing it in the way I suggested, but I'm still getting a lockup. I was thinking of compiling with the debugging macros turned on to get a better idea of where the problem is. Since the problem doesn't seem to happen with gears, I wonder if there's something in the mesa code that isn't locking properly. Have in mind that the Mesa layer is now writing directly to the registers. Are this direct writes locked in all the Mesa lib? For example, and at a first glance, the function: mach64UploadHwStateLocked @ mach64_ioctl.c is making WRITE access to the card without calling LOCK_HARDWARE. Perhaps this funcion is called from another place were the lock takes place, I don't know. Anyway, when the DMA work takes shape on the Mesa layer, the places where the lock is needed will be less than now (I think), only when the DMA buffers are flushed via a BusMaster operation. So, I think that we must not worry about the interlock while the DMA work is not finished. Frank, how is it going? Any news? Well, I've just commited the changes to the CVS. The Sunday is finishing and a new week of hard work is beginning :-( . At least here in Spain the week is shorter (it's only 4 work days). ;-) Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: vt switching
El Vie 26 Oct 2001 22:11, Leif Delgass escribió: Manuel, the hang when switching back from a vt to X with Quake running hangs both in fullscreen and windowed mode (other GL apps like gears don't exhibit this problem, although there is initially some garbage at the top of the screen when returning to X). I'm sure you're right that it has to do with the locking (or lack thereof) in the enter/leaveVT. And with that I'm heading out, I'll try to do some more investigation tommorow... Well. I've written a pair of macros to interlock drm and Xdriver and used it in all the accelerated access from the XDriver. I've also used the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the aticonsole.c file. After this, we cannot enable 2D accelerated rendering yet, because the drm and mesa sides are not honouring this interlocking. This should be made when Frank has the new DMA API finished, because the points to lock will be less than now (I suppose that we only will need to lock the actual DMA transfers) because the DMAOUTREG is only going to append the register writes to a DMA buffer. So, I suppose that the EnterVT/LeaveVT bug is still here, because of a non locking DRM. Anyway, I tried to reenable 2D acceleration and run gears. The engine locked after trying to close gears, but the cursor still worked. My idea is updating the branch with this changes (still without reenabling the 2D acceleration) and Leif ones for the AGP corrections. Leif, I've (#ifdef)ed the AGP code as you told me, but I think that your host.def changes are good for the mach64 branch (disabling the Glide dependencies and enabling builds of DRM drivers) and I plan update it too. Another secondary issue: I'm still have a problem compiling the branch: The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of shared libraries and I think that there is no need to build this utilities in the DRI context. So, I'm also going to add another change to the host.def file: -#define BuildXFree86ConfigTools YES +#define BuildXFree86ConfigTools NO In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable this tools build: ... #if !BuildServersOnly || BuildXFree86ConfigTools XF86CFGDIRS = xf86cfg xf86config #endif ... and we will need less libraries. Finally, and to accelerate the build, the line: #define XF86CardDrivers tdfx i810 mga ati glint vga should be: #define XF86CardDrivers ati And perhaps: #define XFree86CustomVersion DRI trunk should be replaced by: #define XFree86CustomVersion DRI mach64 branch Do you agree ? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 2D driver
El Sáb 27 Oct 2001 16:08, Michel Dänzer escribió: Hi everybody working on the Mach64 driver, I think it's really important for you to get in touch with the 2D driver maintainer, Marc Aurele La France [EMAIL PROTECTED]. First because he is the single most competent person about the 2D driver and probably about the Mach chips in general, second because he doesn't like other people messing with his code. ;) Thanks Michel, for the advise. I thing that the best is wait for Frank to finish the DRM DMA API and then see if the locking is working fine. After this, we could present and explain to Marc Aurele the changes we have made to know his opinion about them. Anyway the changes in the 2D code are very few: 1.-Avoid changes in the GUI_CNTL for the fifo depth. Perhaps we could notify this issue to Marc and try to find another solution. 2.-Make the 2D accelerated functions honour the DRM locks. This is still work in progress and I think that we must wait after checking this code to disturb Marc about it. 3.-Make the LeaveVT and EnterVT honour the DRM locks. The same than the previous point. I think that there were no more changes but the initialization for DRI written by Gareth (that are new and not written by Marc) and the hacks disabling 2D acceleration that I hope we will be able to remove in short. Regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: locking, patch
El Sáb 27 Oct 2001 18:49, Leif Delgass escribió: First off, I messed up on the FIFO size defines in mach64_drv.h (drm kernel module), they should be: # define MACH64_CMDFIFO_SIZE_MASK 0x0003ul # define MACH64_CMDFIFO_SIZE_192 0xul # define MACH64_CMDFIFO_SIZE_128 0x0001ul # define MACH64_CMDFIFO_SIZE_64 0x0002ul I was mixing up my hex and binary, yikes! (at least 1 is always 1 so no harm done) Embarassing. Don't drink and code. Anyway... :-) Fixed. Well. I've written a pair of macros to interlock drm and Xdriver and used it in all the accelerated access from the XDriver. I've also used the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the aticonsole.c file. After this, we cannot enable 2D accelerated rendering yet, because the drm and mesa sides are not honouring this interlocking. This should be made when Frank has the new DMA API finished, because the points to lock will be less than now (I suppose that we only will need to lock the actual DMA transfers) because the DMAOUTREG is only going to append the register writes to a DMA buffer. So, I suppose that the EnterVT/LeaveVT bug is still here, because of a non locking DRM. What about mode switches? The mga and i810 drivers use DRILock/DRIUnlock in the ModeInit functions, and the r128/radeon drivers have a comment that says: /* FIXME? DRILock/DRIUnlock here? */ I don't know if it's necessary. Perhaps we could try to change the screen mode while running gears or Quake3. If the machine locks, then, it'll be necessary. ;-) Anyway, I tried to reenable 2D acceleration and run gears. The engine locked after trying to close gears, but the cursor still worked. My idea is updating the branch with this changes (still without reenabling the 2D acceleration) and Leif ones for the AGP corrections. Leif, I've (#ifdef)ed the AGP code as you told me, but I think that your host.def changes are good for the mach64 branch (disabling the Glide dependencies and enabling builds of DRM drivers) and I plan update it too. Another secondary issue: I'm still have a problem compiling the branch: The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of shared libraries and I think that there is no need to build this utilities in the DRI context. So, I'm also going to add another change to the host.def file: -#define BuildXFree86ConfigTools YES +#define BuildXFree86ConfigTools NO In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable this tools build: ... #if !BuildServersOnly || BuildXFree86ConfigTools XF86CFGDIRS = xf86cfg xf86config #endif ... and we will need less libraries. Finally, and to accelerate the build, the line: #define XF86CardDrivers tdfx i810 mga ati glint vga should be: #define XF86CardDrivers ati And perhaps: #define XFree86CustomVersion DRI trunk should be replaced by: #define XFree86CustomVersion DRI mach64 branch Do you agree ? I think these changes are fine for the branch, it should speed up the build. We'll just need to make sure not to merge them to the trunk when the time comes. Well, I think that we (or whoever that do it) don't even try to merge our host.def to the main trunk, it has nosense. I think that I will update the CVS branch this night. There aren't very important changes, but I think that it's better to have the branch as updated as possible. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third switch), so I think the
answer is yes, it needs locking. I really should use a journalling
filesystem, all this fsck-ing is getting a bit tedious. ;)
OK. I have added the DRILock/Unlock to the AtiModeSet function in the
atimode.c file. I've added another condition (also to the locks in the
aticonsole.c file for vt changing) in this way:
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRILock(pScreen,0);
}
#endif
...
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRIUnlock(pScreen);
}
#endif
I think this is a better way because the code in aticonsole.c and atimode.c
is generic for all the ATI adapters, so we are restricting the checking to
the Mach64 chips greater than the GT that is the first one (if I'm not
mistaken) supporting 3D.
I'm also changing the related macros for locking the 2D accelerated functions.
--Leif
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió: On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 19:49, Leif Delgass escribió: Well, I just got my box to hang hard (like with the vt switching) when running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes defined in my config and the hang happened when looping back to the original mode, i.e. the third switch), so I think the answer is yes, it needs locking. I really should use a journalling filesystem, all this fsck-ing is getting a bit tedious. ;) OK. I have added the DRILock/Unlock to the AtiModeSet function in the atimode.c file. I've added another condition (also to the locks in the aticonsole.c file for vt changing) in this way: It looks like ATIEnter/LeaveVT calls ATIEnter/LeaveGraphics, which in turn calls ATIModeSet. Won't this lead to trying to obtain a lock when the lock is already secured? It might be better to put the lock in aticonsole.c in the ATIModeSwitch function. You are right, I was deadlocking the server. Anyway, the idea is that ATIModeSet has to Lock and Unlock, but ATIEnterVT(LeaveVT) has only to Unlock(Lock) the DRM. We could Lock/Unlock in ATISwitchMode, but I think that we are locking more that needed, because the ATIModeCalculate that is also called from ATISwitchMode doesn't need to be locked. I think that the better way to do this is: ATIEnterVT: Unlock at the end of the Function (to avoid interlocks) ATILeaveVT: Lock at the end of the Function (to avoid interlocks) ATIModeSet: Lock at the beginning and Unlock at the end. What do you thing about this? OK. I'm attaching a small patch that defines and uses a convenience macro used by the other drm drivers (LOCK_TEST_WITH_RETURN). We can use this when we add more ioctls. The patch also includes the FIFO size defines, but you can just say no to that and delete the .rej file. All right. I've commited the changes to the CVS branch yet, but I have to fix the deadlock you've found, so, I'll also send the changes you've sent me. On a totally unrelated note, do you know how to get etags to index KR style functions like the ones in aticonsole.c? No. Sorry. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Questions about locking
Hello. I was investigating on how to allow both 2D and 3D acceleration in the Mach64. So I'm a little confused: First of all, I looked at the R128 and RADEON drivers and they are only doing a DRILock/DRIUnlock in the LeaveVT and EnterVT functions. Does this mean that those cards can do 3D and 2D operation at the same time? Then I looked a little in the mga 2D driver and a few more locking operations are showed. After this, I'm not sure about what we must interlock between 2D and 3D operation. I would like to know what do you think about the following assumptions: 1.-The proper function to lock 3D operation from XFree is DRILock. 2.-We must lock all the operations in the 2D driver that tries: Mach64WaitForIdle Mach64WaitForFIFO to guarantee that the reached FIFO condition is true. This investigation shows me another funny thing: When the 2D Xfree driver only has to make one register write, it doesn't try a Mach64WaitForFIFO. Is this correct? If the DRI driver was writing on the command FIFO, couldn't the 2D attempt to write on the FIFO fail ? On the other hand, when there are more than one register write, say N-register writes, the 2D driver makes a Mach64WaitForFIFO(N) before trying to write to the registers. Is there any other 2D operation that we should need to lock? What criteria must I follow to make this the right way? I suppose that I don't need to lock any register write, but I'm not sure, because the FIFO could get full while I'm writing from the 2D driver. I will keep looking to the other drivers, but I would like to have others opinions. On the MESA side, it looks that the hardware locking is already implemented through the functions LOCK_HARDWARE and UNLOCK_HARDWARE. Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Questions about locking
El Vie 26 Oct 2001 20:21, Leif Delgass escribió: I haven't done an extensive look at this, but I've noticed a couple of things. The 2D driver seems to use a caching scheme for register writes. Also, at one point I had a nasty lockup trying to switch to a vt from fullscreen quake, but I haven't tried it with my latest build yet. I've noticed other drivers have a fullscreen ioctl, but the mach64 currently does not. It seems that once we have the DMA interface defined, we'll want the 2D acceleration to use that as well as the locking scheme, right? Frank, any progress there? I have been looking to the register caching. I don't know if this caching has sense once the DRI is also writing directly to some of the registers. I saw seldom times this in my XFree log file: .. $REGISTER_NAME write cache disabled! this is written by the Mach64Sync function, that compares all the cached register values with the actual values ( and shows that error when values differ). I commented out the register caching when trying to find the DMA problem (it's still commented out in the branch code). I've also noticed that the other drivers (RADEON , R128) don't use the caching 'feature'. I've also seen the outm/inm outf macros (atimach64io.h). These are the ones that provides the cache features. I wonder if we should block the hardware for any of these macros (to guarantee that the FIFO entries are true). Anyway, I think that there are still race conditions, because this kind of code: ... ATIMach64WaitForFIFO(pATI, 6); outf(SRC_OFF_PITCH, pATIHW-src_off_pitch); outf(SRC_Y_X, SetWord(pATIHW-src_x, 1) | SetWord(pATIHW-src_y, 0)); outf(SRC_HEIGHT1_WIDTH1, SetWord(pATIHW-src_width1, 1) | SetWord(pATIHW-src_height1, 0)); outf(SRC_Y_X_START, SetWord(pATIHW-src_x_start, 1) | SetWord(pATIHW-src_y_start, 0)); outf(SRC_HEIGHT2_WIDTH2, SetWord(pATIHW-src_width2, 1) | SetWord(pATIHW-src_height2, 0)); outf(SRC_CNTL, pATIHW-src_cntl); ... If we only block the ouf macros and the WaitForFIFO macro separately, we cannot guarantee that there will be 6 free slots once the WaitForFIFO has finished (because of the DRM). So, what I think we should do is: 1.- Block all the code that matches the previous template (mainly in atimach64.c) , in this way: DRILock( pScreenInfo-pScreen ); ATIMach64WaitForFIFO( pATI, n ); /* * Here the outf stuff */ DRIUnlock( pScreenInfo-pScreen ); 2.-Disable the Register Caching for all the registers. Perhaps we could later enable the caching for the registers that are not used by the drm driver. Talking about the Q3 hang when switching vts: I don't know if this is the problem, but the other drivers (RADEON, R128) has a DRILock (DRIUnlock) calls when doing enterVT (leaveVT), that mach64 hasn't. I will try to test this behaviour today (once I have Q3 installed ;-) ). On another note, I'm attaching a small patch to fix a few things. 1. The AGP register setup was using the wrong macro, since the registers are in Block 1, it should be using outm() instead of outr(). 2. I added some defines for the FIFO sizes in GUI_CNTL and moved the setup to do_dma_init instead of the busmaster test. 3. I did some general cleanup to fix a couple typos and quiet compiler warnings. 4. The DMA memory allocation used in the busmaster test uses the interface described in the kernel docs (Documentation/DMA-mapping.txt). The 2.4.13 kernel adds 64-bit DMA support, so if you have CONFIG_HIGHMEM defined, dma_addr_t is defined as u64. The code was passing u32 handles to the allocation/free functions instead of dma_addr_t handles. This bit me as I have CONFIG_HIGHMEM4G/CONFIG_HIGHMEM set for some reason (wishful thinking?). I changed this and cast the returned handles to u32 to get addresses to pass to the card. I think this is OK, since 32-bit DMA is assumed unless you use pci_set_dma_mask to indicate that the device can do 64-bit. 5. You can ignore the changes in host.def, my .cvsignore wasn't working for some reason. Let me know if you see any problems with the patch and I'll try to take a look at the locking issues, but I think we need Frank's input there too. At a first glance, it looks fine. I will apply it to the branch once that I see that works fine on my machine. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
El Lun 22 Oct 2001 17:52, Malte Cornils escribió: Manuel Teira wrote: If you find any problem compiling the new branch, please make me know. OK, let me see. With regards to that libXau problem: it 's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the rest of the tree isn't necessary. Otherwise, I followed the DRI compilation guide under Documentation. O.K. This is just a issue derived from the trimming of the DRI trunk, I hope. The build (or rather, the make install) failed until I removed tdfx from line 821 in file X11R6-DRI/build/xc/lib/GL/mesa/src/drv/Makefile. Have you got errores related to the glide library? Perhaps you should comment out the line: #define HasGlide3 YES in the host.def file. Or perhaps would be good to comment it out in our mach64 branch. The instructions for making the nls stuff seem to be outdated, since there no longer is any xc/nls in CVS. taking /usr/X11R6-DRI/lib into ld.so.conf doesn 't help for libGL and libGLU, since those already should exist from any previous X installation in /usr/lib, and /usr/lib is implicitly given preference over anything form ld.so.conf. I had to move the old ones away and symlink/copy over the new ones. What I made for the tests was using: export LD_PRELOAD=/usr/X11R6-DRI/lib/libGL.so or export LD_LIBRARY_PATH=/usr/X11R6-DRI/lib Unfortunately, I have a PCI Mach64; modprobe mach64 failed without a helpful error message since agpgart wasn 't installed into the kernel. After modprobing agpgart, then modprobing mach64 (that last one is probably also handled automagically at X startup), glxinfo showed the valued Direct Rendering enabled. And it was; small differences in the display of 3D apps showed that. However, performance was about as slow as software-rendering; at least for gltron, I got about the same average fps as with software mesa. That is probably due to my card not being an AGP variant (also my mainboard does have a - currently empty - AGP slot). I don't know. We are not using any AGP feature just now. What processor does your computer have? I'm getting about 215-220 fps in hw mode and no more than 100 (not exactly) in software mode. That 's about it - I tested 3D with gears, gltron and blender and all worked with a few glitches (not important right now). So, I hope you'll find my report useful. It certainly was fun for me, believe it or not. Thank you for your report. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Problems accessing CVS
El Dom 21 Oct 2001 16:30, Keith Whitwell escribió: Manuel Teira wrote: El Dom 21 Oct 2001 04:18, Daryll Strauss escribió: On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote: OK. Thank you for the clear explanation. Now I think I'm ready to put the new branch in the repository. I'm waiting for the access, guys. As soon as I have access (if i'ts not too late here in Spain) I will proceed. Done Well, it was a little late. I'm trying now, but having problems: export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri export CVS_RSH=ssh bash-2.05$ cvs rtag -b mach64-0-0-2-branch xc The authenticity of host 'cvs.dri.sourceforge.net (216.136.171.202)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cvs.dri.sourceforge.net,216.136.171.202' (DSA) to the list of known hosts. [EMAIL PROTECTED]'s password: ** Could not chdir to home directory /home/users/m/mt/mteira: No such file or directory cvs [server aborted]: can't chdir(/home/users/m/mt/mteira): No such file or directory bash-2.05$ Have I made any mistake or missed anything? It seems some kind of server problem, doesn't it? You probably need to checkout a fresh tree with your new cvsroot. The Root file in CVS/ directories overrides the environment variable from memory so you want to get a new tree with the correct Root files. I've tried to make a checkout and the same error pops. Anyway, I don't need to checkout the tree to make an rtag, do I? I will do the checkout once the rtag is made, then I'll made the checkout of the new created branch, apply the patch and commit the changes. Why shoud I need to checkout the trunk before rtagging it to the new branch? M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Problems accessing CVS
El Dom 21 Oct 2001 16:56, Michel Dänzer escribió: On Sun, 2001-10-21 at 12:43, Manuel Teira wrote: El Dom 21 Oct 2001 04:18, Daryll Strauss escribió: On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote: OK. Thank you for the clear explanation. Now I think I'm ready to put the new branch in the repository. I'm waiting for the access, guys. As soon as I have access (if i'ts not too late here in Spain) I will proceed. Done Well, it was a little late. I'm trying now, but having problems: export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri export CVS_RSH=ssh bash-2.05$ cvs rtag -b mach64-0-0-2-branch xc The authenticity of host 'cvs.dri.sourceforge.net (216.136.171.202)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cvs.dri.sourceforge.net,216.136.171.202' (DSA) to the list of known hosts. [EMAIL PROTECTED]'s password: ** Could not chdir to home directory /home/users/m/mt/mteira: No such file or directory cvs [server aborted]: can't chdir(/home/users/m/mt/mteira): No such file or directory bash-2.05$ Have I made any mistake or missed anything? It seems some kind of server problem, doesn't it? Try again later, administrative changes on SourceForge can take a while to propagate. O.K. I'll try later. Keep Keith's point in mind as well, though it looks to me it was using the correct CVS root. So, are you saying too that I need to checkout the trunk before rtagging ? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Problems accessing CVS
El Dom 21 Oct 2001 17:56, R C escribió: Well, it was a little late. I'm trying now, but having problems: export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri export CVS_RSH=ssh bash-2.05$ cvs rtag -b mach64-0-0-2-branch xc The authenticity of host 'cvs.dri.sourceforge.net (216.136.171.202)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cvs.dri.sourceforge.net,216.136.171.202' (DSA) to the list of known hosts. [EMAIL PROTECTED]'s password: ** Could not chdir to home directory /home/users/m/mt/mteira: No such file or directory I had same problem with gatos dev tree. Workaround is to abort after that error message, change to the subdir generated, then run cvs update. It still complains then, but it at least works. R C I've test your method, but it is still failing with the same error. I've ssh login to dri.sourceforge.net with my account and that directory exists: mteira@usw-pr-shell2:~$ pwd /home/users/m/mt/mteira mteira@usw-pr-shell2:~$ I don't know what to do. Could it be a problem of updating? Or a problem of permisions? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Problems accessing CVS
El Dom 21 Oct 2001 18:56, [EMAIL PROTECTED] escribió: On Sun, 21 Oct 2001, Manuel Teira wrote: El Dom 21 Oct 2001 17:56, R C escribió: Well, it was a little late. I'm trying now, but having problems: export CVSROOT=cvs.dri.sourceforge.net:/cvsroot/dri export CVS_RSH=ssh bash-2.05$ cvs rtag -b mach64-0-0-2-branch xc The authenticity of host 'cvs.dri.sourceforge.net (216.136.171.202)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cvs.dri.sourceforge.net,216.136.171.202' (DSA) to the list of known hosts. [EMAIL PROTECTED]'s password: ** Could not chdir to home directory /home/users/m/mt/mteira: No such file or directory I had same problem with gatos dev tree. Workaround is to abort after that error message, change to the subdir generated, then run cvs update. It still complains then, but it at least works. R C I've test your method, but it is still failing with the same error. I've ssh login to dri.sourceforge.net with my account and that directory exists: mteira@usw-pr-shell2:~$ pwd /home/users/m/mt/mteira mteira@usw-pr-shell2:~$ I don't know what to do. Could it be a problem of updating? Or a problem of permisions? Try doing ssh to cvs.dri.sourceforge.net. This happens because your home directory there is different. (Probably you never used sourceforge cvs before as developer). Read instructions/FAQ on how to use sourceforge on www.sf.net Thank you. This was the solution. I was loggin to a wrong host (dri.sourceforge.net) and my login account was not created. Now, I've just tagged the new branch. Now I'm going to make the checkout of the new branch and committing the changes. Thank all you for your help and excuse me for bugging you with this questions (RTFM would be enough ;-) ). Best regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: BusMastering test seems to work
El Sáb 20 Oct 2001 02:49, Keith Whitwell escribió:
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is
to get the 2D acceleration routines synchronizing with the 3D ones so we
can reenable XAA, right? Also, it looks as if the AGP setup has not been
finished yet. At this point, atidri.c allocates 8M (hardcoded value, but
the agpgart module tells me I have a 64M AGP aperture) and maps 2M of it
for vertex buffers, but it never sets AGP_BASE or AGP_CNTL. There's
currently no allocation of an AGP region for textures. I'm seeing
problems with missing textures in the Quake 3 demo and some other GL
apps.
It's great to get past this hurdle, maybe we can get a new CVS branch
going soon!
Who would need cvs access? It's time this work got some support...
Well. I think we must put this work into CVS ASAP, so everybody could begin
to contribute with all the work that has been unlocked.
I don't mind doing this work, but I only have a 56K modem connection and
never have worked with CVS (could be this is time to learn), only have made
some checkouts.
Now, that we have find the problem (I'd better say the cause), I want to say
that I also commented out a section in the 2D init driver:
if (pATI-Chip = ATI_CHIP_264VT4)
{
outm(GUI_CNTL, pATIHW-gui_cntl);
pATI-nAvailableFIFOEntries = 0;
ATIMach64PollEngineStatus(pATI);
}
This code was updating the GUI_CNTL value, found to be zero for
Chip=ATI_CHIP_264VT4.
Anyway, why is this happening? Is it a card bug? In the register document the
00 value for this register is documented and valid (as the max FIFO length
value).
Well, talking about CVS. What do you think is better? I would made the update
in the CVS if you give me access. It could be nice if someone gives me a
little recipe to made the upgrade without problems, or at least, recommend
some guide about CVS.
--
M. Teira
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Patch to initialize AGP registers
El Sáb 20 Oct 2001 18:02, Frank C. Earl escribió: We can work on parts of it. If you want to do the DMA part (and I won't stop you from it- having said this, I can do that part as well...), we ought to come up with some agreed upon code interfaces to it so that someone else can be plugging away with the Mesa end of things. I think it would be better that you started this task. I don't feel so optimist as yesterday, when the DMA started to work. ;-) I'm sure it'll be the best for the project. I have not the background needed for this and you will make it faster. BTW. It would be nice if the mach64 speed under DRI were 2 times than the speed got under Utah-GLX. It's not a Radeon, but it will be nice to play Q3 with this laptop. I will start the new branch in the CVS ASAP, when they give me access. Best regards ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] /usr/bin/ld: cannot find -lXau
Liam Wilks writes: Could anybody help me with this problem? DRI doesn't seem to want to compile from CVS. I am running Redhat 7.1, with kernel 2.4.5 patched for Win4Lin, and XFree86 4.10. I have an ATI Rage Mobility P/M Graphics Card, which is a Mach 64 based card. I downloaded the alpha patch for ATI Mach 64 today and patched the source tree. I relise that this patch is very early in development and DRI currently does not support Mach 64, however I believe this is not the problem. Below is the tail of the output from compiling DRI: make[5]: Leaving directory `/downloads/dri/DRI-CVS/build/xc/programs/Xserver/hw/xfree86' gcc -o XFree86 -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -L../../exports/lib -L/usr/X11R6-DRI/lib ../../programs/Xserver/hw/xfree86/common/xf86Init.o ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o ../../programs/Xserver/hw/xfree86/common/libxf86.a ../../programs/Xserver/hw/xfree86/parser/libxf86config.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/loader/libloader.a ../../programs/Xserver/hw/xfree86/common/libxf86.a miext/shadow/libshadow.a dix/libdix.a os/libos.a -lXau -lXdmcp ../../lib/font/fontbase.o ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a ../../programs/Xserver/hw/xfree86/common/libxf86.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbx! util/liblbxutil.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a render/librender.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/ddc/libddc.a -lz -lm -rdynamic -ldl -Wl,-rpath-link,../../exports/lib /usr/bin/ld: cannot find -lXau collect2: ld returned 1 exit status make[4]: *** [XFree86] Error 1 make[4]: Target `all' not remade because of errors. rm -f Xserver._man /lib/cpp -undef -traditional -D__filemansuffix__=5x -D__miscmansuffix__=7 -D__drivermansuffix__=4 -D__projectroot__=/usr/X11R6-DRI -D__xorgversion__='Release 6.5 X Version 11' -D__vendorversion__='Version 4.1.99.1 XFree86' Xserver.man | sed -e '/^# *[0-9][0-9]* *.*$/d' -e '/^XCOMM$/s//#/' -e '/^XCOMM[^a-zA-Z0-9_]/s/^XCOMM/#/' Xserver._man rm -f Xserver.1x.html Xserver.1x-html ../../config/util/rman -f HTML Xserver._man \ Xserver.1x-html mv -f Xserver.1x-html Xserver.1x.html macro in not recognized -- ignoring make[4]: Leaving directory `/downloads/dri/DRI-CVS/build/xc/programs/Xserver' make[3]: *** [all] Error 2 make[3]: Leaving directory `/downloads/dri/DRI-CVS/build/xc/programs' make[2]: *** [all] Error 2 make[2]: Leaving directory `/downloads/dri/DRI-CVS/build/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/downloads/dri/DRI-CVS/build/xc' make: *** [World] Error 2 It looks to me that the problem is it can't find libXau.a, however it seems to be there as far as I know. Any help would be appreciated thankyou. I think that you need a previous XFree installation in the /usr/X11R6-DRI, I suffered similar problems with some headers. Perhaps the fastest solution is copying the /usr/X11R6 to the /usr/X11R6-DRI directory to avoid this compilation problems. Then, the installation will overwrite the important stuff. BTW. I'm interested in any problems while applying the patch. Did it work correctly for you? I hope that this helps. Liam Wilks, SportingPulse.Com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
El Mié 17 Oct 2001 11:44, R C escribió: On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote: Regarding theories on DMA and Mach64 and XFree 4.10: I just finished a module that uses the System DMA unit for video capture transfers, and it works fine under a (highly hacked) XFree 4.1.0 server. System: Dual 550 Celeron, All-in-Wonder (original) PCI, 3D Rage II+. XServer is 4.1.0 with Gatos devel branch. Module is for 2.4 kernel. To use this on another card, you would have to enter the proper PCI id in the code. Oh yes, it uses the secondary register aperture, not the linear mapped aperture, but I don't think it makes a difference. Have not tried GUI dma, but it is quite similar. R C I'm sorry, but have no luck trying to install your module. It always bugs me with errors: These ones: #insmod ati_dma.o Oct 18 22:23:49 localhost kernel: PCI: Sharing IRQ 11 with 00:02.0 Oct 18 22:23:49 localhost kernel: PCI: Sharing IRQ 11 with 00:05.0 Oct 18 22:23:49 localhost kernel: Found ATI card at 0xf500. Oct 18 22:23:49 localhost kernel: PCI: Unable to reserve mem region #1:100@f500 for device 01:00.0 Oct 18 22:23:49 localhost kernel: Could not request IO regions! # Or these other ones: #insmod ati_dma.o Oct 18 22:23:51 localhost kernel: PCI: Found IRQ 11 for device 01:00.0 Oct 18 22:23:51 localhost kernel: PCI: Sharing IRQ 11 with 00:02.0 Oct 18 22:23:51 localhost kernel: PCI: Sharing IRQ 11 with 00:05.0 Oct 18 22:23:51 localhost kernel: Found ATI card at 0xf500. Oct 18 22:23:51 localhost kernel: Cannot reserve interrupt: 11 for ATI card! # I don't know what is happening (and many other things). Any idea? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
R C writes: On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote: Regarding theories on DMA and Mach64 and XFree 4.10: I just finished a module that uses the System DMA unit for video capture transfers, and it works fine under a (highly hacked) XFree 4.1.0 server. System: Dual 550 Celeron, All-in-Wonder (original) PCI, 3D Rage II+. XServer is 4.1.0 with Gatos devel branch. Module is for 2.4 kernel. To use this on another card, you would have to enter the proper PCI id in the code. Oh yes, it uses the secondary register aperture, not the linear mapped aperture, but I don't think it makes a difference. Thank you very much. I'll try to see what is missing in the GUI DMA test in the DRI code. At a first glance, I don't remember to have seen a pci_set_master call anywhere in the DRI code. It seems important, doesn't it? Have not tried GUI dma, but it is quite similar. Easier indeed. The directives in the Mach64 Programmer's manual are simpler than for the case you're working on. I'm now at work but impacient to get home and have access to the Mach64 DRI code. Thanks again. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
Mike Westall writes: I spent an incredibly frustrating 4 weeks trying to get the DRI to work with r128 and g400 cards on Dell precision workstation only to find that my problem was precisely because bus mastering was NOT enabled on boot! As soon as I fixed that everything worked fine. Apparently different BIOSes WILL leave the card in different states after boot. Mike Thanks for your comments, guys. In three or four hours (if no new 'browns') we'll have the answer. It would be nice if this were the only problem. ;-) Anyway, I think it won't be the problem, because nobody have had success with the Mach64 Bus Mastering with the DRI ( while having success with Utah-GLX ). Perhaps XFree 3.x setup for the card is different. Best regards -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Patch for the CVS DRI trunk
Hello. I've just finished a patch against the DRI trunk (well, I checked it out one week ago, but I hope the patch will work). Gears is working and the DMA test is still failing. Anyway, I think it's a good thing to start with an up to date codebase. So, please, to any of you interested in helping with the Mach64 development, I would like to know if the patch works for you, and what results are you getting using it. I also recommend migrating to the fresh DRI trunk to share a common codebase. The results you'd expect are: gears working (in my computer is getting about 215-220 FPS) glxinfo working DMA test doesn't work (actually, the busmastering test function is bm_dma_test and it's been called from mach64_do_dma_cleanup in the mach64_dma.c file). Have in mind that mesa is writing directly into the card, because we are still missing a working DMA implementation. One of the pending works could be implementing some kind of pseudoDMA transfers like in the Utah-GLX system (this would be necessary to have a 'secure' driver while we are fighting with BusMastering) Jouko Pynnönen have told me about some diferences between 2D initialization between (XFree 3.x + Utah-GLX) and (XFree 4.1 + DRI). I would try to look further into this. I have posted the patch itself into the sourceforge DRI Project area: [ #471868 ] Mach64 update for the DRI CVS Trunk The patch is a bzip2 compressed unified diff file. Best regards. P.D: I feel that my english is getting worse as time passes. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Mar 25 Sep 2001 07:27, escribiste: On Sun, 23 Sep 2001, Manuel Teira wrote: Perhaps we should work with the latest DRI trunk. Do you think it worth the effort? It seems that most of the changes I noticed have been in the drivers for the newer cards, but I haven't really looked at it that closely at this point. I'm certainly no authority on this, I'm still trying to comprehend everything. ;) A logical analysis: The reset engine code is ORing the BUS_CNTL with 0x00a0, right? But we are suspecting that the component 0x0080 could be read only, and after looking at the code and the defines, it seems that this bit is redefined for the newer cards. Well, if the bit were read-only, the DRI_INFO for that register could learn us something. In my laptop, the BUS_CNTL before and after the DMA tests is always: BUS_CNTL = 0x7b3fa001 As you can see, the 0x0080 is not set, and the 0x0020 is set. Perhaps this is meaning that this bit is read-only and, so, the supposed obsoleted BUS_LAT16X ? What value is holding your BUS_CNTL ? I get 0x7b3fa101 before the test, which is the same except that bit 8 (reserved) is set, and after the DMA test (with the new code that resets the engine) I get 0x7b3fa141 -- BUS_MASTER_DIS is set by the reset code. Yes, excuse me. I'm getting 0x7b3fa041 after the test. Anyway, your results match my suposition that BUS_LAT16X is still present. Regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Dom 23 Sep 2001 04:50, escribiste: According to the register ref. (p.4-26), GB means BGA package, AGP: both 1x and 2x). I have an LT Pro, which has LB in the device ID. This is in the CFG_CHIP_TYPE in CONFIG_CHIP_ID. There's also a class, foundry ID, and major/minor numbers in CONFIG_CHIP_ID. At any rate, I just looked at the dri trunk and it looks like there was a change here. The 'else' (mentioned in my previous mail) is now: else if (Chip ATI_CHIP_264VT4) I checked, and all other references to these regs in the code work the same way, so if the code is correct it seems that: BUS_FIFO_ERR_INT_EN, BUS_FIFO_ERR_INT are used for chips ATI_CHIP_264VTB BUS_HOST_ERR_INT_EN, BUS_HOST_ERR_INT are used for chips ATI_CHIP_264VT4 Perhaps we should work with the latest DRI trunk. Do you think it worth the effort? A logical analysis: The reset engine code is ORing the BUS_CNTL with 0x00a0, right? But we are suspecting that the component 0x0080 could be read only, and after looking at the code and the defines, it seems that this bit is redefined for the newer cards. Well, if the bit were read-only, the DRI_INFO for that register could learn us something. In my laptop, the BUS_CNTL before and after the DMA tests is always: BUS_CNTL = 0x7b3fa001 As you can see, the 0x0080 is not set, and the 0x0020 is set. Perhaps this is meaning that this bit is read-only and, so, the supposed obsoleted BUS_LAT16X ? What value is holding your BUS_CNTL ? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 14:54, escribiste: Hi guys! I've had lot of other things to do in the past weeks so I couldn't work on mach64. I've still problems to compile the trunk with Manuel's patches. I haven't had time to track this down, so I decided to post my changes of mach64_dma.c which I have made in my copy of the mach64-branch. There it compiles well. The GUI-master isn't performed though, but I rewrote the reset_engine function according to the programmer's guide and I call it if the idle test after the transfer failed. So hardware doesn't lock on my machine and I can start X where glxinfo tells me that I'm have hardware based DRI but gears locks my machine so that I have to reboot vie ssh. It's nice to hear about you again. I'll test the changes you've made on my machine ASAP. BTW, I've take a fast look about the way you are allocating the memory for the test: struct pci_pool *pool; void *cpu_addr_table, *cpu_addr_data; void *cpu_addr_table, *cpu_addr_data; pool = pci_pool_create( mach64, NULL, 0x4000, 0x4000, 0x4000, SLAB_ATOMIC ); cpu_addr_table = pci_pool_alloc( pool, SLAB_ATOMIC, table_addr ); cpu_addr_data = pci_pool_alloc( pool, SLAB_ATOMIC, data_addr ); What alignment are you getting on this way? Could we select a diferent alignment using this kind of memory alloc? It is possible, that the mach64_dma.c doesn't compile because I couldn't test it. If something fails please report to me; there may be cut and paste errors. I'll try soon. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 17:03, escribiste: Manuel Teira wrote: have a look at kernel-source-dir/Documentation/DMA-mapping.txt OK. Thanks for the help. there's the explaination about this API. I think we should use this if anybody hasn't any objections. pci_pool_create is specified: pool = pci_pool_create( name, dev, size, align, alloc, flags ); in this case a 16kB buffer aligned to 16kB boundry (16384 = 0x4000) I think it's fine. please tell me status of your Xserver after starting. does it start up? does the hardware lock? are you able to run gears without locking? what does glxinfo tell you? To say you the truth, I haven't been trying to test the XServer with any client. I was just starting it, stopping it (using Ctrl+Alt+BackSpace) and looking at the /var/log/kern.log to see the DMA test status. Now, I've started the X with this command: xinit -- /usr/X11DRI/bin/XFree86 that's the location of my testing XFree server. After that, my WindowManager (KDE) started. I tried the glxinfo after setting the LD_LIBRARY_PATH to : LD_LIBRARY_PATH=/usr/X11DRI/lib and the result is: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Gareth Hughes OpenGL renderer string: Mesa DRI Mach64 20001218 [Rage Pro] x86/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_object, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow Then, I closed my eyes and fired 'gears'. Well, it didn't lock my machine, the gears window only contained garbage, but the program was running, and saying: 1786 frames in 5.002 seconds = 357.057 FPS 1736 frames in 5 seconds = 347.2 FPS Well, I tried it several times, all the time with the same result. On other terminal (without the LD_LIBRARY_PATH variable set) I tried gears, and it runs normally (without 2D or 3D acceleration) and getting around 120 FPS. I would like to compare to my status in order to have the same working ground. Furthermore I suggest to drop the GUI master issue at the moment (it isn't used in the driver right now or am I wrong? and therefore it is just a performance issue) I suppose it's not used, because it never worked, while Gareth code was usable (at least with one of my laptops). If your gears locks too, then I would first track this down. Debuging this is very hard because I have to boot after every try. If you want any log from my computer, please tell me. I'm sending you the mach64_dma.c I'm using (it's just a merge between yours and mine). Perhaps you have to add some extra define to mach64_drv.h to use it, could be: # define MACH64_BUS_APER_REG_DIS (1 4) or # define MACH64_BUS_EXT_REG_EN(1 27) -- Manuel Teira /* mach64_dma.c -- DMA support for mach64 (Rage Pro) driver -*- linux-c -*- * Created: Sun Dec 03 19:20:26 2000 by [EMAIL PROTECTED] * * Copyright 2000 Gareth Hughes * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 18:12, escribiste: Manuel Teira wrote: Then, I closed my eyes and fired 'gears'. Well, it didn't lock my machine, the gears window only contained garbage, but the program was running, and saying: 1786 frames in 5.002 seconds = 357.057 FPS 1736 frames in 5 seconds = 347.2 FPS Well, I tried it several times, all the time with the same result. On other terminal (without the LD_LIBRARY_PATH variable set) I tried gears, and it runs normally (without 2D or 3D acceleration) and getting around 120 FPS. well that's fine I get about the same values. I achieved ca. 350 fps one time and cannot reproduce. Well, I said that it's getting 347 FPS, but nothing is showing in the window, just garbage (and garbage that didn't looks like three wheels). so you are a step further than me. what kind of source are you using? the trunk or the branch? I'm using the XFree 4.1.0 trunk with my modifications, and the mach64_dma.c file I sent you today. Perhaps if I can overcome this compiling errors I have hw accelerated X, too. It would be great if you could do some testing with programs using 3D *AND* 2D and report whether something is wrong (like texture or things like that) When we have a running Xserver perhaps anybody with special connections to ATI could contact we the developers there and ask about some help why the GUI master doesn't work despite it is done as described in the programmer's guide. This only makes sense if we can exclude every other source of errors. The 2D acceleration is disabled in my Xserver (as in the Gareth's code (mach64 branch) ). Perhaps this is what is making your computer hang. If you want any log from my computer, please tell me. First I try to compile the trunk with the changes: for example, it starts at the creation of the Makefiles: at /lib/GL/mesa/src/drv/mach64 the created Makefile is corupt (missing seperator is reported and the Makefile itself is a mess) it's possible that it is easy to fix but I haven't had time to Perhaps your Imakefile is wrong. What codebase are you starting from? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 19:08, escribiste: Manuel Teira wrote: El Sáb 22 Sep 2001 18:30, escribiste: You can pass an argument to isosurf to tell it to render only 100 triangles (isosurf -100) - another good option, and you can get it to render more by moving with the arrow keys. isosurf, where could I find it? Mesa demos directory, same place gears normally lives. see www.mesa3d.org. Keith I have had problems trying to compile the demos myself, so, I've extracted them from a binary package I've found. And now, the results: 1.-When the new bm_dma_test is called from the dma_init it fails as ever. Then, if I try to run the 'gears' demo, it hangs the machine. 2.-When the bm_dma_test is called from the dma_cleanout, the gears demo runs, showing only garbage on the screen. So, it seems that we should blame the DMA test for the locks. 3.-Finally, and in the same environment than (2), I've tried to run the isosurf demo. Against all the bets, it worked. Well, it's able to render the figures as good as in software mode (with the software GL library), but with some problems: - There's garbage in the background of the window. - The window is not cleaned for each frame, so, all the shapes are mixed on the screen after some key strokes. Now, we need somebody with knowledge about the internals to look for the reason of this behaviour. Perhaps something related with buffer swapping? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Progress of mesa-3.5 tree? Update to Mesa-3.6/4.0
El Sáb 15 Sep 2001 02:41, escribiste: On Friday 14 September 2001 21:08, you wrote: That's fine -- I wasn't suggesting that. But, for the people who can actually do this job, the r128/G400 isn't terribly interesting anymore. Isn't the whole open source thing about developers scratching an itch? Cool. It just came across differently, somehow... Dunno, guess it's due to the incidents of the week combined with nothing still on making the RagePRO go under DRI (I think I'm closer- there's some stuff that's being incorrectly set in the ati XFree86 driver, I've un-done that and now the bus-master seems to hang the box solid instead of do nothing at all... There's still something missing that's messing things up- I just can't finger it yet.). Frank, one more time, I would like to have your work to take a look on it. Perhaps with more eyes looking at the problem we could find something. And if you could release your changes we could test it in another machines and see different behaviours. I think that another good idea is to discuss about what have you find wrong in the ati driver, don't you think so? And talking about this thread itself, I think that the DRI development will be always behind the Windows drivers development. So, people buying state-of-art cards will never have a linux environment ready for their shining cards. A lot of things must change to make it possible. Perhaps Linux is not ready for games and will never be. But I think that Linux have not reached it's position for being the first supporting new hardware, but for showing a better stability and performance that MICROS~1 OS. This is the hope, in my opinion. The unstable drivers, hanging the machine, are the worst thing for Linux. If I bought a Rage128, and saw that the machine hanged every two hours, I would say: 'this is just the same shit than Windows', and I will have no reason to use linux. So, the only hope for the hardware enterprises to release linux drivers is people demanding it. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Questions about drm implemetation
Hello. I'm working in adapting the mach64 drm driver to the new template structure. I have a pair of questions: What is the meaning of the __HAVE_SG define? I've set it to zero in the mach64 driver, but I'm not sure about this supposition. In the mach64_dma.c , the following line: dev_priv-sarea = dev-maplist[0]; is now wrong, because the drm_device_t member maplist is now a drm_map_list_t* and in the mach64 trunk, it was a drm_map_t**. I'm trying to figure how to write it now, with the new type, but I'm not sure about it. Do we have to make dev_priv-sarea point to the head of the maplist? What is this supposed to be for? I've almost finished all the porting to the 4.1.0 trunk, but it have been a blind porting. I hope not to burn my laptop, because I'm still paying it. :( (If I dare to test this trunk). And finally, where is the evil register programming of the driver? Do I need to comment it? What should we need to do instead of this register programming. Could you please point me to some document of resource to know how to do it? Is the utah-glx driver implemented in this way, or could I use it as a reference? Excuse for my bad english and thanks for your time. Best regards. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DRI. Any progress?
El Lun 18 Jun 2001 22:46, escribiste: Jeremy W. Bean wrote: On Monday 18 June 2001 12:00, you wrote: I'm also starting to look at the code for the mach64. What do you mean with the new driver template code? Are you talking about the structure of the ATI driver in the mach64 branch? Any help will be appreciated. From what I can tell about the driver templates, and correct me if I am wrong anyone more experienced with the code. Check out for examples the r128 driver from the trunk, for a good example. Notice there are files in there such as r128_tritmp.h. This is a template that gets included in r128_tris.c. What it does basically is consolidate code that is largly reproduced over several functions, so that you set a few macros. For example: #define IND (R128_TWOSIDE_BIT) #define TAG(x) x##_twoside followed by #include r128_tritmp.h Notice the inline function's name defined in r128_tritmp.h is the result of the TAG macro, as well the function's content is dependant on what IND value is defined. So essentially the inline function is a template for various functions that have a bit in common. That way you consolidate common code and keep things consistent. The current mach64 branch is only using one template in the driver. But yes, it does have some of the driver template code there. Nice explanation. :) Look at e.g. programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128.h though. That's the template architecture at its beauty. Most of the code is shared between the drivers, customized with a few defines. Compare that to the duplication and inconsistency before. OK. I've understood the mechanism. I've merged the mach64 driver stuff into a copy of the 4.1.0 trunk. All is compiling but the drm driver, because these holy templates. Tomorrow, I'll try to finish the work. Thanks a lot for your explanations. Best regards. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 DRI. Any progress?
Hello. Once again I try to get any answer about Mach64 DRI development. Is there any work in progress? Is the development for the Mach64 dead? It's really sad, but I've been waiting for one year and no progress have been made or I haven't been told about it. Has anybody merged the main trunk into the mach64 branch? I know that the Mach64 is no state-of-art, but a lot of laptops are still wearing one of these cards. Is there any way to help in the development of this driver? I've never coded a driver and the huge XFree trunk afraids me, but, anyway, I should try to help if somebody could help me with the first steps: Where to find information about the chip? Where to find some templates or architectural information about DRI,... I think the DRI development group is making a good work. It's a pitty I can't see the results in my old graphic card. Best regards. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
