Re: [Dri-devel] mach64 drm and new PCI probing....
There are three pools of DMA memory, low (below 16MB?), normal, high (64b). If the kernel can't identify your hardware it returns a buffer from the low pool because it assumes it is an ISA device. With the new code the kernel can look at the PCI capabilities of the device and the device says its supports the normal pool. Could there be code in the driver assuming the low pool? This is just a guess. --- Dave Airlie [EMAIL PROTECTED] wrote: The new PCI probing code seems to break the mach64 driver, it looks like the pci_alloc_consistent is returning a different buffer when the driver uses the new probing scheme, this is messy to debug for me until I get another machine I can connect to my laptop to debug it... If i make the system fall back to the old system, it works okay.. symptoms are the DMA test fails and it falls back to pseudo-DMA.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
I finally got to look at this patch, the patch puts the options in atioption.c in a different order than in atioption.h this stops tv out from working properly with the previous patch, there is an updated patch at http://freedesktop.org/~airlied/mach64-tvout-070504.diff it still doesn't look great on my TV :-( NTSC or PAL, NTSC suffers from shorter scan lines at the top than at the bottom, PAL suffers from a dodgy shake .. makes your eyes hurt ... Dave. On Sun, 28 Mar 2004, Mike Mestnik wrote: He did respond you should be able to find his comments on the user list. IIRC He said that xv != tvout and that xv was in 0-0-7 and this seams to be the case. I think there is some dependant code missing from the tvout patch that also needs to be brought over. I used /linux/tvout-patches/mach64-tvout-20030328.diff.gz for making my patch. Maby the XV patch will have the missing code we need? --- Anish Mistry [EMAIL PROTECTED] wrote: On Saturday 27 March 2004 09:55 pm, you wrote: I'm glad too see it has worked for you. I have had problems with my patch, may I ask how you use it and what you do to make it work? What I did was use atitvout while in X and this worked but only if I didn't do any mode changes or VT switches. Withought the patch atitvout bails saying it can do VBE calles. I think you misread my message. I was NOT able to get it working. I don't use atitvout since there is only the source code available and not a binary which I would be able to run under the Linux ABI. I'm going to try to hand patch Leif's original 4.3 patch later this week to see if I can get it to work. Have you tried to email Leif I did last week, but got no response. --- Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry -- Anish Mistry ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build (solved)
Thanks fot your input. I have now built a new xserver and the drm kernel modules. glxgears runs at approx 160 fps for 1280x1024x16, with mmio and agp 2x. This seems a little slow, how much is speed improved by asynchronous or synchronous DMA? Which one is preferred? A note on the build process of the kernel modules. I had to do the following om my GNU/Debian unstable box to build the mach64.o: apt-get install kernel-source-2.4.25 (and unpack) ln -s /usr/src/kernel-source-2.4.25 /usr/src/linux (optional) cp /boot/config-2.4.25-1-686 /usr/src/linux/.config (stock kernel) cd /usr/src/linux make xconfig exit immediately = include/linux/version.h is created make dep cd /usr/CVS/dri-cvs/drm/linux make LINUXDIR=/usr/src/linux cd /usr/CVS/dri-cvs/drm/linux cp gamma.o i810.o i830.o mach64.o mga.o r128.o radeon.o savage.o sis.o tdfx.o via.o /lib/modules/2.4.25-1-686/kernel/drivers/char/drm/ depmod -a A much nicer approach would be to build the kernel modules with the aid of only the kernel-headers, not the kernel source, such as when building the alsa-modules, i2c-modules or the lm-sensors-modules. Using the kernel-headers one does not have to create the version.h file, it is already there. This requires a debian directory however, and more makefile support for the build than for a stock kernel. apt-get install kernel-headers-2.4.25-1-686 apt-get install i2c-source (and unpack) cd /usr/src/modules/i2c time fakeroot ./debian/rules KSRC=/usr/src/kernel-headers-2.4.25-1-686 KVERS=2.4.25-1-686 KDREV=2.4.25-1 kdist_image Thanks for your efforts. Hopefully, in due time, the security problem can be solved for the mach64 and savage drivers too :( On Tue, 2004-04-27 at 03:18, Alex Deucher wrote: --- Adam Jackson [EMAIL PROTECTED] wrote: On Monday 26 April 2004 17:59, Felix Khling wrote: The mach64 driver has moved to the trunk. Try building it there. The branch is broken for quite a while now. It won't be fixed. So it's been merged then? As in, I should go update the wiki so we don't get this complaint in the future? Already done. Alex - ajax __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Tue, 27 Apr 2004 01:12:27 +0100 (IST) Dave Airlie [EMAIL PROTECTED] wrote: cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa Besides that one bit it should build fine. /me pokes the mach64 maintainers. ISTR some discussion about merging mach64 anyway, even though it's insecure, perhaps with Big Fat Warning Signs or defaulting to mmio mode (which is secure, right?). Nope.. its not as far as I know, the buffers can still be accessed even if they are not used from the last time this stuff was discussed... it default to mmio at the moment anyways, maybe it and the savage should have some warning when the DRM module is loaded that the system is in-secure.. I think it's not the DRM module that causes the insecurity, at least in case of Savage. It's the Xserver that creates mmio mappings that would allow an attacker to do evil stuff. The problem with Savage is that everything is done in user space. So potentially any user process can do anything with the savage engine. Dave. Felix --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Tue, 27 Apr 2004 00:41:06 +0200 Svante Signell [EMAIL PROTECTED] wrote: Hello, I made a fresh checkout of the mach64-0-0-7 cvs branch together with the Mesa and drm modules according to the Building and ATIMach64 web pages. However the build fails. The tail of world.log is as follows: ... ln -s /usr/CVS/dri-cvs/Mesa/src/mesa/main/accum.h accum.h make[5]: *** No rule to make target `/usr/CVS/dri-cvs/Mesa/src/mesa/main/arbparse.c', needed by `arbparse.c'. Stop. make[5]: Leaving directory `/usr/CVS/dri-cvs/xc/xc/lib/GL/mesa/main' .. The mach64 driver has moved to the trunk. Try building it there. The branch is broken for quite a while now. It won't be fixed. Warnings in the world.log are: [snip] Regards, Felix --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Monday 26 April 2004 17:41, Svante Signell wrote: Hello, I made a fresh checkout of the mach64-0-0-7 cvs branch together with the Mesa and drm modules according to the Building and ATIMach64 web pages. However the build fails. The tail of world.log is as follows: ... mach64-0-0-7 needs a checkout of Mesa CVS from before that particular change occured: cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa Besides that one bit it should build fine. /me pokes the mach64 maintainers. ISTR some discussion about merging mach64 anyway, even though it's insecure, perhaps with Big Fat Warning Signs or defaulting to mmio mode (which is secure, right?). - ajax --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa Besides that one bit it should build fine. /me pokes the mach64 maintainers. ISTR some discussion about merging mach64 anyway, even though it's insecure, perhaps with Big Fat Warning Signs or defaulting to mmio mode (which is secure, right?). Nope.. its not as far as I know, the buffers can still be accessed even if they are not used from the last time this stuff was discussed... it default to mmio at the moment anyways, maybe it and the savage should have some warning when the DRM module is loaded that the system is in-secure.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Tue, Apr 27, 2004 at 12:41:06AM +0200, Svante Signell wrote: Hello, I made a fresh checkout of the mach64-0-0-7 cvs branch together with the Mesa and drm modules according to the Building and ATIMach64 web pages. However the build fails. The tail of world.log is as follows: If it wasn't moved to the main branch as a result of a discussion that went on some time ago and fixed there (not sure if the conclusion was carried out yet) you can revert the mesa tree to the version of march 1. Some time after that some changes were made to that tree that are required some changes to the dri tree. This solution worked for me (with the mach64-0-0-7 as of March 30). ... ln -s /usr/CVS/dri-cvs/Mesa/src/mesa/main/accum.h accum.h make[5]: *** No rule to make target `/usr/CVS/dri-cvs/Mesa/src/mesa/main/arbparse.c', needed by `arbparse.c'. Stop. make[5]: Leaving directory `/usr/CVS/dri-cvs/xc/xc/lib/GL/mesa/main' .. Warnings in the world.log are: Compiler is gcc (GCC) 3.3.3 (Debian 20040401) make[2]: Entering directory `/usr/CVS/dri-cvs/xc/xc/config/imake' gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../include -I../../exports/include/X11 -I../.. -I../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DCPP_PROGRAM=\cpp\ -DHAS_MERGE_CONSTANTS=`if gcc -m32 -fmerge-constants -xc /dev/null -S -o /dev/null 2 /dev/null 1 /dev/null; then echo 1; else echo 0; fi` -c -o imake.o imake.c imake.c:972: warning: string length `1094' is greater than the length `509' ISO C89 compilers are required to support ../config/cf/linux.cf:97: warning: InstallAppDefFiles is not defined (several entries) Imakefile:35: warning: BuildXIElib is not defined Imakefile:39: warning: BuildPexLib is not defined Imakefile:18: warning: KDriveXServer is not defined --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Monday 26 April 2004 17:59, Felix Kühling wrote: The mach64 driver has moved to the trunk. Try building it there. The branch is broken for quite a while now. It won't be fixed. So it's been merged then? As in, I should go update the wiki so we don't get this complaint in the future? - ajax --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
--- Adam Jackson [EMAIL PROTECTED] wrote: On Monday 26 April 2004 17:59, Felix Kühling wrote: The mach64 driver has moved to the trunk. Try building it there. The branch is broken for quite a while now. It won't be fixed. So it's been merged then? As in, I should go update the wiki so we don't get this complaint in the future? Already done. Alex - ajax __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build
On Monday 26 April 2004 20:18, Alex Deucher wrote: So it's been merged then? As in, I should go update the wiki so we don't get this complaint in the future? Already done. You're my hero. - ajax --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
On Saturday 27 March 2004 09:55 pm, you wrote: I'm glad too see it has worked for you. I have had problems with my patch, may I ask how you use it and what you do to make it work? What I did was use atitvout while in X and this worked but only if I didn't do any mode changes or VT switches. Withought the patch atitvout bails saying it can do VBE calles. I think you misread my message. I was NOT able to get it working. I don't use atitvout since there is only the source code available and not a binary which I would be able to run under the Linux ABI. I'm going to try to hand patch Leif's original 4.3 patch later this week to see if I can get it to work. Have you tried to email Leif I did last week, but got no response. --- Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry -- Anish Mistry pgp0.pgp Description: signature
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
He did respond you should be able to find his comments on the user list. IIRC He said that xv != tvout and that xv was in 0-0-7 and this seams to be the case. I think there is some dependant code missing from the tvout patch that also needs to be brought over. I used /linux/tvout-patches/mach64-tvout-20030328.diff.gz for making my patch. Maby the XV patch will have the missing code we need? --- Anish Mistry [EMAIL PROTECTED] wrote: On Saturday 27 March 2004 09:55 pm, you wrote: I'm glad too see it has worked for you. I have had problems with my patch, may I ask how you use it and what you do to make it work? What I did was use atitvout while in X and this worked but only if I didn't do any mode changes or VT switches. Withought the patch atitvout bails saying it can do VBE calles. I think you misread my message. I was NOT able to get it working. I don't use atitvout since there is only the source code available and not a binary which I would be able to run under the Linux ABI. I'm going to try to hand patch Leif's original 4.3 patch later this week to see if I can get it to work. Have you tried to email Leif I did last week, but got no response. --- Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry -- Anish Mistry ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
I'm glad too see it has worked for you. I have had problems with my patch, may I ask how you use it and what you do to make it work? What I did was use atitvout while in X and this worked but only if I didn't do any mode changes or VT switches. Withought the patch atitvout bails saying it can do VBE calles. --- Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry ATTACHMENT part 1.2 application/pgp-signature ATTACHMENT part 2 application/x-gzip name=dmesg.boot.gz ATTACHMENT part 3 application/x-gzip name=XF86Config.gz __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch and VBE TVOut. Patch included.
On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote: This is nothing more than a HUNK fixed copy of the TVOut patch found on leif's linux page. With this patch the TVOut and other related options are evaluated and it is posible to use atitvout while in X. However I notesed some problems with this patch that only a reboot would fix. There was coruption of 2d texture offsets making the FB filled with odd things from display memory. Something like the GDM login name prompt came in clearly while the rest of the screen was messed up. I'l see if I can't get some screenshots of this. I was unable to get tvout working with your attached patch. Using the 4.3 binaries from Leif's site works fine, but no dri. I'm using FreeBSD. -- Anish Mistry pgp0.pgp Description: signature dmesg.boot.gz Description: GNU Zip compressed data XF86Config.gz Description: GNU Zip compressed data
Re: [Dri-devel] mach64 dri on freebsd 5.2
Leif Delgass [EMAIL PROTECTED] writes: I forgot to bring in the drm_linux_list.h for bsd that was added on the mach64-0-0-6-branch. I just added it and it is included from drmP.h. With any luck that should fix the compile errors in the kernel module. ok, thank you again, that does fix the compile errors in the kernel module. I built the module, and loaded it: # kldstat | grep mach64 51 0xc4e88000 15000mach64.ko # ls -l /dev/dri/card0 crw-rw-rw- 1 root wheel 145, 0 Mar 8 08:08 /dev/dri/card0 I set my ld path to point to the new gl libs: # setenv LD_LIBRARY_PATH /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/:$LD_LIBRARY_PATH # ldd which glxinfo /usr/X11R6/bin/glxinfo: libGLU.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGLU.so.1 (0x28079000) libGL.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGL.so.1 (0x280f3000) libXext.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libXext.so.6 (0x2816f000) libX11.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libX11.so.6 (0x2817e000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28246000) libm.so.2 = /lib/libm.so.2 (0x2826a000) libc.so.5 = /lib/libc.so.5 (0x28283000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x2835d000) # glxinfo -display :1 name of display: :1.0 display: :1 screen: 0 direct rendering: Yes [rest of output snipped for clarity.] but glxgears only gets about 115.3 frames: # glxgears -display :1 [1] 6381 577 frames in 5.0 seconds = 115.400 FPS 576 frames in 5.0 seconds = 115.200 FPS 576 frames in 5.0 seconds = 115.200 FPS 577 frames in 5.0 seconds = 115.400 FPS which is the same as without dri. So gl thinks it has dri, but performance is no better. (note - the -display :1 is because I am running two Xservers. If I disable the 2nd Xserver, I still get only 115 frames, but I didn't have that output to paste.) (note2 - I am going to try building a few gl games - gltron and tuxracer - and see if they improve.) I looked at the log file, and here is the important output: XFree86 Version 4.3.99.12 (DRI mach64-0-0-7-branch) [snip] (II) LoadModule: glx (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libglx.a (II) Module glx: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: dri (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module drm (II) LoadModule: drm (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/freebsd/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: ati (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/drivers/ati_drv.o (II) Module ati: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 6.5.3 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 [snip] (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 detected. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active Device section card0. [snip] (II) ATI(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) ATI(0): [drm] DRM interface version 1.2 (II) ATI(0): [drm] created mach64 driver at busid pci::01:00.0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xc4f0d000 (II) ATI(0): [drm] mapped SAREA 0xc4f0d000 to 0x282d3000 (II) ATI(0): [drm] framebuffer handle = 0xfd00 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm]
Re: [Dri-devel] mach64 dri on freebsd 5.2
On 8 Mar 2004 [EMAIL PROTECTED] wrote: Leif Delgass [EMAIL PROTECTED] writes: I forgot to bring in the drm_linux_list.h for bsd that was added on the mach64-0-0-6-branch. I just added it and it is included from drmP.h. With any luck that should fix the compile errors in the kernel module. ok, thank you again, that does fix the compile errors in the kernel module. I built the module, and loaded it: # kldstat | grep mach64 51 0xc4e88000 15000mach64.ko # ls -l /dev/dri/card0 crw-rw-rw- 1 root wheel 145, 0 Mar 8 08:08 /dev/dri/card0 I set my ld path to point to the new gl libs: # setenv LD_LIBRARY_PATH /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/:$LD_LIBRARY_PATH # ldd which glxinfo /usr/X11R6/bin/glxinfo: libGLU.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGLU.so.1 (0x28079000) libGL.so.1 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGL.so.1 (0x280f3000) libXext.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libXext.so.6 (0x2816f000) libX11.so.6 = /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libX11.so.6 (0x2817e000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28246000) libm.so.2 = /lib/libm.so.2 (0x2826a000) libc.so.5 = /lib/libc.so.5 (0x28283000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x2835d000) # glxinfo -display :1 name of display: :1.0 display: :1 screen: 0 direct rendering: Yes [rest of output snipped for clarity.] but glxgears only gets about 115.3 frames: # glxgears -display :1 [1] 6381 577 frames in 5.0 seconds = 115.400 FPS 576 frames in 5.0 seconds = 115.200 FPS 576 frames in 5.0 seconds = 115.200 FPS 577 frames in 5.0 seconds = 115.400 FPS which is the same as without dri. So gl thinks it has dri, but performance is no better. Don't expect huge numbers from glxgears, you'll notice more improvement in apps using textures and more geometry than gears. (note - the -display :1 is because I am running two Xservers. If I disable the 2nd Xserver, I still get only 115 frames, but I didn't have that output to paste.) (note2 - I am going to try building a few gl games - gltron and tuxracer - and see if they improve.) You should see a significant difference in those. I looked at the log file, and here is the important output: XFree86 Version 4.3.99.12 (DRI mach64-0-0-7-branch) [snip] (II) LoadModule: glx (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libglx.a (II) Module glx: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: dri (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading sub module drm (II) LoadModule: drm (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/freebsd/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: ati (II) Loading /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/drivers/ati_drv.o (II) Module ati: vendor=The XFree86 Project compiled for 4.3.99.12, module version = 6.5.3 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 [snip] (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 detected. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active Device section card0. [snip] (II) ATI(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) ATI(0): [drm] DRM interface
Re: [Dri-devel] mach64 dri on freebsd 5.2
Leif Delgass [EMAIL PROTECTED] writes: [snip] but glxgears only gets about 115.3 frames: # glxgears -display :1 [1] 6381 577 frames in 5.0 seconds = 115.400 FPS 576 frames in 5.0 seconds = 115.200 FPS 576 frames in 5.0 seconds = 115.200 FPS 577 frames in 5.0 seconds = 115.400 FPS which is the same as without dri. So gl thinks it has dri, but performance is no better. Don't expect huge numbers from glxgears, you'll notice more improvement in apps using textures and more geometry than gears. [snip] (II) ATI(0): [drm] Will request pseudo-DMA (MMIO) mode ^ [snip rest of log] Everything in the log looks fine, but you are getting MMIO mode and not real DMA mode. You should use real DMA to get the best performance. Actually, I thought real DMA mode was the default, but you should be able to force it on with: Option DMAMode async in the Device section of XF86Config. thank you. I added this to my XF86Config, and now glxgears reports: 880 frames in 5.0 seconds = 176.000 FPS 878 frames in 5.0 seconds = 175.600 FPS 883 frames in 5.0 seconds = 176.600 FPS 880 frames in 5.0 seconds = 176.000 FPS 878 frames in 5.0 seconds = 175.600 FPS more than 50% better. However I ran into unexpected trouble building gltron and have been too busy/distracted to make it work it yet. If you know of a good open source opengl benchmark, I would be grateful to know about it. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dri on freebsd 5.2
On Sun, 7 Mar 2004, Dave Airlie wrote: What is the status of mach64 dri support on freebsd 5.2 ? nobody has tested it for a while, so I say it suffers from bitrot... mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should all be there, just needing some updates for FreeBSD 5.2, I'll look into it over the next while (need to sleep for a day or two :-) Dave. I just brought over the missing Makefiles and mach64_drv.c (with PCI ID list removed since it's in mach64.h now) for bsd from mach64-0-0-6-branch. I haven't tested the build, but I think I picked up all the necessary pieces. -- Leif Delgass http://www.retinalburn.net --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dri on freebsd 5.2
Leif Delgass [EMAIL PROTECTED] writes: On Sun, 7 Mar 2004, Dave Airlie wrote: What is the status of mach64 dri support on freebsd 5.2 ? nobody has tested it for a while, so I say it suffers from bitrot... mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should all be there, just needing some updates for FreeBSD 5.2, I'll look into it over the next while (need to sleep for a day or two :-) Dave. I just brought over the missing Makefiles and mach64_drv.c (with PCI ID list removed since it's in mach64.h now) for bsd from mach64-0-0-6-branch. I haven't tested the build, but I think I picked up all the necessary pieces. Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c : xf86glx.c: In function `__MESA_setVisualConfigs': xf86glx.c:481: error: `kernel8' undeclared (first use in this function) xf86glx.c:481: error: (Each undeclared identifier is reported only once xf86glx.c:481: error: for each function it appears in.) xf86glx.c:482: error: `DitherValues' undeclared (first use in this function) If I remove those two variables, the build continues past that point. I don't yet know if it completes because my laptop takes a long time to build X. thanks again. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dri on freebsd 5.2
Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c : xf86glx.c: In function `__MESA_setVisualConfigs': xf86glx.c:481: error: `kernel8' undeclared (first use in this function) xf86glx.c:481: error: (Each undeclared identifier is reported only once xf86glx.c:481: error: for each function it appears in.) xf86glx.c:482: error: `DitherValues' undeclared (first use in this function) If I remove those two variables, the build continues past that point. I don't yet know if it completes because my laptop takes a long time to build X. I've moved the fix over the from the trunk so it should work, it compies on Linux for me .. can't test it at work though.. Dave. thanks again. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 dri on freebsd 5.2
Thank you for your time and your replies.
Dave Airlie [EMAIL PROTECTED] writes:
Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c :
xf86glx.c: In function `__MESA_setVisualConfigs':
xf86glx.c:481: error: `kernel8' undeclared (first use in this function)
xf86glx.c:481: error: (Each undeclared identifier is reported only once
xf86glx.c:481: error: for each function it appears in.)
xf86glx.c:482: error: `DitherValues' undeclared (first use in this function)
If I remove those two variables, the build continues past that
point. I don't yet know if it completes because my laptop takes a long
time to build X.
I've moved the fix over the from the trunk so it should work, it compies
on Linux for me .. can't test it at work though..
With this change I was able to build an Xserver that works, and runs,
but still no hardware accleration, because I still have no drm
kernel module for freebsd. In /var/log/XFree86.0.log I see:
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: Open failed
[drm] failed to load kernel module mach64
(II) ATI(0): [drm] drmOpen failed
(EE) ATI(0): [dri] DRIScreenInit Failed
I tried uncommenting this line host.def:
/* #define BuildXF86DRM YES */
That makes the build die with:
echo #define DRM_LINUX 1 opt_drm.h
cc -O -pipe -mcpu=pentiumpro -I. -I.. -D_KERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@
-I@/../include -I/usr/include -finline-limit=15000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64/../mach64_dma.c
In file included from
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:38:
../mach64_drv.h:44: error: field `list' has incomplete type
../mach64_drv.h:74: error: field `free_list' has incomplete type
../mach64_drv.h:75: error: field `placeholders' has incomplete type
../mach64_drv.h:76: error: field `pending' has incomplete type
../mach64_drv.h: In function `mach64_find_pending_buf_entry':
../mach64_drv.h:812: warning: implicit declaration of function `list_entry'
../mach64_drv.h:812: error: syntax error before drm_mach64_freelist_t
../mach64_drv.h:817: error: dereferencing pointer to incomplete type
../mach64_drv.h:818: error: syntax error before drm_mach64_freelist_t
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c: In
function `mach64_dump_ring_info':
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:401:
warning: implicit declaration of function `list_for_each'
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:401:
error: syntax error before '{' token
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: `entry' undeclared (first use in this function)
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: (Each undeclared identifier is reported only once
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: for each function it appears in.)
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c: At
top level:
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:414:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:415:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:416:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:417:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:418:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:419:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:420:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:421:
error: syntax error before string constant
Re: [Dri-devel] mach64 dri on freebsd 5.2
I forgot to bring in the drm_linux_list.h for bsd that was added on
the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
With any luck that should fix the compile errors in the kernel module.
Leif
On 7 Mar 2004 [EMAIL PROTECTED] wrote:
Thank you for your time and your replies.
Dave Airlie [EMAIL PROTECTED] writes:
Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c :
xf86glx.c: In function `__MESA_setVisualConfigs':
xf86glx.c:481: error: `kernel8' undeclared (first use in this function)
xf86glx.c:481: error: (Each undeclared identifier is reported only once
xf86glx.c:481: error: for each function it appears in.)
xf86glx.c:482: error: `DitherValues' undeclared (first use in this function)
If I remove those two variables, the build continues past that
point. I don't yet know if it completes because my laptop takes a long
time to build X.
I've moved the fix over the from the trunk so it should work, it compies
on Linux for me .. can't test it at work though..
With this change I was able to build an Xserver that works, and runs,
but still no hardware accleration, because I still have no drm
kernel module for freebsd. In /var/log/XFree86.0.log I see:
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: open result is -1, (No such file or directory)
drmOpenDevice: Open failed
[drm] failed to load kernel module mach64
(II) ATI(0): [drm] drmOpen failed
(EE) ATI(0): [dri] DRIScreenInit Failed
I tried uncommenting this line host.def:
/* #define BuildXF86DRM YES */
That makes the build die with:
echo #define DRM_LINUX 1 opt_drm.h
cc -O -pipe -mcpu=pentiumpro -I. -I.. -D_KERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I.. -I.
-I@ -I@/../include -I/usr/include -finline-limit=15000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64/../mach64_dma.c
In file included from
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:38:
../mach64_drv.h:44: error: field `list' has incomplete type
../mach64_drv.h:74: error: field `free_list' has incomplete type
../mach64_drv.h:75: error: field `placeholders' has incomplete type
../mach64_drv.h:76: error: field `pending' has incomplete type
../mach64_drv.h: In function `mach64_find_pending_buf_entry':
../mach64_drv.h:812: warning: implicit declaration of function `list_entry'
../mach64_drv.h:812: error: syntax error before drm_mach64_freelist_t
../mach64_drv.h:817: error: dereferencing pointer to incomplete type
../mach64_drv.h:818: error: syntax error before drm_mach64_freelist_t
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c: In
function `mach64_dump_ring_info':
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:401:
warning: implicit declaration of function `list_for_each'
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:401:
error: syntax error before '{' token
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: `entry' undeclared (first use in this function)
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: (Each undeclared identifier is reported only once
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:404:
error: for each function it appears in.)
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c: At
top level:
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:414:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:415:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:416:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:417:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:418:
error: syntax error before string constant
builddir/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/mach64_dma.c:419:
error: syntax error
Re: [Dri-devel] mach64 dri on freebsd 5.2
What is the status of mach64 dri support on freebsd 5.2 ? nobody has tested it for a while, so I say it suffers from bitrot... mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should all be there, just needing some updates for FreeBSD 5.2, I'll look into it over the next while (need to sleep for a day or two :-) Dave. Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 on sparc64, any one try?
Mike Mestnik wrote: I have a UltraSparc5 with an onboard Rage3D, workes with the mach64 driver. There are some problems with the kernel and PCI domains, but I got thoes cleared out. There is still a problem that the chip is stuck in whaterver mode is set by openboot(the bios), but I can change the bit depth. Other than that and endianess and byte size issues is there any thing else that might not work? I oftan have to build programs with the sparc32 command, I hope that X will be no diffrent. Are any of the fallbacks 64bit accelerated? SPARC support has fallen a bit out of date. I don't think there are any rasterization optimizations (i.e., assembly code) for SPARC, and some of the TNL assembly code was disabled. You will need to build both the kernel and user parts for either 32-bit or 64-bit. Don't mix-and-match. There are known DRI issues if you do that. Other than that, I think you've already enumerated all of the obvious types of problems you may run into. :) Please report back any successes or failures you have. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 on sparc64, any one try?
On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote: [...] Other than that and endianess and byte size issues is there any thing else that might not work? FWIW, people have been running Mach64 DRI on PPC for a while (only with MMIO though, not DMA), so endianness shouldn't be a problem. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 on sparc64, any one try?
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote: [...] Other than that and endianess and byte size issues is there any thing else that might not work? FWIW, people have been running Mach64 DRI on PPC for a while (only with MMIO though, not DMA), so endianness shouldn't be a problem. I don't know what sparc has for DMA but it dose have PCI slots so it could have a PCIGART. The first problem is /Mesa-newtree/src/mesa/sparc/sparc.c sparc.c:32:21: context.h: No such file or directory sparc.c:33:26: math/m_xform.h: No such file or directory sparc.c:34:27: tnl/t_context.h: No such file or directory sparc.c:35:19: sparc.h: No such file or directory I'm betting some one changed this and just didn't update this file, so my question is what file 'did' they update? and what list should this go on? __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 on sparc64, any one try?
Mike Mestnik wrote: --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote: [...] Other than that and endianess and byte size issues is there any thing else that might not work? FWIW, people have been running Mach64 DRI on PPC for a while (only with MMIO though, not DMA), so endianness shouldn't be a problem. I don't know what sparc has for DMA but it dose have PCI slots so it could have a PCIGART. The first problem is /Mesa-newtree/src/mesa/sparc/sparc.c sparc.c:32:21: context.h: No such file or directory sparc.c:33:26: math/m_xform.h: No such file or directory sparc.c:34:27: tnl/t_context.h: No such file or directory sparc.c:35:19: sparc.h: No such file or directory I'm betting some one changed this and just didn't update this file, so my question is what file 'did' they update? and what list should this go on? Short answer: A lot. http://dri.sourceforge.net/cgi-bin/moin.cgi/Building --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 on sparc64, any one try?
Ok, so I'l build X at 64 bits as having a 32bit kmod would proble mean I'd need a 32bit kernel. I have stoped working on this cause I can't build the DRI tree. I have a working copy of Xfree86(provided by debian) so it must be posible to build xfree86. Could I get a list of all the files that I'd need to build mach64 in the XFree86 tree? At the bottom is a patch for xc/lib/GL/mesa/sparc/Imakefile, this fixes SOME of the problems with the way DRI builds the mesa source tree, if it dosen't get commited it will get lost. and eventualy I ran... cd xc/lib/GL for fil in $(find -name Imakefile); do echo ' ,s/#ifdef SparcArchitecture$/#ifdef SparcArchitecture \\ 0/ ,s/defined(SparcArchitecture)/defined(SparcArchitecture) \\ 0/ wq ' | ed $fil; done But this didn't stop the sparc ASM from getting built. The overall problem with it is the global registers need to defined in .register, this happens for just about every instruction. ../../../../lib/GL/mesa/sparc/xform.S: Assembler messages: ../../../../lib/GL/mesa/sparc/xform.S:25: Error: detected global register use not covered by .register pseudo-op ../../../../lib/GL/mesa/sparc/xform.S:28: Error: detected global register use not covered by .register pseudo-op ../../../../lib/GL/mesa/sparc/xform.S:28: Error: detected global register use not covered by .register pseudo-op ../../../../lib/GL/mesa/sparc/xform.S:28: Error: detected global register use not covered by .register pseudo-op ../../../../lib/GL/mesa/sparc/xform.S:30: Error: detected global register use not covered by .register pseudo-op ../../../../lib/GL/mesa/sparc/xform.S:30: Error: detected global register use not covered by .register pseudo-op --- Ian Romanick [EMAIL PROTECTED] wrote: Mike Mestnik wrote: I have a UltraSparc5 with an onboard Rage3D, workes with the mach64 driver. There are some problems with the kernel and PCI domains, but I got thoes cleared out. There is still a problem that the chip is stuck in whaterver mode is set by openboot(the bios), but I can change the bit depth. Other than that and endianess and byte size issues is there any thing else that might not work? I oftan have to build programs with the sparc32 command, I hope that X will be no diffrent. Are any of the fallbacks 64bit accelerated? SPARC support has fallen a bit out of date. I don't think there are any rasterization optimizations (i.e., assembly code) for SPARC, and some of the TNL assembly code was disabled. You will need to build both the kernel and user parts for either 32-bit or 64-bit. Don't mix-and-match. There are known DRI issues if you do that. Other than that, I think you've already enumerated all of the obvious types of problems you may run into. :) Please report back any successes or failures you have. --- Imakefile 9 Dec 2003 15:33:36 - 1.2 +++ Imakefile 17 Feb 2004 02:05:57 - @@ -1,4 +1,6 @@ -XCOMM $XFree86: xc/lib/GL/mesa/src/SPARC/Imakefile,v 1.3 2002/11/22 22:55:58 tsi Exp $ +XCOMM $XFree86: xc/lib/GL/mesa/src/sparc/Imakefile,v 1.8 2002/11/25 12:58:55 tsi Exp $ + +#include Threads.tmpl /* * Need both shared and unshared Mesa objects in the following cases: @@ -25,33 +27,42 @@ #endif +#define MesaSparcBuildDir /**/ +#define NeedToLinkMesaSrc +#include Imakefile.inc + + #if Malloc0ReturnsNull ALLOC_DEFINES = -DMALLOC_0_RETURNS_NULL #endif -#define MesaSPARCBuildDir /**/ -#define NeedToLinkMesaSrc -#include Imakefile.inc +#if BuildXF86DRI + DRI_DEFINES = GlxDefines + DRI_INCLUDES = -I../../../dri -I../../../glx -I../../dri -I../../../include \ + -I$(INCLUDESRC)/GL -I$(XF86OSSRC) -I$(SERVERSRC)/GL/dri +#endif - DEFINES = $(ALLOC_DEFINES) GlxDefines $(MESA_ASM_DEFINES) - INCLUDES = -I$(INCLUDESRC) -I$(EXTINCSRC) -I$(MESASRCDIR)/src \ - -I$(MESASRCDIR)/src/SPARC \ - -I../../../include +MESA_INCLUDES = -I$(MESASRCDIR)/src/mesa \ + -I$(MESASRCDIR)/src/mesa/main \ + -I$(MESASRCDIR)/src/mesa/array_cache \ + -I$(MESASRCDIR)/src/mesa/math \ + -I$(MESASRCDIR)/src/mesa/glapi \ + -I$(MESASRCDIR)/src/mesa/swrast \ + -I$(MESASRCDIR)/src/mesa/$(ASM_DIR) \ + -I$(MESASRCDIR)/include \ + -I../../../include -I$(XINCLUDESRC) + DEFINES = $(ALLOC_DEFINES) $(DRI_DEFINES) $(ASM_DEFS) $(MATHDEF) + INCLUDES = $(MESA_INCLUDES) $(DRI_INCLUDES) SRCS = $(MESA_ASM_SRCS) OBJS = $(MESA_ASM_OBJS) + #include Library.tmpl LibraryObjectRule() -STD_CPP_DEFINES = StandardDefines $(PROJECT_DEFINES) - SubdirLibraryRule($(OBJS)) NormalLintTarget($(SRCS)) -ObjectFromAsmSource(xform, NullParameter) -ObjectFromAsmSource(clip, NullParameter) -ObjectFromAsmSource(norm, NullParameter) - DependTarget() __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
As for the glxgears thing, I got some output from it when I ran it with gdb from an ssh session: glxgears: vblank.c:338: driWaitForVBlank: Assertion `interval != (unsigned)-1' failed. try updating from CVS both trees, I fixed this I just can't remember which tree it went into :-) I think it was the Mesa one, I'll take a look at the DMA failure case later on .. when I'm more with awake On a side note, what kind of stuff should I put in my host.def to build a nice static debuging server? I googled for this and found a few things, but they I change the XF86Drivers line to just ati, the DriDrivers line to just mach64, define GlxBuiltInMach64 to YES and comment out DoLoadableServer line and I think that works.. I've also used the gdb mentioned in the Wiki I think to debug the normal server ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
-X starts up fine now, window manager comes up, etc. -xvinfo reports xv working, playing mpeg with mplayer confirms this. -glxinfo reports correct info -glxgears locks up. Rest of X is locked, but mouse can be moved around. I can ssh in, but can't seem to kill the X server. A reboot is required to get the screen working again. wierd is their anything in dmesg? send me a copy of it .. I've just had a game of tuxracer and it works great for me .. I've also started two glxgears side by side ... and exited them.. does gears lock up after you try to exit it or straight away? if it is on exit, I'd re-build the tree and confirm yuou have the latest 2d driver as that is what was happening me before about 8 hours ago.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
Yeah, got a couple things here. First, the dmesg. the dma test is failing. It worked fine on the old branch. This of course happens when starting X. Here's a dmesg clip: -- agpgart: Putting AGP V2 device at :00:00.0 into 2x mode agpgart: Putting AGP V2 device at :01:00.0 into 2x mode [drm] descriptor ring: cpu addr 0xcc878000, bus addr: 0xe000 [drm] mach64_do_wait_for_idle failed! GUI_STAT=0x0081 [drm] [drm] ring contents: [drm] head_addr: 0x head: 0 tail: 0 [drm] 0xe000: 0x007ffe48 0x06134000 0xcff8 0x (head) (tail) [drm] 0xe010: 0x 0x 0x 0x [drm] 0xe020: 0x 0x 0x 0x [drm] 0xe030: 0x 0x 0x 0x [drm] ... [drm] 0xe0003fd0: 0x 0x 0x 0x [drm] 0xe0003fe0: 0x 0x 0x 0x [drm] 0xe0003ff0: 0x 0x 0x 0x [drm] [drm] [drm]BM_GUI_TABLE = 0xe000 [drm] [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 [drm] BM_SYSTEM_MEM_ADDR = 0xe000 [drm] BM_COMMAND = 0x [drm] [drm] BM_STATUS = 0x834860ca [drm]BUS_CNTL = 0x7b33a111 [drm] FIFO_STAT = 0x [drm]GUI_STAT = 0x0081 [drm]SRC_CNTL = 0x0f00 [drm] mach64_do_wait_for_idle failed (result=-16) [drm] [drm]AGP_BASE = 0xe000 [drm]AGP_CNTL = 0x0002003e [drm] ALPHA_TST_CNTL = 0x0470 [drm] [drm] BM_COMMAND = 0x [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 [drm]BM_GUI_TABLE = 0xe000 [drm] BM_STATUS = 0x834860ca [drm] BM_SYSTEM_MEM_ADDR = 0xe000 [drm] BM_SYSTEM_TABLE = 0x4cb8 [drm]BUS_CNTL = 0x7b33a111 [drm] [drm] CLR_CMP_CLR = 0x [drm]CLR_CMP_CNTL = 0x [drm] CONFIG_CHIP_ID = 0xdc004c42 [drm] CONFIG_CNTL = 0x3f46 [drm]CONFIG_STAT0 = 0x00a10095 [drm]CONFIG_STAT1 = 0x [drm]CONFIG_STAT2 = 0x0200 [drm] CRC_SIG = 0x [drm] CUSTOM_MACRO_CNTL = 0x003c0171 [drm] [drm] DP_BKGD_CLR = 0x [drm] DP_FRGD_CLR = 0x [drm] DP_MIX = 0x00070003 [drm]DP_PIX_WIDTH = 0x01000404 [drm] DP_SRC = 0x0100 [drm] DP_WRITE_MASK = 0x [drm] DSP_CONFIG = 0x00370a09 [drm] DSP_ON_OFF = 0x0158072e [drm]DST_CNTL = 0x0023 [drm] DST_OFF_PITCH = 0x1900 [drm] [drm]EXT_MEM_CNTL = 0x64000c01 [drm] [drm] FIFO_STAT = 0x [drm] [drm] GEN_TEST_CNTL = 0x0100 [drm]GUI_CMDFIFO_DATA = 0x017c020b [drm] GUI_CMDFIFO_DEBUG = 0x00248026 [drm]GUI_CNTL = 0x0001 [drm]GUI_STAT = 0x0081 [drm] GUI_TRAJ_CNTL = 0x0023 [drm] [drm] HOST_CNTL = 0x [drm]HW_DEBUG = 0x48803800 [drm] [drm] MEM_ADDR_CONFIG = 0x0101 [drm]MEM_BUF_CNTL = 0x00382848 [drm] [drm]PAT_REG0 = 0x [drm]PAT_REG1 = 0x [drm] [drm] SC_LEFT = 0x [drm]SC_RIGHT = 0x031f [drm] SC_TOP = 0x [drm] SC_BOTTOM = 0x0a3c [drm] [drm] SCALE_3D_CNTL = 0x [drm]SCRATCH_REG0 = 0x04100400 [drm]SCRATCH_REG1 = 0x [drm] SETUP_CNTL = 0x3100 [drm]SRC_CNTL = 0x0f00 [drm] [drm]TEX_CNTL = 0x [drm] TEX_SIZE_PITCH = 0x [drm]TIMER_CONFIG = 0x [drm] [drm] Z_CNTL = 0x0110 [drm] Z_OFF_PITCH = 0x19062a20 [drm] [drm] resetting engine ... [drm] freeing data buffer memory. [drm] DMA test failed (ret=-16), using pseudo-DMA mode --- As for the glxgears thing, I got some output from it when I ran it with gdb from an ssh session: glxgears: vblank.c:338: driWaitForVBlank: Assertion `interval != (unsigned)-1' failed. I got some patchy backtrace action too: (gdb) bt #0 0x4021e031 in kill () from /lib/libc.so.6 #1 0x4018b49e in pthread_kill () from /lib/libpthread.so.0 #2 0x0006 in ?? () #3 0xb668 in ?? () #4 0x4018b454 in pthread_kill () from /lib/libpthread.so.0 #5 0x40009a00 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #6 0x080515d8 in ?? () #7 0xb688 in ?? () #8 0x4018b7a3 in raise () from /lib/libpthread.so.0 #9 0x4021de1c in raise () from /lib/libc.so.6 #10 0x4021f2a7 in abort () from /lib/libc.so.6 #11 0x4021777e in __assert_fail () from /lib/libc.so.6 #12 0x4044d34a in driWaitForVBlank (priv=0x8050cd8, vbl_seq=0x40192e40, flags=4294967295, missed_deadline=0xb86b ) at vblank.c:338 #13 0x40451d2a in mach64CopyBuffer (dPriv=0x8050cd8) at mach64_ioctl.c:309 #14 0x40453887 in mach64SwapBuffers (dPriv=0x8050cd8) at mach64_screen.c:285 #15 0x4034f4a3 in driSwapBuffers
Re: [Dri-devel] mach64 and new tree
Dave Airlie wrote: So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if I have a DRM that allows it I can access it from userspace process without DRI or XFree86... XF86Config should only be modifiable by root, so if root decides to be insecure, that's root's business. BTW, if you're working with vertices, you should definitely be using the new t_vertex.c code (see the i830 driver) if at all possible. It can be extended to cover some more scenarios if necessary -- perhaps we need to allow driver extensions to that code. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
On Fri, Feb 13, 2004 at 01:31:59AM +, Dave Airlie wrote: So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if The thing with normal DMA in Mach64 is that the DMA buffers can have not only geometry, textures, but also bus mastering commands which almost give access of the system full physical memory to the client. But the current DRM has a pseudo-DMA mode which from the client POV works just like the normal DMS, except that is syncronous. That pseudo-DMA mode was original written as a debugging aiding tool to help transition for the full DMA. It sends the commands to the card one by one using MMIO. If we add a simple sanity/security check to the mach64_do_dispatch_pseudo_dma() in mach64_dma.c then client no longer can issue naughty commands. I have a DRM that allows it I can access it from userspace process without DRI or XFree86... That's not correct. Many DRM IOCTLs can only be used by root (such as the one to enable/disable DMA). [...] And Jose if you have any work done on the DRM interface change in any state or any ideas, could you drop it somewhere so I can start looking at it maybe.. I don't care if it does anything I'm more trying to get the ideas you were proposing than a working DRM ... I'm afraid I have many ideas but not work in the same proportion... There is a newdrm-0-0-1-branch which has some of the necessary infrastuture (especially the DMA pool mangament code is complete). Unfortunately at the time I got carried away and also tried to make the DRM common code in a true library (replacing DRM_* macros by functions like a mania) and eventually didn't finish either task. I'll see if I have any uncommited code in my hard-drive and generate the doxygen documentation for you this weekend. But to avoid past mistakes I strongly advise you to take this slowly, with one little step at a time. Having Mach64 on the trunk seems a step big enough, without any prejudice to your goals. Jose Fonseca --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
When I updated and using the XFree86 from the snapshot directory, I was missing an I2C symbol, the ati driver in DRI CVS seems to need a newer version of libi2c.a, mine was from Fedora Core 1... The 2d driver builds now but 3d seems to crap it out .. it'll be a day or two until I figure it out .. I might need to get a serial console together.. (or a network).. Okay the 2D driver is now in a lot better state and should work fine ... the libi2c.a issue is still there I think.. Dave. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
On Thu, 12 Feb 2004, Dave Airlie wrote: Okay the last few fixes make tuxracer and glxgears work again, so the new branch should be as useable as the old one, I think there are still a few cleanups in the native vertex code (using macros for a few things), and then a texmem converison might be in order. But it's good enough for me to get on with some real work on my laptop :-) Dave. Hello, It's great that you are picking this up. It's been on my todo list for a long while but free time is nonexistant for me these days (full time grad student + half time research assistant = - half time DRI developer?!) I actually have a near complete texmem conversion that's been gathering dust for a while. I'll try to clean it up and send a patch in the next few days. -- Leif Delgass http://www.retinalburn.net --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
It's great that you are picking this up. It's been on my todo list for a long while but free time is nonexistant for me these days (full time grad student + half time research assistant = - half time DRI developer?!) well a few things came together, I got specs at work for the rage pro that I found we had thought about using in a previous product, and I wanted a couple of things in the later DRI to work on my laptop, (and Aussie TV turns to worse muck during the summer :-) I actually have a near complete texmem conversion that's been gathering dust for a while. I'll try to clean it up and send a patch in the next few days. if you can't no worries, texmem conversion for i810 was the first conversion I did.. :-), I'll have to leave it alone for a few days and see if anyone can find any issues with it .. (I just checked in another load of fixes for specular and color that I had wrong ...), I'm gonna dig around at work and see if I can get a PCI or AGP M64 card, there might be one in a corner somewhere :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
On Thu, 12 Feb 2004 10:17:11 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote: While I'm at it (see driinterface-0-0-3-branch mails) I could update the snapshot scripts to build mach64-0-0-7-branch snapshots. please do it, I'm sure a bit more testing would help a lot ... Done. I put a first snapshot built in my home dir into dri.freedesktop.org/~felix/snapshots if you want to test it. Then let's see if the automatic update of the build scripts from CVS works. The next nightly mach64 snapshot should be from the new branch. Thanks, Dave. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
On Thu, 12 Feb 2004 06:42:29 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote: Okay the last few fixes make tuxracer and glxgears work again, so the new branch should be as useable as the old one, I think there are still a few cleanups in the native vertex code (using macros for a few things), and then a texmem converison might be in order. But it's good enough for me to get on with some real work on my laptop :-) While I'm at it (see driinterface-0-0-3-branch mails) I could update the snapshot scripts to build mach64-0-0-7-branch snapshots. Dave. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
While I'm at it (see driinterface-0-0-3-branch mails) I could update the snapshot scripts to build mach64-0-0-7-branch snapshots. please do it, I'm sure a bit more testing would help a lot ... Thanks, Dave. Dave. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7-branch status
On Thu, 12 Feb 2004 14:01:01 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Thu, 12 Feb 2004 10:17:11 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote: While I'm at it (see driinterface-0-0-3-branch mails) I could update the snapshot scripts to build mach64-0-0-7-branch snapshots. please do it, I'm sure a bit more testing would help a lot ... Done. I put a first snapshot built in my home dir into dri.freedesktop.org/~felix/snapshots if you want to test it. Then let's see if the automatic update of the build scripts from CVS works. The next nightly mach64 snapshot should be from the new branch. Of course the automatic update did not work. :-/ I ran a manual cvs update now. So tomorrow's snapshot should finally be from the new branch. Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
If it's OK to sacrifice some speed in order to make the mach64 driver secure and elegible to go the the trubk then there is quite a simple solution: disable DMA by default (using the MMIO pseudo-DMA). Users still have the option to force DMA in XF86Config if they so wish. I think this would make most people happy, as users no longer had to download snapshots, and for the developers it would be easier too as no further HEAD merges would be necessary. The mach64 will only be secure with a redesign of the DRM DMA engine. Without it there will always be a tradeoff between speed to get security. Jose Fonseca On Mon, Feb 09, 2004 at 11:59:37AM -0800, James Jones wrote: Dave, I was the one that brought this up. I have a little time (a few hours a week only) to work on it, and since no one else seemed to care I was going to tackle this very slowly. I was going to work on the DRM insecurities once I dug up the old conversations with Jose detailing what needed to be done. I know he had a whole new dma system in the works that was supposed to be flexible enough to solve these problems. I was hoping to come up with a simpler fix to get things working just good enough for mach64 to be considered secure. I assumed it could then be included in the main branches (wherever they may be now) where it would be easier to keep up to date at least. I'm glad others are still interested and its good to hear that progress is already being made. -James --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
So should we just work on getting everything running on newtree then and not worry about the security issues for now? -James - Original Message - From: Keith Whitwell [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Cc: James Jones [EMAIL PROTECTED]; [EMAIL PROTECTED]; Dave Airlie [EMAIL PROTECTED] Sent: Thursday, February 12, 2004 10:53 AM Subject: Re: [Dri-devel] mach64 and new tree José Fonseca wrote: If it's OK to sacrifice some speed in order to make the mach64 driver secure and elegible to go the the trubk then there is quite a simple solution: disable DMA by default (using the MMIO pseudo-DMA). Users still have the option to force DMA in XF86Config if they so wish. I think this would make most people happy, as users no longer had to download snapshots, and for the developers it would be easier too as no further HEAD merges would be necessary. This seems like a good way forward. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if I have a DRM that allows it I can access it from userspace process without DRI or XFree86... I think the branch now works as well as the older branch the last couple of commits I did last night fixed up the issues with specular/fog stuff that I messed up a bit.. we are now using packed vertices, So texmem changes, and a bit more testing, my issue is I can't keep both trees built on my laptop :-), so I'm hoping I don't need to change the old tree for debugging to track down anything I break!!.. And Jose if you have any work done on the DRM interface change in any state or any ideas, could you drop it somewhere so I can start looking at it maybe.. I don't care if it does anything I'm more trying to get the ideas you were proposing than a working DRM ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
Dave, I was the one that brought this up. I have a little time (a few hours a week only) to work on it, and since no one else seemed to care I was going to tackle this very slowly. I was going to work on the DRM insecurities once I dug up the old conversations with Jose detailing what needed to be done. I know he had a whole new dma system in the works that was supposed to be flexible enough to solve these problems. I was hoping to come up with a simpler fix to get things working just good enough for mach64 to be considered secure. I assumed it could then be included in the main branches (wherever they may be now) where it would be easier to keep up to date at least. I'm glad others are still interested and its good to hear that progress is already being made. -James Dave Airlie wrote: I noticed it came up during the IRC meeting this week about moving the mach64 up to the top of tree, So how should this be done in terms of CVS, the mach64 driver as is insecure, so I'd rather not put into an official tree until those issues are sorted out, I know Jose has some ideas on these and I'll see if I can track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) Dave. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
Dave Airlie wrote: track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. I think it should be fine to go in at Mesa head. Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. I think it should be fine to go in at Mesa head. Okay what about the DRI tree bits? DRM and changes to ATI driver?, should I go with mach64-0-0-7 or should I just make sure the ati bits work and not add mach64 to the host.def (I can see that messing up the snapshots a bit though), or maybe I just add a big huge warning to the DRM module and the X startup stating the mach64 DRM is inherently insecure and shouldn't be used on multi-user systems? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
On Sun, 2003-12-07 at 18:43, Jos Fonseca wrote: On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote: It turns out that I mis-configured lilo and when I rebooted a kernel with the software suspend patch was being booted rather then a clean one as I had thought (and I *knew* that swsusp causes problems with video cards). When I booted with a clean kernel, mach64 drm worked fine (and I got 270fps with glxgears rather then the ususal 110fps :)). [...] Nonetheless, I've included the debug output, the agpgart source with the software suspend patch added as well as without it and the software suspend patch itself for both the list archives in case anyone else runs into this problem. Also, I know that 2.6.0+ uses software suspend, so the debugging information below may help when it comes time for a 2.6 port. Thanks for the info. I don't know whose's fault is that sw suspend doesn't work with mach64 dri (it could be sw suspend patch, mach64 drm, or the agpgart). I know that radeon driver has suspend/resume support, but I think it's for hardware suspend. No, it's also for software suspend (Charl wrote it to be able to use that), but it only has an effect for a suspend/resume cycle while the server is running; it's weird that the mere fact that the kernel is patched for software suspend should have an effect on DRI initialisation. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Chris, On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote: Hello Jose, It's very strange that this doesn't work. If you compile the driver and the Xserver into /usr/X11R6-DRI/ and use that XFree86 server there shouln't be any binary incompatabilities problems (which I suspect are the cause of all this). When you mentioned this and the fact that you as well as I had no idea what was going on, I decided to re-compile everything (kernel, XFree86) cleanly without any vendor or personal patches. It turns out that I made a grave mistake in the information I provided and I sincerely apologize. It turns out that I mis-configured lilo and when I rebooted a kernel with the software suspend patch was being booted rather then a clean one as I had thought (and I *knew* that swsusp causes problems with video cards). When I booted with a clean kernel, mach64 drm worked fine (and I got 270fps with glxgears rather then the ususal 110fps :)). Again, please accept my apology for my mistake and I thank you for your patience. I learned while working in telecommunications that one must make sure that all their stuff is good before contacting the other end -- I failed in that regard this time. I am at your disposal if you ever need any experimental mach64 testing or help in general. No need to appologise! I know you did your best to provide all the useful details and that's what matters. Also, will this experience it will be easier to detect similar cases in the future. Nonetheless, I've included the debug output, the agpgart source with the software suspend patch added as well as without it and the software suspend patch itself for both the list archives in case anyone else runs into this problem. Also, I know that 2.6.0+ uses software suspend, so the debugging information below may help when it comes time for a 2.6 port. Thanks for the info. I don't know whose's fault is that sw suspend doesn't work with mach64 dri (it could be sw suspend patch, mach64 drm, or the agpgart). I know that radeon driver has suspend/resume support, but I think it's for hardware suspend. Since I'm quite busy ATM I'm inclined to just wait and see how things go from here. [...] Regards, Jose Fonseca --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Fwd: Re: [Dri-devel] mach64-0-0-6-branch dri bug report]
I'm copying the list sans attachments in case someone else runs into the same problem as I (for the archives) -- it turns out that the bug was just my own stupidity. -Forwarded Message- From: Christopher Gleba [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Date: Thu, 04 Dec 2003 17:02:17 -0500 Hello Jose, It's very strange that this doesn't work. If you compile the driver and the Xserver into /usr/X11R6-DRI/ and use that XFree86 server there shouln't be any binary incompatabilities problems (which I suspect are the cause of all this). When you mentioned this and the fact that you as well as I had no idea what was going on, I decided to re-compile everything (kernel, XFree86) cleanly without any vendor or personal patches. It turns out that I made a grave mistake in the information I provided and I sincerely apologize. It turns out that I mis-configured lilo and when I rebooted a kernel with the software suspend patch was being booted rather then a clean one as I had thought (and I *knew* that swsusp causes problems with video cards). When I booted with a clean kernel, mach64 drm worked fine (and I got 270fps with glxgears rather then the ususal 110fps :)). Again, please accept my apology for my mistake and I thank you for your patience. I learned while working in telecommunications that one must make sure that all their stuff is good before contacting the other end -- I failed in that regard this time. I am at your disposal if you ever need any experimental mach64 testing or help in general. Nonetheless, I've included the debug output, the agpgart source with the software suspend patch added as well as without it and the software suspend patch itself for both the list archives in case anyone else runs into this problem. Also, I know that 2.6.0+ uses software suspend, so the debugging information below may help when it comes time for a 2.6 port. I'm not sure what's the casual relationship between these. If the mach64_dma_init() ioctl wasn't sucessful at least once, the [drm] Initialized mach64 1.0.0 20020904 on minor 0 line would never appear in the log... By which order they appear on the kernel log? Please post the complete extract of the log which concerns the XFree initialization. As shown below it seems that the drm module is being initialized and then the errors come afterward -- that is, with the software suspend patch. Also, before loading XFree86, manually load the agpgart module and the mach64 with the debug option: insmod agpgart insmod mach64 drm_opts=debug Output is below: Kernel messages: kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Debug messages ON kernel: [drm:drm_count_cards] kernel: [drm:drm_count_cards] numdevs = 1 kernel: [drm:mach64_stub_register] kernel: [drm:mach64_stub_register] calling inter_module_register kernel: [drm:mach64_ctxbitmap_next] drm_ctxbitmap_next bit : 0 kernel: [drm:mach64_ctxbitmap_init] drm_ctxbitmap_init : 0 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_flush] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_release] open_count = 1 kernel: [drm:mach64_release] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_fasync] fd = -1, device = 0xe200 kernel: [drm:mach64_takedown] kernel: [drm:mach64_do_cleanup_dma] mach64_do_cleanup_dma kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr= 0x00, dev 0xe200, auth=1 kernel: [drm:mach64_flush] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_release] open_count = 1 kernel: [drm:mach64_release] pid = 15561, device = 0xe200 , open_count = 1 kernel: [drm:mach64_fasync] fd = -1, device = 0xe200 kernel: [drm:mach64_takedown] kernel: [drm:mach64_do_cleanup_dma] mach64_do_cleanup_dma kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0086401, nr= 0x01, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0086401, nr= 0x01, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0x40086410, nr= 0x10, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0186415, nr= 0x15, dev
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Christopher, On Tue, Dec 02, 2003 at 02:57:50PM -0500, Christopher Gleba wrote: Hello Jose, Thank you for the response. Do you have a PCI card? If not make sure the agpgart kernel module is loaded before the mach64 module, by adding pre-install mach64 modprobe -k agpgart Yes, it is an AGP card: [...] and I had made sure that the agpgart module was loaded (that's why I thought this problem was so odd): lsmod: Module Size Used byNot tainted mach64 85368 0 agpgart18896 0 (unused) kernel messages: kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 kernel: [drm] Module unloaded kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 This is _very_ odd. The agpgart appears to be loaded OK before the mach64 module, but it's not used found by the later! (II) ATI(0): [drm] register handle = 0xf410 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xf4100400 (WW) ATI(0): Not enough memory for local textures, disabling DRI And you should decrease the screen depth (16bpp is a must if you care for 3D performance). Oddly, it is already at 16bpp: XF86Config: Section Screen Identifier screen1 Device device1 Monitor monitor1 DefaultColorDepth 16 Subsection Display Depth 16 Virtual 1280 1024 EndSubsection EndSection Well, 1280*1024*2*3=7864320 which is quite close to the 8*1024*1024=8388608 you have on the chip. Since is the AGP memory is not available, you do not have enough memory on the chip for two 256x256*16bit textures... So the issue is the AGP... . XFree86.0.log: (II) Setting vga for screen 0. (==) ATI(0): Chipset: ati. (**) ATI(0): Depth 16, (--) framebuffer bpp 16 xdpyinfo: screen #0: dimensions:1280x1024 pixels (361x292 millimeters) resolution:90x89 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba at 0x40016000 Did a lsmod, agpgart and mach64 are loaded. Looked at kernel logs and found: kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0 Well, this is suerly a consequence of above, but these calls shouldn't be happening consedering DRM was disabled That's another thing that I thought was so odd and why I posted to the list. My intuition (I am not an X developer) is that DRI is being disabled as a result of the above errors? I'm not sure what's the casual relationship between these. If the mach64_dma_init() ioctl wasn't sucessful at least once, the [drm] Initialized mach64 1.0.0 20020904 on minor 0 line would never appear in the log... By which order they appear on the kernel log? Please post the complete extract of the log which concerns the XFree initialization. Also, before loading XFree86, manually load the agpgart module and the mach64 with the debug option: insmod agpgart insmod mach64 drm_opts=debug I hope that this bug report helps and thank the dri development people for their hard work. See if the above tips help. Let us know otherwise. No dice so far. As mentioned before, the mach64-0-0-5-branch on XFree86 4.2.0 used to work beautifully. I've attached the XFree86.0.log from XFree86-4.3-23mdk with mach64-20031128-linux applied. Unfortunately differences between mach64-0-0-5-branch and mach64-0-0-6-branch are precisly the former being for XFree86 4.2.0 and the later for 4.3.0. Otherwise we could try to checkout mach64-0-0-6-branch in diffrent times and determine which change caused this. If there is any particular testing that I can do let me know -- if need be I can download and compile the mach64-0-0-6-branch CVS branch again and give that a shot. It's very strange that this doesn't work. If you compile the driver and the Xserver into
admin note RE: [Dri-devel] mach64-0-0-6-branch dri bug report
just a few words for the future, nothing serious... -Original Message- From: Christopher Gleba [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 23:02 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Size: 220 kB i am pretty sure that an e-mail of that size might be qualified to get handled as a bugzilla bug report. at least only the folks that want the full set of attachments have to download them if they do want them. -Alex. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Christopher, On Mon, Dec 01, 2003 at 12:46:55AM -0500, Christopher Gleba wrote: Hello, I had been using the mach64-0-0-5-branch in linux for a while but recently I upgraded my install and thus gave a shot at the mach64-0-0-6-branch and encountered a problem. This report is broken into sections: 1 - Problem description 2 - System information 3 - XF86Config-4 --- 1) Problem Description: I first tried the mach64-20031128-linux.i386.tar.bz2 daily snapshot with XFree86-4.3-23mdk. Kernel modules built fine and insmod'ed. DRI was not working; the relevant section on XFree86.0.log reads: (II) ATI(0): [drm] created mach64 driver at busid PCI:1:0:0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xd0ba (II) ATI(0): [drm] mapped SAREA 0xd0ba to 0x40016000 (II) ATI(0): [drm] framebuffer handle = 0xf500 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm] Will request asynchronous DMA mode (WW) ATI(0): [agp] AGP not available (WW) ATI(0): [agp] AGP failed to initialize -- falling back to PCI mode. (WW) ATI(0): [agp] Make sure you have the agpgart kernel module loaded. Do you have a PCI card? If not make sure the agpgart kernel module is loaded before the mach64 module, by adding pre-install mach64 modprobe -k agpgart to your /etc/modules.conf (II) ATI(0): [drm] register handle = 0xf410 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xf4100400 (WW) ATI(0): Not enough memory for local textures, disabling DRI And you should decrease the screen depth (16bpp is a must if you care for 3D performance). (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba at 0x40016000 Did a lsmod, agpgart and mach64 are loaded. Looked at kernel logs and found: kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0 Well, this is suerly a consequence of above, but these calls shouldn't be happening consedering DRM was disabled So I figured that a patch that Mandrake put on X may have been causing the problem -- so I downloaded the mach64-0-0-6-branch from CVS yesterday and re-built a clean XFree86 -- same problem. I hope that this bug report helps and thank the dri development people for their hard work. See if the above tips help. Let us know otherwise. Jose Fonseca --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Hello Jose, Thank you for the response. Do you have a PCI card? If not make sure the agpgart kernel module is loaded before the mach64 module, by adding pre-install mach64 modprobe -k agpgart Yes, it is an AGP card: lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 0011 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at f500 (32-bit, non-prefetchable) [size=16M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at f410 (32-bit, non-prefetchable) [size=4K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- and I had made sure that the agpgart module was loaded (that's why I thought this problem was so odd): lsmod: Module Size Used byNot tainted mach64 85368 0 agpgart18896 0 (unused) kernel messages: kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 kernel: [drm] Module unloaded kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 (II) ATI(0): [drm] register handle = 0xf410 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xf4100400 (WW) ATI(0): Not enough memory for local textures, disabling DRI And you should decrease the screen depth (16bpp is a must if you care for 3D performance). Oddly, it is already at 16bpp: XF86Config: Section Screen Identifier screen1 Device device1 Monitor monitor1 DefaultColorDepth 16 Subsection Display Depth 16 Virtual 1280 1024 EndSubsection EndSection XFree86.0.log: (II) Setting vga for screen 0. (==) ATI(0): Chipset: ati. (**) ATI(0): Depth 16, (--) framebuffer bpp 16 xdpyinfo: screen #0: dimensions:1280x1024 pixels (361x292 millimeters) resolution:90x89 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba at 0x40016000 Did a lsmod, agpgart and mach64 are loaded. Looked at kernel logs and found: kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0 Well, this is suerly a consequence of above, but these calls shouldn't be happening consedering DRM was disabled That's another thing that I thought was so odd and why I posted to the list. My intuition (I am not an X developer) is that DRI is being disabled as a result of the above errors? I hope that this bug report helps and thank the dri development people for their hard work. See if the above tips help. Let us know otherwise. No dice so far. As mentioned before, the mach64-0-0-5-branch on XFree86 4.2.0 used to work beautifully. I've attached the XFree86.0.log from XFree86-4.3-23mdk with mach64-20031128-linux applied. If there is any particular testing that I can do let me know -- if need be I can download and compile the mach64-0-0-6-branch CVS branch again and give that a shot. Also this system does not have any important information on it so I can set up ssh root access if that would help in testing at all. If that would help, let me know and give me a few days to prepare the setup. -- -- Chris
[Fwd: Re: [Dri-devel] mach64-0-0-6-branch dri bug report]
Forgot the attachment in the last post. -Forwarded Message- From: Christopher Gleba [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Date: Tue, 02 Dec 2003 14:57:50 -0500 Hello Jose, Thank you for the response. Do you have a PCI card? If not make sure the agpgart kernel module is loaded before the mach64 module, by adding pre-install mach64 modprobe -k agpgart Yes, it is an AGP card: lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 0011 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at f500 (32-bit, non-prefetchable) [size=16M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at f410 (32-bit, non-prefetchable) [size=4K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- and I had made sure that the agpgart module was loaded (that's why I thought this problem was so odd): lsmod: Module Size Used byNot tainted mach64 85368 0 agpgart18896 0 (unused) kernel messages: kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 kernel: [drm] Module unloaded kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann kernel: agpgart: Maximum main memory to use for agp memory: 203M kernel: agpgart: Detected Intel 440BX chipset kernel: agpgart: AGP aperture is 64M @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 (II) ATI(0): [drm] register handle = 0xf410 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xf4100400 (WW) ATI(0): Not enough memory for local textures, disabling DRI And you should decrease the screen depth (16bpp is a must if you care for 3D performance). Oddly, it is already at 16bpp: XF86Config: Section Screen Identifier screen1 Device device1 Monitor monitor1 DefaultColorDepth 16 Subsection Display Depth 16 Virtual 1280 1024 EndSubsection EndSection XFree86.0.log: (II) Setting vga for screen 0. (==) ATI(0): Chipset: ati. (**) ATI(0): Depth 16, (--) framebuffer bpp 16 xdpyinfo: screen #0: dimensions:1280x1024 pixels (361x292 millimeters) resolution:90x89 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba at 0x40016000 Did a lsmod, agpgart and mach64 are loaded. Looked at kernel logs and found: kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0 kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0 Well, this is suerly a consequence of above, but these calls shouldn't be happening consedering DRM was disabled That's another thing that I thought was so odd and why I posted to the list. My intuition (I am not an X developer) is that DRI is being disabled as a result of the above errors? I hope that this bug report helps and thank the dri development people for their hard work. See if the above tips help. Let us know otherwise. No dice so far. As mentioned before, the mach64-0-0-5-branch on XFree86 4.2.0 used to work beautifully. I've attached the XFree86.0.log from XFree86-4.3-23mdk with mach64-20031128-linux applied. If there is any particular testing that I can do let me know -- if need be I can download and compile the mach64-0-0-6-branch CVS branch again and give
Re: [Dri-devel] mach64 DRI problems
José Fonseca writes: On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote: * The hang always occurs within a mach64_dma_dispatch_vertex call for primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears. glxgears only uses quads primitives, so the primitive is not relevant here. Hmmm, I am _definitely_ observing calls to mach64_dma_dispatch_vertex with prim = 8 while running glxgears. And it is the one that seems to cause the trouble. * I can get it to hang in mmio mode running glxgears if I make mach64_dispatch_pseudo_dma() just wait for space in the FIFO (or even for the FIFO to be empty) rather than waiting for the engine to be idle every 16 words. Was this using direct MMIO or HOST_TO_DATA? MMIO. Can anyone give me any pointers about how to get this chip going properly? From what you describe here I see three explanations: - there is some kind of caching corrupting the data from/to the hardware, which is specific to some of the PPC architectures That would not explain how I can get the chip to hang when I am feeding it with MMIO. - the driver is emitting bad 3D data - this is IMHO unlike since some other people have no problems with PPC and I also think this is unlikely, given that it works fine in MMIO mode (as long as I use the normal code which waits for the engine to be idle every 16 words). - your hardware is buggy - I had problems in the past with an AGP controller, but AFAIK the AGP isn't used in PPC, so I don't know what could be in fault. Later powerbooks (PPC laptops) have AGP, but not this one. I have AGP on my titanium G4 powerbook, which has a Rage 128 chip, for instance. This chip (3D Rage LT Pro, code 'LI') does have some bugs; for instance, 2D diagonal lines sometimes get drawn incorrectly (most noticeable with xpilot). So it is quite possible that there is a hardware bug. Paul. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 DRI problems
On Sat, 31 May 2003, Paul Mackerras wrote: José Fonseca writes: On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote: * The hang always occurs within a mach64_dma_dispatch_vertex call for primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears. glxgears only uses quads primitives, so the primitive is not relevant here. Hmmm, I am _definitely_ observing calls to mach64_dma_dispatch_vertex with prim = 8 while running glxgears. And it is the one that seems to cause the trouble. You're talking about sync/async DMA mode here, right? Have you tried some of the other Mesa demos? It would be useful to see what other apps do or don't cause a lockup, if it is always in dispatching vertex buffers, and if the type of primitive is the same or not. I'm inclined to agree with Jose that the primitive type shouldn't matter, but it's worth looking into. * I can get it to hang in mmio mode running glxgears if I make mach64_dispatch_pseudo_dma() just wait for space in the FIFO (or even for the FIFO to be empty) rather than waiting for the engine to be idle every 16 words. Was this using direct MMIO or HOST_TO_DATA? MMIO. Here's some more info on HOSTDATA: In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the GUI master target register (rather than BM_ADDR), we feed the blit data to the card through the HOST_DATA[0-15] registers, so it's still MMIO. The thing we have to be careful of is that you can't wait for idle between writes that set up the blit and the writes of the blit data to the HOST_DATA registers, or else the engine will lock up. That's what the no_idle_wait flag is for in the pseudo-DMA dispatch code. The docs say that full FIFO discliple must be maintined when writing to the HOST_DATA registers, which means checking for enough FIFO entries. The registers are sequential, so you can do an assembly optimized memcpy of 16 32-bit words at a time, checking the fifo between copies. When doing DMA to BM_HOSTDATA, the assumption is that the engine takes care of FIFO discipline (BM_HOSTDATA isn't really documented well). At any rate, this doesn't apply to gears since it doesn't use textures. Can anyone give me any pointers about how to get this chip going properly? From what you describe here I see three explanations: - there is some kind of caching corrupting the data from/to the hardware, which is specific to some of the PPC architectures That would not explain how I can get the chip to hang when I am feeding it with MMIO. - the driver is emitting bad 3D data - this is IMHO unlike since some other people have no problems with PPC and I also think this is unlikely, given that it works fine in MMIO mode (as long as I use the normal code which waits for the engine to be idle every 16 words). - your hardware is buggy - I had problems in the past with an AGP controller, but AFAIK the AGP isn't used in PPC, so I don't know what could be in fault. Later powerbooks (PPC laptops) have AGP, but not this one. I have AGP on my titanium G4 powerbook, which has a Rage 128 chip, for instance. This chip (3D Rage LT Pro, code 'LI') does have some bugs; for instance, 2D diagonal lines sometimes get drawn incorrectly (most noticeable with xpilot). So it is quite possible that there is a hardware bug. This is the same chip I have (also rev. dc) on x86, but mine is AGP. The lockups you are describing sound identical to previous reports on PPC, iirc. MMIO works, but sync and async DMA cause lockups. Also, we originally tried waiting for 16 FIFO entries instead of waiting for idle in the pseudo-DMA path. It works for me on x86, but it caused lockups for ppc users. For DMA, the condition where the FIFO is empty, but GUI_ACTIVE is set in GUI_STAT is a symptom of an engine lock-up, which could be caused by a number of things. I've definitely seen that state many times before, so I don't think it necessarily indicates a hardware bug. I remember other reports on ppc where the engine would lock in this state at the last descriptor in the ring. You should be able to get a (partial) dump of the ring contents by loading the kernel module with drm_opts=debug. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 DRI problems
On Sat, 31 May 2003, Leif Delgass wrote: Here's some more info on HOSTDATA: In MMIO/pseudo-DMA mode, when we see a descriptor with BM_HOSTDATA as the GUI master target register (rather than BM_ADDR), we feed the blit data to the card through the HOST_DATA[0-15] registers, so it's still MMIO. The thing we have to be careful of is that you can't wait for idle between writes that set up the blit and the writes of the blit data to the HOST_DATA registers, or else the engine will lock up. That's what the no_idle_wait flag is for in the pseudo-DMA dispatch code. The docs say that full FIFO discliple must be maintined when writing to the HOST_DATA ^ discipline, that is. I need more coffee. ;) registers, which means checking for enough FIFO entries. The registers are sequential, so you can do an assembly optimized memcpy of 16 32-bit words at a time, checking the fifo between copies. When doing DMA to BM_HOSTDATA, the assumption is that the engine takes care of FIFO discipline (BM_HOSTDATA isn't really documented well). At any rate, this doesn't apply to gears since it doesn't use textures. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 binary packages do not work with kernel 2.5.66
On Tue, 25 Mar 2003, Michael Thaler wrote: Hello, I just compiled and installed the latest linux developer kernel. I tried to install the Mach64 binary drivers from www.retinalburn.com. With kernel 2.4.20 it works fine for me, but with kernel 2.5.66 I get the following error message: :/usr/local/src/dripkg# modprobe mach64 FATAL: Error inserting mach64 (/lib/modules/2.5.66/kernel/drivers/char/drm/mach64.o): Invalid module format Is it possible to get the Mach64 driver working with ther developer kernels? Will it help to coompile the mach64 branch? Greetings, Michael Right now I'm not sure if the DRM drivers in DRI cvs will work unmodified when built against 2.5.x (assuming they actually build). Linus and others have been maintaining DRM drivers in the 2.5.x kernel tree based on the DRI trunk, but of course mach64 is not part of the DRI trunk yet, so it's not in the kernel sources yet. If you want to use 2.5.x with the mach64 driver, you may need to do some merging/modification of the DRM code from the mach64 branch (I'm not planning to install a development kernel on my test system). Make sure you've updated all the utilities required to run the 2.5.x kernels (e.g. modutils) and rebuilt the mach64.o module for the current kernel you're running. If you're not comfortable hacking on the code yourself, I'd suggest sticking with a 2.4.x kernel to use the DRI driver until the new stable kernel series (2.6/3.0?) is opened. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. I've been working on this locally a little, but haven't tackled the pci_alloc_consistent in a proper manner yet (the corresponding interface for us is bus_dma, which I am just beginning to understand while working on ati_pcigart.h/drm_scatter.h conversion). If you would approve of me moving the mach64 files to shared/drm/kernel, I could at least work on things incrementally (much of this stuff is mechanical changes), and then hopefully provide something pretty to review for pci_alloc_consistent. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
On 15 Feb 2003, Eric Anholt wrote: On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. I've been working on this locally a little, but haven't tackled the pci_alloc_consistent in a proper manner yet (the corresponding interface for us is bus_dma, which I am just beginning to understand while working on ati_pcigart.h/drm_scatter.h conversion). If you would approve of me moving the mach64 files to shared/drm/kernel, I could at least work on things incrementally (much of this stuff is mechanical changes), and then hopefully provide something pretty to review for pci_alloc_consistent. As long as the Linux build still works, that's fine by me. If you want to create the makefile links, move it to shared, and work on macro-izing the ioctls and whatnot, go for it. I was going to do this eventually, but if you're eager to get started, that's great. Of course, this will all have to happen in the mach64-0-0-6-branch for now, until we get the DRM interface/security changes done. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Seems to work for me as long as I don't try to use my Radeon at the same time. I have my setup as follows: HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI enabled DOES NOT WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI disabled DRI enabled DOES WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 AGP (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI disabled NOT TESTED HEAD 0 On-board RageXL (initialised by BIOS) DRI enabled DOES WORK I can not have the Radeon initialised by the BIOS since the the RageXL can not then be initialised later. I do have a problem with Radeon with subsequent X server starts. It can not access the V_BIOS and tries to use extremely bogus values. Unless someone here knows how to fix this I will send a mail to XFree86-devel. Attached is the output for the Dual-head DRI failure case. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (DRI mach64-0-0-6-branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.5.59-test i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Fri Feb 14 16:40:16 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard1_0 (**) |--Screen Screen1 (1) (**) | |--Monitor Monitor1 (**) | |--Device Videocard0 (**) |--Input Device DevInputMice (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout gb (**) XKB: layout: gb (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/Speedo,/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/msttcorefonts,/usr/X11R6/lib/X11/fonts/OTF,/usr/share/fonts/default/Type1,/usr/lib/openoffice/share/fonts/truetype,/usr/share/fonts/ja/TrueType (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.2, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project
Re: [Dri-devel] mach64-0-0-6-branch
[...] Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Could anyone tell me if I'll find recent GATOS stuff merged into the current XFree86-4.3 pre-releases ? I did not find the answer neither on the GATOS pages nor in the XFree86 CVS 'changes.html' document. I _did_ expect XFree86-4.3 to be 'up to date' with GATOS and would like to see some sort of proof - _before_ downloading tons of source code, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver on Compaq Armada M300
On Mit, 2003-02-05 at 17:50, Albert Cohen wrote: (II) ATI(0): [drm] drmSetBusid failed (7, PCI:0:5:0), Permission denied (EE) ATI(0): [dri] DRIScreenInit Failed This has been discussed several times here: you need to make sure the DRM is built with the same compiler as the kernel. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Tue, Feb 04, 2003 at 09:51:30PM -0500, Leif Delgass wrote: On Wed, 5 Feb 2003, Arkadi Shishlov wrote: What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. Now I think it is texture alpha. Quite pointless to have RGBA texture without ability to use it alpha channel. http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg It is GL_MODULATE, no lighting, GL_RGBA texture, glBlend(alpha, one_minus_alpha). Looking at screenshot the first that come in mind - mach64 doesn't do linear filtering for magnification. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Thu, 6 Feb 2003 00:44:12 +0200 Arkadi Shishlov [EMAIL PROTECTED] wrote: Now I think it is texture alpha. Quite pointless to have RGBA texture without ability to use it alpha channel. http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg Hows Quakeforge comming, btw - it'd be nice to play it on my Radeon 9000. fun game. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 5 Feb 2003, Arkadi Shishlov wrote: On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
No they aren't supported in DRI. For existing apps, they would probably Thanks for these very good explanation. My ergo: no use. So, it seems Mach64 does not have any good usable compression technique. Cheers, -- Sergey signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Mach64 / Rage128 texture compression update
According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. Sorry for my ignorance, are these compression methods supported in any way by DRI now? Which apps would benefit of them? Regards, -- Sergey signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Mach64 / Rage128 texture compression update
On 2 Feb 2003, Sergey V. Oudaltsov wrote: According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. Sorry for my ignorance, are these compression methods supported in any way by DRI now? Which apps would benefit of them? No they aren't supported in DRI. For existing apps, they would probably only be useful for apps supplying uncompressed textures and requesting generic compression through ARB_texture_compression. The textures would have to be compressed in software and then passed to the card to de-compress as it applies the textures. There is no GL extension (vendor-specific or otherwise) that I know of for these formats, so it would require a new extension spec. and a software implementation of compression/de-compression as well as the support for hardware de-compression (that's the easy part). Since there's no existing extension, there wouldn't be any existing apps supplying pre-compressed textures to the GL in this format, and afaik, very few existing apps would ask for generic compressed formats either. This limits the utility of implementing it, as VQ compression is much more time consuming than S3TC/DXTC compression, as I understand it. It's better for offline compression and real-time de-compression (de-compression could be faster than with S3TC). So it would require detailed specs on the compression format as implemented in the hardware (e.g. block and codebook sizes) to write the spec. and software support, or some trial and error reverse engineering. Quite frankly, it seems like it's probably more trouble than it's worth. Does anyone know if these formats were ever supported in ATI's drivers? I'm assuming it would have to have been in the DX drivers, since I can't find any GL extension supporting them. But I can't find any reference to DX supporting VQ except for the WinCE DirectX SDK for the Sega Dreamcast. I think Microsoft made DX 5 and 6.1 sdks for the dreamcast, and DXTC/S3TC was introduced in the PC version of DX6. According to ATI's site, later Rage 128 chips (Rage Fury Pro, Rage Mobility) support DX6 texture compression, which I assume means S3TC, but I don't see any relevant register defines in the headers and I don't have specs for Rage 128. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 / Rage128 texture compression update
According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think. On Fri, 31 Jan 2003, Ian Romanick wrote: While I was searching around the net for papers on texture memory management, I came across some references to Talisman and DirectX 6.0 texture compression. It seems that the compression algorithm used is called TREC, which is short for Texture and Rendering Compression. http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm Apparently, it is some sort of DCT based compression scheme. That would explain why ATI is the only company to ever implement it in hardware. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 29 Jan 2003, Arkadi Shishlov wrote: Hi. I'm working on QuakeForge engine, and some things related to transparency (player damage blood) and 'dynamic lighting' (grenade explosion) are very slow. Quake3 runs faster in mean time. Quake3 has some hacks built in to work around the mach64's limitations. I think it looks for Rage Pro in the Renderer string to enable them. I want to investigate problem further on Quake side, but I want to be sure I understood mach64 limitation correctly from what I've read at http://www.retinalburn.net/linux/dri_status.html - glEnable(GL_FOG) and glEnable(GL_BLEND) cannot be enabled at the same time. Correct. Enabling fog when blending is enabled will have no effect (there's no software fallback). Enabling blending when fog is enabled will disable fog. So fog should not cause any slowdowns as a result of falling back to software. - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not done as a fallback since it's very common. Hardware accelerated: environment texture base format GL_DECAL any valid format - GL_RGB, GL_RGBA GL_REPLACEGL_LUMINANCE, GL_RGB, GL_RGBA GL_MODULATE GL_LUMINANCE, GL_RGB, GL_RGBA(not fully compliant) Software fallbacks: -- environment texture base format GL_BLEND any GL_REPLACEGL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY GL_MODULATE GL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY And of course anything more recent than these core environments isn't supported, e.g ADD, COMBINE, etc. cvs co -r mach64-0-0-5-branch xc/xc/lib/GL/mesa/src/drv/mach64 are the right files to investigate for additional limitations? Yes. Look at mach64UpdateTextureEnv in mach64_texstate.c for the above and mach64_state.c for fog, blending and other state. BTW, when particular operation is implemented in software but require some on-screen content, driver copy already rendered chunk from framebuffer, pass it to Mesa, then copy back? To be honest, I don't know the gory details of the Mesa software rasterizer yet, but any primitives needing a texture application that can't be done in hardware would be completely software rendered and written to the framebuffer, I think. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
Sorry for continuing this thread but I think there are some open issues: 1. There is a memory leak (or something similar) in the mach64 driver since consecutive calls to the Xv driver fails . (With a call to a GL application in between) 2. Does the lack of feedback indicate that the issue is closed (i.e. bug free or not interesting or resolved)? (I know the funding is non-existing for mach64 , I really appreciate the efforts from Leif D. 3. There is some texmem stuff going on in the main path, is this affecting the mach65-0.0.5 branch? This mail is specifically addressed to Leif D. who has been _very_ responsive (and interested) so far :-) Maybe I should buy a new graphics card, such as Radeon 9000 (or an Nvidia one, god forgive) instead of bothering with old cards?? (even if they work properly) Svante Svante Signell writes: Leif Delgass writes: On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... At startup of the X server: (II) ATI(0): Largest offscreen area available: 1280 x 2252 (II) ATI(0): Will use 511 kB of offscreen memory for XAA (II) ATI(0): Will use back buffer at offset 0x2ff800 (II) ATI(0): Will use depth buffer at offset 0x57f800 Later in the log file: (II) ATI(0): Largest offscreen area available: 1280 x 2252 ... You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Only one client remains after exiting from the xsceensaver demo. cat /proc/dri/0/clients a dev piduid magic ioctls y 0 1904 0 06292494 BTW: I'm running gnome and sawfish. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 2a) Exit the atlantis demo, with xscreensaver running in the background. 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
Leif Delgass writes: On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... At startup of the X server: (II) ATI(0): Largest offscreen area available: 1280 x 2252 (II) ATI(0): Will use 511 kB of offscreen memory for XAA (II) ATI(0): Will use back buffer at offset 0x2ff800 (II) ATI(0): Will use depth buffer at offset 0x57f800 Later in the log file: (II) ATI(0): Largest offscreen area available: 1280 x 2252 appear again at the end of the X log. Also when that happens, the XVideo memory (in use for the current frame) is freed. If the remaining offscreen memory after the DRI allocations (511 kB in this case) is not enough for subsequent video frame allocations, then you'll see the BadAlloc, which would cause mplayer to crash. Since the driver uses double-buffering for XVideo by default, this is _not_ enough for DVD and I'm pretty sure it's not enough for the video size you had the problem with in your first email (though I'd have to check the calculations for that video format). So if you have both a GL app and an XVideo app running at the same time, the XVideo app's allocations will fail unless the video size is fairly small. This is not very graceful, but it's expected with the current code and doesn't indicate a memory leak. However, if you run mplayer, exit mplayer, run a GL app, exit the GL app, and then run mplayer again, you shouldn't have a problem. If that's what's really happening, that's a bug. Yes, this is what I did. I did exit from the atlantis demo but still with xscreensaven running in the background. Also, stopping the xscreensaver daemon does not change anything. In addition, after failure to allocate off-screen memory I can still view small size video applications in mplayer but not large size ones. So the concusion would be that it's a bug, either in the mach64 driver or somewhere else, eg. xscreensaver? You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Only one client remains after exiting from the xsceensaver demo. cat /proc/dri/0/clients a dev piduid magic ioctls y 0 1904 0 06292494 BTW: I'm running gnome2 and sawfish. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 2a) Exit the atlantis demo, with xscreensaver running in the background. 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) In the sequence above, do you close the atlantis demo between step 2 and 3? I can reproduce this if I leave atlantis open and then start an xvideo app (I tested with xine), or if I leave xine running and then start atlantis. This is the scenario I described above. But if atlantis/xscreensaver is not running after step 2 (check /proc/dri/0/clients to make sure), then #3 shouldn't fail. See above. At any rate, the upshot is that you won't be able to have 3D accel and XVideo past a certain video size at the same time with 1280x1024 (with the current shared buffer scheme for DRI). Even if we can make the failure more graceful, we'll either have to revert to software GL or reduce the maximum XvImage size (though we could probably make it so any running apps would continue to work as expected). I don't expect to have them active at the same time, running them one at a time is OK for me. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: Leif Delgass writes: Have you tried a lower resolution? Not yet. Try restarting X with 1024x768@16bpp for a while and see if you still have the same problem. I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Offscreen memory refers to the on-card memory left over after the framebuffer allocation(s). When there are no GL contexts, the framebuffer memory is equal to display width x display height x bytes per pixel (2 for 16-bit). With GL contexts running, there is an additional back buffer (same size as the 2D front framebuffer) plus a depth buffer which is width x height x 2 (depth buffer is always 16-bit). The remaining offscreen memory is used for XAA and XVideo buffers. You can get a BadAlloc when there is not enough offscreen memory left. Doing the calculations one gets: 8Meg - 3x(1280x1024)= 8388608 - 7864320 = 524288 bytes = 512 kbytes which is close to what the log file reports: (II) ATI(0): Will use 511 kB of offscreen memory for XAA It seems that the 3D driver already has allocated the frame buffer, back buffer and depth buffer memory at startup, right. Obviously the remaining 512k of memory is sufficient for the XV driver when no 3D applications has been activated. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... appear again at the end of the X log. Also when that happens, the XVideo memory (in use for the current frame) is freed. If the remaining offscreen memory after the DRI allocations (511 kB in this case) is not enough for subsequent video frame allocations, then you'll see the BadAlloc, which would cause mplayer to crash. Since the driver uses double-buffering for XVideo by default, this is _not_ enough for DVD and I'm pretty sure it's not enough for the video size you had the problem with in your first email (though I'd have to check the calculations for that video format). So if you have both a GL app and an XVideo app running at the same time, the XVideo app's allocations will fail unless the video size is fairly small. This is not very graceful, but it's expected with the current code and doesn't indicate a memory leak. However, if you run mplayer, exit mplayer, run a GL app, exit the GL app, and then run mplayer again, you shouldn't have a problem. If that's what's really happening, that's a bug. You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) Running the xscreensaver demo again works, no problem. Conclusion: Memory available for XAA and XV before running the 3D application is not returned when the application exits!! Maybe this in not possible to do for this card without leaving X and reentering, but it is _very_ annoying. I don't really like to run the desktop at 1024x768. I will robably use another X display for 3D applications or for viewing movie clips. The best alternative though, would be if you can find a solution in the
Re: [Dri-devel] Mach64 resource problems
Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: Leif Delgass writes: Have you tried a lower resolution? Not yet. Try restarting X with 1024x768@16bpp for a while and see if you still have the same problem. I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Offscreen memory refers to the on-card memory left over after the framebuffer allocation(s). When there are no GL contexts, the framebuffer memory is equal to display width x display height x bytes per pixel (2 for 16-bit). With GL contexts running, there is an additional back buffer (same size as the 2D front framebuffer) plus a depth buffer which is width x height x 2 (depth buffer is always 16-bit). The remaining offscreen memory is used for XAA and XVideo buffers. You can get a BadAlloc when there is not enough offscreen memory left. Doing the calculations one gets: 8Meg - 3x(1280x1024)= 8388608 - 7864320 = 524288 bytes = 512 kbytes which is close to what the log file reports: (II) ATI(0): Will use 511 kB of offscreen memory for XAA It seems that the 3D driver already has allocated the frame buffer, back buffer and depth buffer memory at startup, right. Obviously the remaining 512k of memory is sufficient for the XV driver when no 3D applications has been activated. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) Running the xscreensaver demo again works, no problem. Conclusion: Memory available for XAA and XV before running the 3D application is not returned when the application exits!! Maybe this in not possible to do for this card without leaving X and reentering, but it is _very_ annoying. I don't really like to run the desktop at 1024x768. I will robably use another X display for 3D applications or for viewing movie clips. The best alternative though, would be if you can find a solution in the mach64 driver. Thanks for your help, Svante The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? Attached please find the XFree86.0.log at 1280x1024 and a diff to when the screen size is 1024x768 XFree86.0.log.1280x1024 Description: Binary data XFree86.0.log.diff Description: Binary data
Re: [Dri-devel] Mach64 resource problems
Leif Delgass writes: Have you tried a lower resolution? Not yet. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? Do you mean the XFree86.0.log or an strace log? See also below. --Leif Can you please describe how memory (both card and main memory) is allocated and released for 2D and 3D applications: What puzzles me is that if I start with a fresh X everything is OK, but after the problem occurs I have to exit X to be able to run the application again. It is not sufficient to terminate the application to get back to the same state as as when starting anew. Possible causes of the resource shortage can be: 1. The applications do not return memory when exiting. 2. X cannot reclaim the memory when the appications exit. 3. There is a memory leak somewhere. 4. Something else?? Thanks, Svante Selected parts of XFree86.0.log and strace mplayer -vo sdl file.avi below. XFree86.0.log (II) LoadModule: vbe (II) Reloading /usr/X11R6/lib/modules/libvbe.a (II) ATI(0): VESA BIOS detected (II) ATI(0): VESA VBE Version 2.0 (II) ATI(0): VESA VBE Total Mem: 8192 kB (II) ATI(0): VESA VBE OEM: ATI MACH64 (II) ATI(0): VESA VBE OEM Software Rev: 1.0 (II) ATI(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) ATI(0): VESA VBE OEM Product: MACH64LP (II) ATI(0): VESA VBE OEM Product Rev: 01.00 (II) ATI(0): VESA VBE DDC supported (II) ATI(0): VESA VBE DDC Level 2 (II) ATI(0): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(0): VESA VBE DDC read successfully (II) ATI(0): Manufacturer: NOK Model: 1b0 Serial#: 33583 (II) ATI(0): Year: 1998 Week: 9 (II) ATI(0): EDID Version: 1.2 ... (--) ATI(0): ATI 3D Rage LT Pro graphics controller detected. (--) ATI(0): Chip type 4C42 LB, version 4, foundry UMC, class 0, revision 0x03 . (--) ATI(0): AGP bus interface detected; block I/O base is 0xD000. (--) ATI(0): ATI Mach64 adapter detected. (!!) ATI(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) ATI(0): Internal RAMDAC (subtype 1) detected. (==) ATI(0): RGB weight 565 (==) ATI(0): Default visual is TrueColor (==) ATI(0): Using gamma correction (1.0, 1.0, 1.0) (II) ATI(0): Using Mach64 accelerator CRTC. (**) ATI(0): Using CRT interface and disabling digital flat panel. (II) ATI(0): Storing hardware cursor image at 0xE47FFC00. (II) ATI(0): Using 8 MB linear aperture at 0xE400. (!!) ATI(0): Virtual resolutions will be limited to 8191 kB due to linear aperture size and/or placement of hardware cursor image area. (II) ATI(0): Using Block 0 MMIO aperture at 0xE6000400. (II) ATI(0): Using Block 1 MMIO aperture at 0xE600. (==) ATI(0): Write-combining range (0xe400,0x80) (II) ATI(0): MMIO write caching enabled. (--) ATI(0): 8192 kB of SGRAM (1:1) detected (using 8191 kB). (WW) ATI(0): Cannot shadow an accelerated frame buffer. (--) ATI(0): Internal programmable clock generator detected. (--) ATI(0): Reference clock 29.500 MHz. ... (II) ATI(0): [drm] created mach64 driver at busid PCI:1:0:0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xc8958000 (II) ATI(0): [drm] mapped SAREA 0xc8958000 to 0x40013000 (II) ATI(0): [drm] framebuffer handle = 0xe400 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm] Will request asynchronous DMA mode (**) ATI(0): [agp] Using AGP 2x Mode (==) ATI(0): [agp] Using 8 MB AGP aperture (II) ATI(0): [agp] Mode 0x1f000203 [AGP 0x8086/0x7190; Card 0x1002/0x4c42] (II) ATI(0): [agp] 8192 kB allocated with handle 0xc915c000 (==) ATI(0): [agp] Using 2 MB for DMA buffers (II) ATI(0): [agp] Using 6 MB for AGP textures (II) ATI(0): [agp] vertex buffers handle = 0xe000 (II) ATI(0): [agp] Vertex buffers mapped at 0x40b0c000 (II) ATI(0): [agp] AGP texture region handle = 0xe020 (II) ATI(0): [agp] AGP Texture region mapped at 0x40d0c000 (II) ATI(0): [drm] register handle = 0xe600 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xe6000400 (II) ATI(0): Memory
Re: [Dri-devel] Mach64 resource problems
On Wed, 27 Nov 2002, Svante Signell wrote: Leif Delgass writes: Have you tried a lower resolution? Not yet. Try restarting X with 1024x768@16bpp for a while and see if you still have the same problem. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Offscreen memory refers to the on-card memory left over after the framebuffer allocation(s). When there are no GL contexts, the framebuffer memory is equal to display width x display height x bytes per pixel (2 for 16-bit). With GL contexts running, there is an additional back buffer (same size as the 2D front framebuffer) plus a depth buffer which is width x height x 2 (depth buffer is always 16-bit). The remaining offscreen memory is used for XAA and XVideo buffers. You can get a BadAlloc when there is not enough offscreen memory left. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? Do you mean the XFree86.0.log or an strace log? See also below. I meant the XFree86.0.log. Could you send the whole thing as an attachment? --Leif Can you please describe how memory (both card and main memory) is allocated and released for 2D and 3D applications: What puzzles me is that if I start with a fresh X everything is OK, but after the problem occurs I have to exit X to be able to run the application again. It is not sufficient to terminate the application to get back to the same state as as when starting anew. Possible causes of the resource shortage can be: 1. The applications do not return memory when exiting. 2. X cannot reclaim the memory when the appications exit. 3. There is a memory leak somewhere. 4. Something else?? Thanks, Svante Selected parts of XFree86.0.log and strace mplayer -vo sdl file.avi below. XFree86.0.log (II) LoadModule: vbe (II) Reloading /usr/X11R6/lib/modules/libvbe.a (II) ATI(0): VESA BIOS detected (II) ATI(0): VESA VBE Version 2.0 (II) ATI(0): VESA VBE Total Mem: 8192 kB (II) ATI(0): VESA VBE OEM: ATI MACH64 (II) ATI(0): VESA VBE OEM Software Rev: 1.0 (II) ATI(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) ATI(0): VESA VBE OEM Product: MACH64LP (II) ATI(0): VESA VBE OEM Product Rev: 01.00 (II) ATI(0): VESA VBE DDC supported (II) ATI(0): VESA VBE DDC Level 2 (II) ATI(0): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(0): VESA VBE DDC read successfully (II) ATI(0): Manufacturer: NOK Model: 1b0 Serial#: 33583 (II) ATI(0): Year: 1998 Week: 9 (II) ATI(0): EDID Version: 1.2 ... (--) ATI(0): ATI 3D Rage LT Pro graphics controller detected. (--) ATI(0): Chip type 4C42 LB, version 4, foundry UMC, class 0, revision 0x03 -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
Have you tried a lower resolution? If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? --Leif On Tue, 26 Nov 2002, Svante Signell wrote: Hello, I have problems with the latest mach64 branch from dri-cvs. After a successful view of an .avi clip next time the card memory does not seem to be available, i.e. the card is left in a bad state? The only way to rerun the application is to exit X and restart. The example given below is with a 2D application: mplayer, but other applications behave similarly. I think the problem is with the mach64 driver for X, and this is developed in the DRI project, right? The X server is built from DRI-CVS two days ago with the XV patches added from Leif Delgass homepage. cat /var/log/XFree86.0.log: XFree86 Version 4.2.0 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 ... The graphics card is an ATI 3D Rage LT with 8 Meg onboard memory. Desktop size is 1280x1024 An example of output is when running mplayer with the SDL driver: VO: [sdl] 624x352 = 624x352 Planar YV12 SDL: Using driver: x11 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 142 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 21 Current serial number in output stream: 22 and with the XV driver: VO: [xv] 624x352 = 624x352 Planar YV12 X11 error: BadAlloc (insufficient resources for operation) MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow instructions there. We can't and won't help unless you provide these informations when reporting a possible bug. Xlib: unexpected async reply (sequence 0x54)! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 flatshading
On Wed, 10 Jul 2002, Allen Barnett wrote: 2. clipping.c: In this program, a cube is drawn using a flat shaded quad strip with different colors for each pair of vertices. If a face of the cube is clipped by an edge of the X window, then the triangles which the quad is decomposed into are not drawn in the correct color. You can rotate the cube around with the left mouse button to see the effect on different faces. You can zoom in and out with the middle mouse button. Once the cube is entirely inside the window, it is drawn properly. I think this may be related to a problem mentioned on Leif's status page. (It works OK with Mesa, with indirect rendering and with the TDFX driver.) I fixed this by having Mesa copy the provoking-vertex color into all vertices (by telling the template we don't have hardware flat-shading). The mach64 uses a fixed vertex number for flatshading, and we implement all primitives as triangles, reusing vertices where possible. Perhaps there is a way to order the vertices to get flat-shading to work without copying colors, but this fixes the problem. The driver still turns on flat-shading in the hardware setup engine when applicable, but I'm not sure if this makes any difference in performance. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
On Tue, Jul 16, 2002 at 11:54:02AM -0400, Leif Delgass wrote: On Wed, 10 Jul 2002, Allen Barnett wrote: 2. clipping.c: In this program, a cube is drawn using a flat shaded quad strip with different colors for each pair of vertices. If a face of the cube is clipped by an edge of the X window, then the triangles which the quad is decomposed into are not drawn in the correct color. You can rotate the cube around with the left mouse button to see the effect on different faces. You can zoom in and out with the middle mouse button. Once the cube is entirely inside the window, it is drawn properly. I think this may be related to a problem mentioned on Leif's status page. (It works OK with Mesa, with indirect rendering and with the TDFX driver.) I fixed this by having Mesa copy the provoking-vertex color into all vertices (by telling the template we don't have hardware flat-shading). The mach64 uses a fixed vertex number for flatshading, and we implement all primitives as triangles, reusing vertices where possible. Perhaps there is a way to order the vertices to get flat-shading to work without copying colors, It's probably worth to check it out, to avoid all the copying restoring that happens with this. but this fixes the problem. The driver still turns on flat-shading in the hardware setup engine when applicable, but I'm not sure if this makes any difference in performance. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. I'm surprised that this isn't working. Can you verify? I tested on the i810 at the time definitely got clipping working there... Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
On Tue, 16 Jul 2002, Keith Whitwell wrote:
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't have any effect on smooth shading. Actually,
it _eliminates_ some saves/restores necessary for unfilled polygons with
hardware flat-shading.
Actually, I think the problem is larger than mach64. Rage128 has the same
problem and it appears to have GL compliant flat-shading based on the
primitive. The problem is that for clipped polygons, the primitive type
changes, so flat-shading breaks down in that case (like with unfilled
polygons). I think the templates would have to be changed to copy the
provoking-vertex color of the polygon being clipped into the vertices of
the triangles generated by clipping, rather than interpolating the color.
I'm surprised that this isn't working. Can you verify? I tested on the i810
at the time definitely got clipping working there...
Here's a couple screenshots with the r128 driver (20020629 build):
http://www.retinalburn.net/linux/r128-unclipped-flat.png
http://www.retinalburn.net/linux/r128-clipped-flat.png
Allen's test program is attached. Maybe someone could check this on
Radeon with software tcl as well?
--
Leif Delgass
http://www.retinalburn.net
/*
* Clipped faces are not colored correctly with flat shading (except for
* the yellow face which only has one color).
* Use the left button to spin, middle button to zoom.
*/
#include GL/glut.h
static void init ( const char* filename )
{
// Set the window's background color
glClearColor( .25, .25, .25, 1. );
glShadeModel( GL_FLAT );
glEnable( GL_DEPTH_TEST );
}
static void display ( void )
{
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glBegin( GL_QUAD_STRIP );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glVertex3f( -1., -1., 1. );
glColor3f( 0., 0., 1. ); /* blue */
glVertex3f( -1., 1., -1. );
glVertex3f( -1., 1., 1. );
glColor3f( 0., 1., 0. ); /* green */
glVertex3f( 1., 1., -1. );
glVertex3f( 1., 1., 1. );
glColor3f( 1., 0., 1. ); /* magenta */
glVertex3f( 1., -1., -1. );
glVertex3f( 1., -1., 1. );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glVertex3f( -1., -1., 1. );
glEnd();
glBegin( GL_QUADS );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glColor3f( 0., 0., 1. ); /* blue */
glVertex3f( -1., 1., -1. );
glColor3f( 0., 1., 0. ); /* green */
glVertex3f( 1., 1., -1. );
glColor3f( 0., 1., 1. ); /* cyan */
glVertex3f( 1., -1. , -1. );
glColor3f( 1., 1., 0. ); /* yellow */
glVertex3f( -1., -1., 1. );
glVertex3f( 1., -1. , 1. );
glVertex3f( 1., 1., 1. );
glVertex3f( -1., 1., 1. );
glEnd();
glutSwapBuffers();
}
static void reshape ( int width, int height )
{
glViewport( 0, 0, width, height );
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glOrtho( -1.5, 1.5, -1.5, 1.5, -2, 2 );
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glRotatef( 40., 1., 0., 0. );
glRotatef( 50., 0., 1., 0. );
glRotatef( 10., 1., 0., 0. );
}
static enum MouseAction { NONE, SPIN, ZOOM } action = NONE;
static int m_x = 0;
static int m_y = 0;
static void mouse ( int button, int state, int x, int y )
{
if ( button == 0 ) {
if ( state == 0 )
action = SPIN;
else
action = NONE;
}
else if ( button == 1 ) {
if ( state == 0 )
action = ZOOM;
else
action = NONE;
}
m_x = x;
m_y = y;
}
static GLdouble modelview[16];
static void motion ( int x, int y )
{
int dx = x - m_x;
int dy = y - m_y;
switch ( action ) {
case SPIN:
glRotated( dy, modelview[0], modelview[4], modelview[8] );
glRotated( dx, modelview[1], modelview[5], modelview[9] );
glGetDoublev( GL_MODELVIEW_MATRIX, modelview );
break;
case ZOOM:
glMatrixMode( GL_PROJECTION );
if ( dy 0 )
glScalef( .99, .99, .99 );
else
glScalef( 1.01, 1.01, 1.01 );
glMatrixMode( GL_MODELVIEW );
}
m_x = x;
m_y = y;
glutPostRedisplay();
}
static void key ( unsigned char key, int x, int y )
{
switch ( key ) {
case 27:
exit( 0 );
}
}
int main ( int argc, char* argv[] )
{
// Standard GLUT setup commands
glutInit( argc, argv );
glutInitWindowSize( 500, 500 );
glutInitDisplayMode( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH );
glutCreateWindow( argv[0] );
printf( %s %s\n, glGetString( GL_VERSION ), glGetString( GL_RENDERER ) );
init( argv[1] );
glutReshapeFunc( reshape );
glutDisplayFunc( display );
glutMouseFunc( mouse );
glutMotionFunc( motion );
glutKeyboardFunc( key );
glutMainLoop();
return 0;
}
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Jul 15 13:01:11 viking kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 64MB Jul 15 13:01:11 viking kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 Jul 15 13:01:12 viking kernel: [drm] Creating pci pool Jul 15 13:01:12 viking kernel: [drm] Allocating descriptor table memory Jul 15 13:01:12 viking kernel: [drm] descriptor ring: cpu addr 0xc051c000, bus addr: 0x0051c000 Jul 15 13:01:12 viking kernel: [drm] Starting DMA test... Jul 15 13:01:12 viking kernel: [drm] starting DMA transfer... Jul 15 13:01:12 viking kernel: [drm] waiting for idle... Jul 15 13:01:12 viking kernel: [drm] waiting for idle...done Jul 15 13:01:12 viking kernel: [drm] DMA test succeeded, using asynchronous DMA mode Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] ring contents: Jul 15 13:04:02 viking kernel: [drm] head_addr: 0x0051d650 head: 1428 tail: 1944 Jul 15 13:04:02 viking kernel: Jul 15 13:04:02 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051d620: 0x007ffe48 0xd0098000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d630: 0x007ffe48 0xd018 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d640: 0x007ffe48 0xd013 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d650: 0x007ffe48 0xd01b4000 0x4dd0 0x (head) Jul 15 13:04:02 viking kernel: [drm] 0x0051d660: 0x007ffe48 0xd0054000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d670: 0x007ffe48 0xd00bc000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d680: 0x007ffe48 0xd0084000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051de30: 0x007ffe48 0xd008c000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de40: 0x007ffe48 0xd018 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de50: 0x007ffe48 0xd0098000 0xc0d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de60: 0x007ffe48 0xd00dc000 0x4068 0x (tail) Jul 15 13:04:02 viking kernel: [drm] 0x0051de70: 0x007ffe48 0xd00d4000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de80: 0x007ffe48 0xd01ec000 0x4270 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de90: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm]BM_GUI_TABLE = 0x0051d660 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 Jul 15 13:04:02 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0xd01b4460 Jul 15 13:04:02 viking kernel: [drm] BM_COMMAND = 0x4970 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_STATUS = 0x130060ca Jul 15 13:04:02 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:04:02 viking
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:48 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:48 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:48 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:48 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:48 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:50 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] ring contents: Jul 15 13:16:50 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:50 viking kernel: Jul 15 13:16:50 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:50 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:50 viking kernel: [drm] ... Jul 15 13:16:50 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:50 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:50 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:50 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:50 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:50 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:50 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:52 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:52 viking kernel: [drm] Jul 15 13:16:52 viking kernel: [drm] ring contents: Jul 15 13:16:52 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:52 viking kernel: Jul 15 13:16:52 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:52 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:52 viking kernel: [drm] ... Jul 15 13:16:52 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Yes, it's a different problem this time - the engine locked hard. [...] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 These values on the left side are absurd - the DMA buffer is busted. This means that either invalid data was generated or it was overwritten. I vote for the former (attending the new vertex template code may be buggy somewhere). [...] I think its just a coincident that it happend so soon after the server start, since I tested it a lot last night and nothing happened. Yes. It's most definetly an unrelated problem. [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:26:58PM +0200, Felix Kühling wrote: I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x ^^ Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 The engine locked while looping around the ring, reading the first entry. My guess is that the engine was already busted somehow... Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] [...] José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Oops, forgot to copy this one to the list... Begin forwarded message: Date: Mon, 15 Jul 2002 15:09:17 +0200 From: Felix Kühling [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Subject: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11 On Mon, 15 Jul 2002 12:56:33 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! I will definitely keep my interest in DRI development. And I have to thank you and Leif. José Fonseca Bye, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-20020704: gltestperf lockup on Zsmooth triangles
On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote:
On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote:
I had a lockup on an older version of the mach64 DRI driver, so
I thought I'd retest with a newer one. gltestperf locks up (no
response to keyboard, but mouse still moves--it locked up as well
in the older version) on the ZSmooth Triangles size:480 test.
Not immediately, but it locks up after the second set of triangles
and maybe early into the third.
Thanks for the report.
Here's the relivant stuff from the kernel messages:
[...]
There may have been more, but it didn't make it to the log.
Any more logging/system configuration info needed?
I'm going to see if I can reproduce it when I finish the current round
of changes.
Ok. I've determined the cause of this one: gltestperf floods with DMA buffers
enough to keep the chip busy for more than 1sec (the current timeout) so
the DRM thinks the chip locked..!
For instance changing the following line of mach64_ring_idle in mach64_dma.c
for ( i = 0 ; i dev_priv-usec_timeout; i++ ) {
to
for ( i = 0 ; i dev_priv-usec_timeout 4; i++ ) {
does the trick. But we need a more robust implementation of
mach64_ring_idle. Since we probably want to keep the timeout small
my suggestion is to count the time that takes for the ring head pointer
to advance instead of counting the time it takes to finish processing
all ring entries.
Any other ideas? Have other driver ever faced problems like this one?
José Fonseca
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-20020704: gltestperf lockup on Zsmooth triangles
José Fonseca wrote:
On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote:
On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote:
I had a lockup on an older version of the mach64 DRI driver, so
I thought I'd retest with a newer one. gltestperf locks up (no
response to keyboard, but mouse still moves--it locked up as well
in the older version) on the ZSmooth Triangles size:480 test.
Not immediately, but it locks up after the second set of triangles
and maybe early into the third.
Thanks for the report.
Here's the relivant stuff from the kernel messages:
[...]
There may have been more, but it didn't make it to the log.
Any more logging/system configuration info needed?
I'm going to see if I can reproduce it when I finish the current round
of changes.
Ok. I've determined the cause of this one: gltestperf floods with DMA buffers
enough to keep the chip busy for more than 1sec (the current timeout) so
the DRM thinks the chip locked..!
For instance changing the following line of mach64_ring_idle in mach64_dma.c
for ( i = 0 ; i dev_priv-usec_timeout; i++ ) {
to
for ( i = 0 ; i dev_priv-usec_timeout 4; i++ ) {
does the trick. But we need a more robust implementation of
mach64_ring_idle. Since we probably want to keep the timeout small
my suggestion is to count the time that takes for the ring head pointer
to advance instead of counting the time it takes to finish processing
all ring entries.
Any other ideas? Have other driver ever faced problems like this one?
I had similar troubles with the i810 moved to the scheme you suggest --
timeout for movement, not completion.
The other cards probably have the same problem, but are harder to keep busy
for that long.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-20020704: gltestperf lockup on Zsmoothtriangles
On Sun, 14 Jul 2002, José Fonseca wrote:
On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote:
On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote:
I had a lockup on an older version of the mach64 DRI driver, so
I thought I'd retest with a newer one. gltestperf locks up (no
response to keyboard, but mouse still moves--it locked up as well
in the older version) on the ZSmooth Triangles size:480 test.
Not immediately, but it locks up after the second set of triangles
and maybe early into the third.
Thanks for the report.
Here's the relivant stuff from the kernel messages:
[...]
There may have been more, but it didn't make it to the log.
Any more logging/system configuration info needed?
I'm going to see if I can reproduce it when I finish the current round
of changes.
Ok. I've determined the cause of this one: gltestperf floods with DMA buffers
enough to keep the chip busy for more than 1sec (the current timeout) so
the DRM thinks the chip locked..!
For instance changing the following line of mach64_ring_idle in mach64_dma.c
for ( i = 0 ; i dev_priv-usec_timeout; i++ ) {
to
for ( i = 0 ; i dev_priv-usec_timeout 4; i++ ) {
does the trick. But we need a more robust implementation of
mach64_ring_idle. Since we probably want to keep the timeout small
my suggestion is to count the time that takes for the ring head pointer
to advance instead of counting the time it takes to finish processing
all ring entries.
Any other ideas? Have other driver ever faced problems like this one?
A couple of things we could do that might help are to implement frame
aging and/or add the ring space check back in to throttle the frame rate
and limit the amount of pending buffers on the ring.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-20020704: gltestperf lockup on Zsmooth triangles
On Sun, Jul 14, 2002 at 02:04:27PM -0400, Leif Delgass wrote: [...] A couple of things we could do that might help are to implement frame aging and/or add the ring space check back in to throttle the frame rate and limit the amount of pending buffers on the ring. That could help but it wouldn't prevent that an application generated a wild number of triangles per frame and this would happen again, so I already fixed it on CVS. Of course that frame throttling has merits on its own so we should eventually look into it. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote:
On Sat, 13 Jul 2002, Leif Delgass wrote:
On Sun, 14 Jul 2002, José Fonseca wrote:
But the fact remains that the reads from GUI_STAT aren't reliable. I
wonder if the chip creats some transient values...
I wonder if always reading FIFO_STAT before GUI_STAT would make a
difference. The register reference says that the GUI_ACTIVE bit in
GUI_STAT would be set if the FIFO is not empty, but all the sample code I
recall looking at waits for idle by reading FIFO_STAT to make sure the
last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed
like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT.
I looked at the idle function in the DDX, and it only reads FIFO_STAT for
chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT
for all Rage Pro chips and above, so it seems unlikely that reading
FIFO_STAT would make a difference.
Ok. Let's try the following then: call do_wait_for_idle when the engine
is given as idle on ring_tick. (This basically consists of checking
FIFO_STAT and then GUI_STAT again).
If the chip generates transient idles during operation then this
should catch it (or at least it should be really unlikely to miss it). If
the chip generates transient busys while in idle (which somehow seems more
unlikely) then the error will happen again.
Felix, please try the patch attached. I'm also gonna see if I can
reproduce it (by the look of its webpages, TORCS seems a nice way to
spend sometime ;-). I'll also redo the other extra safety check that
was failing before on my system to see if it goes away too.
José Fonseca
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.26.2.3
diff -u -r1.1.6.3.2.26.2.3 mach64_drv.h
--- mach64_drv.h10 Jul 2002 04:43:49 - 1.1.6.3.2.26.2.3
+++ mach64_drv.h14 Jul 2002 18:47:07 -
-523,6 +523,9
*/
int gui_active = MACH64_READ(MACH64_GUI_STAT) MACH64_GUI_ACTIVE;
+ if( !gui_active )
+ mach64_do_wait_for_idle( dev_priv );
+
ring-head_addr = MACH64_READ(MACH64_BM_GUI_TABLE) 0xfff0;
if ( gui_active ) {
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, 14 Jul 2002 19:59:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote: On Sat, 13 Jul 2002, Leif Delgass wrote: On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. I looked at the idle function in the DDX, and it only reads FIFO_STAT for chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT for all Rage Pro chips and above, so it seems unlikely that reading FIFO_STAT would make a difference. Ok. Let's try the following then: call do_wait_for_idle when the engine is given as idle on ring_tick. (This basically consists of checking FIFO_STAT and then GUI_STAT again). If the chip generates transient idles during operation then this should catch it (or at least it should be really unlikely to miss it). If the chip generates transient busys while in idle (which somehow seems more unlikely) then the error will happen again. Felix, please try the patch attached. I'm also gonna see if I can Ok, I will apply it. But since the errors were very rare, it will take some time to be sure. Is there a way to make a patch that can print a log message when a transient idle is generated in a situation when it shoudn't and try to recover from it the way your patch does? Then if one sees such a message and the programme didn't crash one could be sure. reproduce it (by the look of its webpages, TORCS seems a nice way to spend sometime ;-). I'll also redo the other extra safety check that was failing before on my system to see if it goes away too. Yeah, it's a nice programme, but I get only between 8 and 13 fps at 640x480. José Fonseca Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, Jul 14, 2002 at 10:09:44PM +0200, Felix Kühling wrote: On Sun, 14 Jul 2002 19:59:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: [...] Felix, please try the patch attached. I'm also gonna see if I can Ok, I will apply it. But since the errors were very rare, it will take some time to be sure. Is there a way to make a patch that can print a I know... Have no hurry! log message when a transient idle is generated in a situation when it shoudn't and try to recover from it the way your patch does? Then if one sees such a message and the programme didn't crash one could be sure. As is now, not really.. unless one polls the value a little waiting for a transient value, but it's not very pratical. Just leave the patch in your tree - if nothing happens after some weeks of regular use is enough. Anyway, I think I can reproduce the problem on my testbox by letting the UT demo running alone some hours, so I hope to have a more definite answer soon. reproduce it (by the look of its webpages, TORCS seems a nice way to spend sometime ;-). I'll also redo the other extra safety check that was failing before on my system to see if it goes away too. Yeah, it's a nice programme, but I get only between 8 and 13 fps at 640x480. Hey! I didn't made the chip! I just helped on the drivers! ;-) José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, Jul 13, 2002 at 11:24:44PM +0200, Felix Kühling wrote: Hi, I tried another game: Torcs. Occasionally (about once in 1 or 2 hours) it crashes with Error flushing vertex buffer: return = -11. This is the corresponding kernel log: Jul 13 23:04:30 viking kernel: [drm:mach64_freelist_get] *ERROR* Empty ring with non-idle engine! Here it says the engine was idle [...] Jul 13 23:04:30 viking kernel: [drm] 0x0051e310: 0x007ffe48 0xd00cc000 0x4048 0x (head) (tail) ... but the engine here seems to be idle... [...] Jul 13 23:04:30 viking kernel: [drm]GUI_STAT = 0x01800100 ^ ... and here is the confirmation! I don't know how this can be but I already had to override another safety check like this one because of the same problem. The reads are made using the kernel 'readl' macro, which deals with the compiler ordering, and the memory barriers. Since it's a read there isn't caching on the PCI bus. But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... [...] I can restart torcs after that without problems. Maybe other programmes have the same problem but I didn't test them that thoroughly ;) BTW, I'm also trying to figure out a problem reported by David Willmore is always reproducible on gltestperf, which seems to happens due to excess rate of tris/sec. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Sat, 13 Jul 2002, Leif Delgass wrote: On Sun, 14 Jul 2002, José Fonseca wrote: But the fact remains that the reads from GUI_STAT aren't reliable. I wonder if the chip creats some transient values... I wonder if always reading FIFO_STAT before GUI_STAT would make a difference. The register reference says that the GUI_ACTIVE bit in GUI_STAT would be set if the FIFO is not empty, but all the sample code I recall looking at waits for idle by reading FIFO_STAT to make sure the last 16 slots are not filled, and _then_ reads GUI_STAT. It always seemed like overkill, but maybe reading FIFO_STAT somehow updates GUI_STAT. I looked at the idle function in the DDX, and it only reads FIFO_STAT for chips earlier than the VTB. It relies on the GUI_FIFO bits of GUI_STAT for all Rage Pro chips and above, so it seems unlikely that reading FIFO_STAT would make a difference. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
