First DRI uber-benchmark
This is my third attempt sending this email. If sourceforge decides to let all three copies through at once, you'll have to forgive me. A while back it was suggested that benchmarking all of the various DRI-compatible video cards might provide some interesting information. I just finished my first attempt at performing a slew of benchmarks with this goal, and the results haven't been great. It's certainly possible that (a) some of the video cards might be bad since they were purchased on ebay, (b) I didn't configure some of them properly, or (c) the CVS checkout I used had problems. At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Setup: I used an old ECS k7s5a pro motherboard with an Athlon 2400XP. 512 MB of PC2100 Ram, onboard sound, IBM G74 monitor, and Maxtor ATA100 drive. The OS was Debian Unstable, with the sources.list set to snapshot.debian.net with a date of 15 Aug 2004. The DRI packages I used are the same ones on my server (CVS checkout from 15 Aug 04 with S3TC and Radeon DynamicPM.) I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Method: All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. glxgears - let it run for 1 minute then marked down the highest score quake2 - s_initsound 0, snd_restart, timedemo 1, map demo1.dm2. Run each resolution 2x and select the highest score. Used glx OpenGL driver. quake3 - s_initsound 0, snd_restart, timedemo 1, demo four. Run each resolution 2x and select the highest score. RTCW - launched with wolfmp +set sv_cheats 1, s_initsound 0, snd_restart, timedemo 1, demo checkpoint. Run each resolution 2x and select the highest score. Unreal Tournament - launch game, bring up console, timedemo 1, wait for second flyby to complete then mark down second score. X and the games were all configured for 16 bit color. r_ext_compressed_textures was set to 0. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. Shuttle Spacewalker 32MB (sis 305) Crashes on RTCW, hangs on Unreal Tournament. glxgears gave this 337.8 fps. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. Cards that worked (more or less): Voodoo 5-5500 64MB (tdfx) glxgears - 1425.6 q2 640x480 - 56.4 q2 800x600 - 51.2 q2 1024x768 - 42.9 q3 640x480 - 95 q3 800x600 - 68 q3 1024x768 - 46.1 rtcw 640x480 - 57.6 rtcw 800x600 - 44.6 rtcw 1024x768 - 32.3 ut 640x480 - 80.79 ut 800x600 - 76.6 ut 1024x768 - 58.11 Notes: Seemed very reliable. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Radeon DDR 32MB (r100) glxgears - 1123 q2 640x480 - 87.8 q2 800x600 - 74.2 q2 1024x768 - 58.1 q3 640x480 - 114.9 q3 800x600 - 80.9 q3 1024x768 - 53.5 rtcw 640x480 - 85.5 rtcw 800x600 - 63.9 rtcw 1024x768 - 43.7 ut 640x480 - 82.97 ut 800x600 - 76.34 ut 1024x768 - 56.4 Notes: RTCW was substantially slower on the first run. Screen became corrupted once and was only fixed be a reboot. Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 Notes: Reliable, looks great. UT suffered from lots of software fallback. Radeon 8500 AIW 128MB (r200) glxgears - 2583.4 q2 640x480 - 115 q2 800x600 - 105.4 q2 1024x768 - 88.2 q3 640x480 - 165.3 q3 800x600 - 131.5 q3 1024x768 - 90.6 rtcw 640x480 - 98.4 rtcw 800x600 - 92.2 rtcw 1024x768 - 68 ut 640x480 - 73.74 ut 800x600 - 73.4 ut 1024x768 - 67.14 Notes: Roland's observations about massive slowdown at the end of the UT flyby are still accurate. Although not tested, the 8500 locks up playing ut2003 and ut2004. I have a few more cards to benchmark for comparison. Nvidia - TNT2 and FX5200 FGLRX - Radeon 8500 AIW and Radeon 9600se I also have a Radeon 9200 that I was unable to get working with this machine. Once I have all the benchmarks together I'll make some
Re: First DRI uber-benchmark
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 22 August 2004 02:16, John Lightsey wrote: At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Awesome stuff. I'd ask that you open bugs for the crashes you get, preferably with testcases that aren't closed-source games if possible. All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. There are several programs under mesa/progs/* that include synthetic benchmarks, which might show interesting variations compared with glxgears (the other canonical synthetic benchmark). Maybe. Also several of the xscreensaver GL demos have benchmarks; glblur, blocktube, flurry, and lavalite are particularly punishing, and menger and sierpinski3d are great for generating absurd numbers of polygons. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. This you can probably drop from future testing. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. This is disturbing, I used to play ut on a mach64 all the time. Perhaps the DMA path is still busted? - - ajax -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBKEKcW4otUKDs0NMRAgKtAKCUxdHJ5lFXMK0i+o6lFcdqrHRN1ACfQoL9 Kk57HH8zm33OypDlRZbhW3A= =o0+S -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. I can confirm that this card locks up very frequently. One way which I have found to immediately lock it up is by attempting to use GL_NV_texgen_reflection. Hope this helps the savage developers. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1003] running two instances of glsnake locks X
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1003 --- Additional Comments From [EMAIL PROTECTED] 2004-08-22 01:23 --- Could you try again with current mesa-cvs ? Eric Anholt committed a fix against locking issues with r100/r200. I tried it on r100 and it helped: running glxgears and some instances ipers at the same time worked well: no data/vertex-migration between contexts. q3a and glxgears at the same time seems to be ok now, too. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][DRI] Fix singlesize.c compile error for glx...
On Sat, 21 Aug 2004 23:44:26 -0500 Steven J. Hill [EMAIL PROTECTED] wrote: Latest CVS checkout does not compile, please apply. -Steve Please note that the xc module in DRI CVS has been officially declared dead. All DRI development is now going on in either Mesa CVS or Xorg CVS. Only the DRM module is still in DRI CVS. I'm going to commit a fix for this anyway in order to get the snapshots building again until I get around to making them build them from Xorg CVS. Regards, Felix [snip patch] | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 08:16, John Lightsey wrote: Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. I also encountered this instability on a mobility M6 (mobile Rage128) --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sun, 22 Aug 2004 01:16:18 -0500 John Lightsey [EMAIL PROTECTED] wrote: Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. There are rumors about some Savage4's that lock up when reading the status register. :-/ A workaround would be to use shadow status (the card writes status to system/AGP memory and the driver picks it up from there). This is high on my todo list, but it'll require some fundamental work on the DRM driver first. In the mean time, maybe trying different AGP speeds would help. Or is this a PCI card? Also, the Savage4 I'm using for testing here has severe heat problems. Mounting a small fan on top of the passive heat sink helped. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Good to know that at least one Savage4 works more or less reliably. ;-) Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On 22.08.2004, at 08:16, John Lightsey wrote: glxgears - let it run for 1 minute then marked down the highest score how reproducable and meaningful is a highest score? I don't know, but I got a feeling that using a mean or a median might be of better reproducability and also might better reflect common 3d response feeling (in case you want to make a real-world benchmark, not a synthetic one). cheers simon -- /\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
Re: First DRI uber-benchmark
On Sunday 22 August 2004 04:57, Simon 'corecode' Schubert wrote: On 22.08.2004, at 08:16, John Lightsey wrote: glxgears - let it run for 1 minute then marked down the highest score how reproducable and meaningful is a highest score? I don't know, but I got a feeling that using a mean or a median might be of better reproducability and also might better reflect common 3d response feeling (in case you want to make a real-world benchmark, not a synthetic one). The high score ends up being a fraction of a frame higher than the mode score. The difference doesn't seem significant on any of the cards. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 04:59, Felix Kühling wrote: On Sun, 22 Aug 2004 01:16:18 -0500 John Lightsey [EMAIL PROTECTED] wrote: Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. There are rumors about some Savage4's that lock up when reading the status register. :-/ A workaround would be to use shadow status (the card writes status to system/AGP memory and the driver picks it up from there). This is high on my todo list, but it'll require some fundamental work on the DRM driver first. In the mean time, maybe trying different AGP speeds would help. Or is this a PCI card? They're all AGP cards. I'll try setting the a90 to AGP1x to see if that helps. The crash with the IBM SR9 happens while the checkpoint demo is loading. Some kind of texture loading problem perhaps? John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Sul, 2004-08-22 at 02:51, Jon Smirl wrote: Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. That lock is already released whenever the code sleeps (eg page faults) so if its broken then its already broken and it doesn't matter. If it isnt broken then its still not broken --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sul, 2004-08-22 at 07:16, John Lightsey wrote: I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Which DRI kernel modules - the CVS tree provided ones or the 2.6.7 kernel ones ? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
Which DRI kernel modules - the CVS tree provided ones or the 2.6.7 kernel ones ? there should be no regression between them, I'd expect the currrnt CVS ones might in theory be slower than 2.6.7 but I haven't seen any regressions on the radeon modules while I've been doing the function table work, 2.6.7 is pretty close to CVS about 5 mths ago... I don't think we have fixed any lockups or anything of that great interest in this time .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sul, 2004-08-22 at 13:11, Dave Airlie wrote: there should be no regression between them, I'd expect the currrnt CVS ones might in theory be slower than 2.6.7 but I haven't seen any regressions on the radeon modules while I've been doing the function table work, 2.6.7 is pretty close to CVS about 5 mths ago... I don't think we have fixed any lockups or anything of that great interest in this time .. At least on the fedora-test list the new Xorg CVS seems to be showing up some i815/830 works with 2.6.8.1 but not 2.6.old kernels. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
First DRI uber-benchmark
A while back it was suggested that benchmarking all of the various DRI-compatible video cards might provide some interesting information. I just finished my first attempt at performing a slew of benchmarks with this goal, and the results haven't been great. It's certainly possible that (a) some of the video cards might be bad since they were purchased on ebay, (b) I didn't configure some of them properly, or (c) the CVS checkout I used had problems. At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Setup: I used an old ECS k7s5a pro motherboard with an Athlon 2400XP. 512 MB of PC2100 Ram, onboard sound, IBM G74 monitor, and Maxtor ATA100 drive. The OS was Debian Unstable, with the sources.list set to snapshot.debian.net with a date of 15 Aug 2004. The DRI packages I used are the same ones on my server (CVS checkout from 15 Aug 04 with S3TC and Radeon DynamicPM.) I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Method: All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. glxgears - let it run for 1 minute then marked down the highest score quake2 - s_initsound 0, snd_restart, timedemo 1, map demo1.dm2. Run each resolution 2x and select the highest score. Used glx OpenGL driver. quake3 - s_initsound 0, snd_restart, timedemo 1, demo four. Run each resolution 2x and select the highest score. RTCW - launched with wolfmp +set sv_cheats 1, s_initsound 0, snd_restart, timedemo 1, demo checkpoint. Run each resolution 2x and select the highest score. Unreal Tournament - launch game, bring up console, timedemo 1, wait for second flyby to complete then mark down second score. X and the games were all configured for 16 bit color. r_ext_compressed_textures was set to 0. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. Shuttle Spacewalker 16MB (sis 305) Lots of crashing. Problems with vesafb? glxgears gave this 337.8 fps. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. Cards that worked (more or less): Voodoo 5-5500 64MB (tdfx) glxgears - 1425.6 q2 640x480 - 56.4 q2 800x600 - 51.2 q2 1024x768 - 42.9 q3 640x480 - 95 q3 800x600 - 68 q3 1024x768 - 46.1 rtcw 640x480 - 57.6 rtcw 800x600 - 44.6 rtcw 1024x768 - 32.3 ut 640x480 - 80.79 ut 800x600 - 76.6 ut 1024x768 - 58.11 Notes: Seemed very reliable. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Radeon DDR 32MB (r100) glxgears - 1123 q2 640x480 - 87.8 q2 800x600 - 74.2 q2 1024x768 - 58.1 q3 640x480 - 114.9 q3 800x600 - 80.9 q3 1024x768 - 53.5 rtcw 640x480 - 85.5 rtcw 800x600 - 63.9 rtcw 1024x768 - 43.7 ut 640x480 - 82.97 ut 800x600 - 76.34 ut 1024x768 - 56.4 Notes: RTCW was substantially slower on the first run. Screen became corrupted once and was only fixed be a reboot. Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 Notes: Reliable, looks great. UT suffered from lots of software fallback. Radeon 8500 AIW 128MB (r200) glxgears - 2583.4 q2 640x480 - 115 q2 800x600 - 105.4 q2 1024x768 - 88.2 q3 640x480 - 165.3 q3 800x600 - 131.5 q3 1024x768 - 90.6 rtcw 640x480 - 98.4 rtcw 800x600 - 92.2 rtcw 1024x768 - 68 ut 640x480 - 73.74 ut 800x600 - 73.4 ut 1024x768 - 67.14 Notes: Roland's observations about massive slowdown at the end of the UT flyby are still accurate. Although not tested, the 8500 locks up playing ut2003 and ut2004. I have a few more cards to benchmark for comparison. Nvidia - TNT2 and FX5200 FGLRX - Radeon 8500 AIW and Radeon 9600se I also have a Radeon 9200 that I was unable to get working with this machine. Once I have all the benchmarks together I'll make some pretty little graphs. Soany suggestions, comments, feedback? John
Re: 2.4.8.1+P6: radeon, dri xruns
On Sat, 2004-08-21 at 15:25, Fernando Pablo Lopez-Lezcano wrote: On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: I don't believe the DRM drivers are holding any global kernel locks when they do wait_for_fifo. Any locks held would be internal to DRM and can be changed if needed. There must be a lock. I used to use a patch that I found somewhere (that does conditional reschedules), but it triggers the scheduling while lock held kernel oops if you enable that option in the kernel configuration. There are several, and they undoubtedly interact in subtle ways. Grep for spin_lock in the drm directory and you will see what i mean. These locks are internal to the DRM and not global kernel locks, which makes it possible to fix them, but holding any spinlock will disable preemption. Based on the generalized solution Ingo proposed and the reaction of the DRI developers it seems like this will not be too hard to fix, but a thorough understanding of the locking code will be required. Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 01:52, Adam Jackson wrote: On Sunday 22 August 2004 02:16, John Lightsey wrote: At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Awesome stuff. I'd ask that you open bugs for the crashes you get, preferably with testcases that aren't closed-source games if possible. Once I'm certain that the problems are not caused by bad hardware or a bad configuration on my part I'll try to debug and report the lockups and crashes. All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. There are several programs under mesa/progs/* that include synthetic benchmarks, which might show interesting variations compared with glxgears (the other canonical synthetic benchmark). Maybe. Also several of the xscreensaver GL demos have benchmarks; glblur, blocktube, flurry, and lavalite are particularly punishing, and menger and sierpinski3d are great for generating absurd numbers of polygons. I looked around for some free software programs that would calculate an average framerate rather than simply showing a FPS counter, but I didn't find any. Something based on crystal-space would be particularly nice. I also looked at specviewperf, but it takes far too long to run. Are there any in mesa/progs that stand out? Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. This is disturbing, I used to play ut on a mach64 all the time. Perhaps the DMA path is still busted? It crashes without locking the display or even changing the resolution. This one looks easier to debug than the others. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote: The delay is very large because this routine is waiting for the graphics coprocessor to finish an operation. Some of the operations can take many ms to complete; for example telling the chip to copy 64MB of memory somewhere. I would think the question should be, how do we wait on the GPU without killing both audio and video latency. The problem here is that most graphics commands are very short in duration. Some of these commands can be issued a million of times per second. A few commands are much longer running. I don't believe there is an easy way to tell how long the commands will run. A better solution might be to loop twenty times to pick up the very short commands. After 20us switch to a loop that allows the kernel to schedule. You don't want to immediately schedule since that will kill graphics performance. As Ingo comments in another email I don't think that is necessarily the case [but then again I'm not an expert in the schedulling code]. You want to test whether a schedule is needed (a conditional reschedule, if I'm correct). If it is not then nothing happens and the code keeps feeding comands to the graphics processor. If one is needed then I don't see why the graphics code should keep holding the processor. Ok, if there is something else that needs the processor graphics performance could be affected, but that is because there is something else that needs the processor (and will suffer a performance problem if ignored). -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
[please cc me, I'm not on the dri list]
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
memory somewhere.
That corresponds to my experience. I currently use glxgears while
running low latency audio stuff to test whether the problem is there or
not. For small window sizes (of glxgears) everything is fine. If I keep
making the window bigger there is a point where I start triggering xruns
like crazy (7 to 10 msecs or so).
I would think the question should be, how do we wait
on the GPU without killing both audio and video latency.
The problem here is that most graphics commands are very short in
duration. Some of these commands can be issued a million of times per
second. A few commands are much longer running. I don't believe there
is an easy way to tell how long the commands will run.
A better solution might be to loop twenty times to pick up the very
short commands. After 20us switch to a loop that allows the kernel to
schedule. You don't want to immediately schedule since that will kill
graphics performance.
What would be a good program that measures graphics performance that I
could run to test this? I could build a kernel with a patch I have that
has conditional reschedules in it (but it is illegal in the sense that
reschedules with a lock held) and see how that impacts performance, or
not. But I need something to test that will reflect some metric that
makes sense to the graphics crowd.
-- Fernando
What's the right way to write a loop like this that meets the above
requirements and also satisfies the audio needs?
static int radeon_do_wait_for_idle( drm_radeon_private_t *dev_priv )
{
int i, ret;
dev_priv-stats.boxes |= RADEON_BOX_WAIT_IDLE;
ret = radeon_do_wait_for_fifo( dev_priv, 64 );
if ( ret ) return ret;
for ( i = 0 ; i dev_priv-usec_timeout ; i++ ) {
if ( !(RADEON_READ( RADEON_RBBM_STATUS )
RADEON_RBBM_ACTIVE) ) {
radeon_do_pixcache_flush( dev_priv );
return 0;
}
DRM_UDELAY( 1 );
}
#if RADEON_FIFO_DEBUG
DRM_ERROR( failed!\n );
radeon_status( dev_priv );
#endif
return DRM_ERR(EBUSY);
}
=
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: I don't believe the DRM drivers are holding any global kernel locks when they do wait_for_fifo. Any locks held would be internal to DRM and can be changed if needed. There must be a lock. I used to use a patch that I found somewhere (that does conditional reschedules), but it triggers the scheduling while lock held kernel oops if you enable that option in the kernel configuration. -- Fernando --- Lee Revell [EMAIL PROTECTED] wrote: On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: What's the right way to write a loop like this that meets the above requirements and also satisfies the audio needs? I think it depends on which locks you are holding, and what kind of locks they are. Lee = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Sat, 2004-08-21 at 09:58, Jon Smirl wrote: BTW, loops like this are in most of the DRM drivers for other cards. They are probably in accelerated framebuffer drivers too. I know for a fact that the mga driver also has this problem, and I suspect that the r128 is also affected (but have not tested it). When I looked at them a while ago the code base seemed very similar so that most probably a fix for one of them would be usable for the others. -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
First DRI uber-benchmark
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sent this message earlier, but it doesn't seem to have made it through. Subject: First DRI uber-benchmark Date: Saturday 21 August 2004 13:17 From: John Lightsey [EMAIL PROTECTED] To: [EMAIL PROTECTED] A while back it was suggested that benchmarking all of the various DRI-compatible video cards might provide some interesting information. I just finished my first attempt at performing a slew of benchmarks with this goal, and the results haven't been great. It's certainly possible that (a) some of the video cards might be bad since they were purchased on ebay, (b) I didn't configure some of them properly, or (c) the CVS checkout I used had problems. At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Setup: I used an old ECS k7s5a pro motherboard with an Athlon 2400XP. 512 MB of PC2100 Ram, onboard sound, IBM G74 monitor, and Maxtor ATA100 drive. The OS was Debian Unstable, with the sources.list set to snapshot.debian.net with a date of 15 Aug 2004. The DRI packages I used are the same ones on my server (CVS checkout from 15 Aug 04 with S3TC and Radeon DynamicPM.) I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Method: All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. glxgears - let it run for 1 minute then marked down the highest score quake2 - s_initsound 0, snd_restart, timedemo 1, map demo1.dm2. Run each resolution 2x and select the highest score. Used glx OpenGL driver. quake3 - s_initsound 0, snd_restart, timedemo 1, demo four. Run each resolution 2x and select the highest score. RTCW - launched with wolfmp +set sv_cheats 1, s_initsound 0, snd_restart, timedemo 1, demo checkpoint. Run each resolution 2x and select the highest score. Unreal Tournament - launch game, bring up console, timedemo 1, wait for second flyby to complete then mark down second score. X and the games were all configured for 16 bit color. r_ext_compressed_textures was set to 0. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. Shuttle Spacewalker 16MB (sis 305) Lots of crashing. Problems with vesafb? glxgears gave this 337.8 fps. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. Cards that worked (more or less): Voodoo 5-5500 64MB (tdfx) glxgears - 1425.6 q2 640x480 - 56.4 q2 800x600 - 51.2 q2 1024x768 - 42.9 q3 640x480 - 95 q3 800x600 - 68 q3 1024x768 - 46.1 rtcw 640x480 - 57.6 rtcw 800x600 - 44.6 rtcw 1024x768 - 32.3 ut 640x480 - 80.79 ut 800x600 - 76.6 ut 1024x768 - 58.11 Notes: Seemed very reliable. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Radeon DDR 32MB (r100) glxgears - 1123 q2 640x480 - 87.8 q2 800x600 - 74.2 q2 1024x768 - 58.1 q3 640x480 - 114.9 q3 800x600 - 80.9 q3 1024x768 - 53.5 rtcw 640x480 - 85.5 rtcw 800x600 - 63.9 rtcw 1024x768 - 43.7 ut 640x480 - 82.97 ut 800x600 - 76.34 ut 1024x768 - 56.4 Notes: RTCW was substantially slower on the first run. Screen became corrupted once and was only fixed by a reboot. Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 Notes: Reliable, looks great. UT suffered from lots of software fallback. Radeon 8500 AIW 128MB (r200) glxgears - 2583.4 q2 640x480 - 115 q2 800x600 - 105.4 q2 1024x768 - 88.2 q3 640x480 - 165.3 q3 800x600 - 131.5 q3 1024x768 - 90.6 rtcw 640x480 - 98.4 rtcw 800x600 - 92.2 rtcw 1024x768 - 68 ut 640x480 - 73.74 ut 800x600 - 73.4 ut 1024x768 - 67.14 Notes: Roland's observations about massive slowdown at the end of the UT flyby are still accurate. Although not tested, the 8500 locks up playing ut2003 and ut2004. I have a few more cards to benchmark for comparison. Nvidia - TNT2 and FX5200 FGLRX - Radeon 8500 AIW and Radeon 9600se I also have a Radeon 9200
Re: 2.4.8.1+P6: radeon, dri xruns
* Jon Smirl [EMAIL PROTECTED] wrote:
--- Ingo Molnar [EMAIL PROTECTED] wrote:
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then you can sleep precisely up to completion:
Interrupts are not a good solution. The hardware would generate
millions of them per second. This is the same problem network cards
have, you can interrupt the machine to death.
you'd only have to enable interrupt generation when you are not
busy-polling. In 99.9% of the cases (when !need_resched()) you could
busy poll as much as you want, and keep IRQ generation off. Very likely
IRQ generation can be turned on/off via a single PCI write on most 3D
hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
following property is a must:
I would expect the best solution is to make a few passes through the
loop delaying a couple usec to catch the common case of quick
completion. Then switch to doing need_resched().
no. If need_resched() is set then the code *must* try to schedule ASAP.
There is no excuse for not doing so - 'performance will suffer' is not a
correct argument becase _if_ need_resched() is true then the system (and
the user) doesnt want the 3D app to run right now. There will be no
performance difference to the 3D app, since by having high latencies the
DRI code does not give any extra performance to 3D apps, it only
increases the scheduling latency! The timeslices of the 3D app are used
up depending on how long the 3D app runs - so if it burns cycles
busy-polling it will in fact get less CPU time on average. (if the CPU
is contended.)
Anyway, need_resched() set is not a common condition, and if it happens
then kernel code _must_ react. (In fact most kernel code will be
preempted right away - but the DRI code runs under spinlocks.)
So the correct solution is to add something like this to _at least_ the
busy-polling code:
if (need_resched()) {
... drop locks ...
cond_resched();
... reacquire locks ...
}
or, if there's a single spinlock held (the BKL doesnt count) then:
cond_resched_lock(driver-lock);
(but the locking obviously has to be correct and safe.)
ok?
Ingo
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sun, 2004-08-22 at 11:40 +0200, Steffen Hein wrote: On Sunday 22 August 2004 08:16, John Lightsey wrote: Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. I also encountered this instability on a mobility M6 (mobile Rage128) M6 is Radeon, the mobile Rage128 chips were M3 and M4 (and M5?). Which is it? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sun, 2004-08-22 at 01:16 -0500, John Lightsey wrote:
This is my third attempt sending this email. If sourceforge decides to let
all three copies through at once, you'll have to forgive me.
It's mostly me administrating the dri-{announce,devel,patches} at the
moment... if anyone (preferably non-newcomers though) wants to help out,
that would be great.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 05:39, Alan Cox wrote: On Sul, 2004-08-22 at 07:16, John Lightsey wrote: I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Which DRI kernel modules - the CVS tree provided ones or the 2.6.7 kernel ones ? The kernel modules were from CVS. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
You're right. It's a 8mb mobility M3 in a dell latitude c600. Sorry, not my notebook ;-) --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
Here are the FGLRX and Nvidia scores for comparison... The Nvidia drivers were built from the packages in Debian non-free (1.0.6111) and the FGLRX drivers were built from Flavio Stanchina's packages (3.11.1). BFG FX5200 Ultra 128MB glxgears - 3934.8 q2 640x480 - 337.1 q2 800x600 - 312.3 q2 1024x768 - 268.5 q3 640x480 - 219.2 q3 800x600 - 217.6 q3 1024x768 - 203.6 rtcw 640x480 - 108.9 rtcw 800x600 - 108.7 rtcw 1024x768 - 107.7 ut 640x480 - 98.12 ut 800x600 - 98.28 ut 1024x768 - 95.71 Notes: TNT2 32MB glxgears - 491.6 q2 640x480 - 83.7 q2 800x600 - 55 q2 1024x768 - 38.9 q3 640x480 - 54.2 q3 800x600 - 34.6 q3 1024x768 - 22.4 rtcw 640x480 - 41.8 rtcw 800x600 - 27.2 rtcw 1024x768 - 17.4 ut 640x480 - 60.14 ut 800x600 - 41.59 ut 1024x768 - 26.31 Notes: Locked up with agpgart. Minor display corruption when switching resolutions in UT which was cleared up by restarting X. Radeon 8500 AIW 128MB w/FGLRX Contant lockups... Totally unusable. Radeon 9600LE 128MB glxgears - 753.4 q2 640x480 - 146.2 q2 800x600 - 97.8 q2 1024x768 - 56 q3 640x480 - 133.6 q3 800x600 - 82.8 q3 1024x768 - 45.3 rtcw 640x480 - 95.1 rtcw 800x600 - 67.4 rtcw 1024x768 - 37.7 ut 640x480 - 93.08 ut 800x600 - 72.98 ut 1024x768 - 41.65 Notes: These numbers all represent X running at 32 bit color depth. FGLRX does not support 16 bit. So... A Radeon DDR 32MB running DRI seems to be faster than a TNT2 32MB. Matrox G400 seems to be faster on everything other than Unreal Tournament. I'll send a link to the graphs on Monday. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
In gmane.comp.video.dri.devel, you wrote: I looked around for some free software programs that would calculate an average framerate rather than simply showing a FPS counter, but I didn't find any. Something based on crystal-space would be particularly nice. Have a look at the samples provided with the Ogre engine; they calculate the average framerate of every run and the minima and maxima: http://www.ogre3d.org They should be pretty useful especially for benchmarking advanced 3D stuff. The default build links against the proprietary Cg library by Nvidia. To circumvent that simply remove the autoconf test for Cg in configure.in, remove CgProgramManager from PlugIns/Makefile.am and run bootstrap.sh. The functionality is not affected as Cg shader support is loaded on demand. Cheers, Moritz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sul, 2004-08-22 at 21:51, John Lightsey wrote: So... A Radeon DDR 32MB running DRI seems to be faster than a TNT2 32MB. Matrox G400 seems to be faster on everything other than Unreal Tournament. I'll send a link to the graphs on Monday. Maybe I should get the Voodoo2 DRI written. The voodoo2 can wipe the Matrox G400's backside but I'd assumed it was still too slow to be useful --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.8.1+P6: radeon, dri xruns
On Fri, 2004-08-20 at 22:37, Dave Airlie wrote: It looks like the timeout for many Radeon DRI operations is controlled by the dev_priv-usec_timeout value, which is copied from userspace via ioctl in radeon_cp_init. This value can be as large as 100 MSECS! radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ The driver does not seem to have a default for this, so you need to find the userspace code that is initializing the DRI and find the value it is being set to. the current default is 1 usecs from radeon_dri.h in xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value Hey, thanks, I was not aware of that option! Changing the value has the predictable effect of lowering the duration of the latency hits I get. Setting it to 1000 (instead of 1) makes it possible to run glxgears (the test I'm using to trigger xruns) with bigger screen sizes than before. I can still trigger xruns, of course, but they are 1ms instead of 10ms :-( DRI gurus: let me know if somebody comes up with a patch, I'm willing to be a guinea pig... -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
At least on the fedora-test list the new Xorg CVS seems to be showing up some i815/830 works with 2.6.8.1 but not 2.6.old kernels. hmm interesting.. I'll try and get Xorg on one of my i810 systems in the next day or two... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote: Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 I'm aware of two perfomance bottlenecks in the driver. Number one is that it always uses synchronous DMA. I have asynchronous DMA working just fine under DirectFB but it should probably be tested more with XFree86 before going to cvs. Number two is the TC2_MAGIC bit. It really hurts the single texturing case and even dual texturing gains ~1 fps (in q3) with that bit turned off. Even with those two changes the Windows drivers are still quite a bit faster :( Notes: Reliable, looks great. UT suffered from lots of software fallback. Any idea what fallbacks? ut2k4 demo was actually playable on my G400 if I disabled the texenv extensions. We probably need a config option for that. ut2k3 demo always used projective multi texturing despite what settings I tweaked so I couldn't get decent performance out of it. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 18:37, Ville Syrjälä wrote: On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote: Matrox G400 32MB (mga) ... I'm aware of two perfomance bottlenecks in the driver. Number one is that it always uses synchronous DMA. I have asynchronous DMA working just fine under DirectFB but it should probably be tested more with XFree86 before going to cvs. Number two is the TC2_MAGIC bit. It really hurts the single texturing case and even dual texturing gains ~1 fps (in q3) with that bit turned off. Even with those two changes the Windows drivers are still quite a bit faster :( Notes: Reliable, looks great. UT suffered from lots of software fallback. Any idea what fallbacks? ut2k4 demo was actually playable on my G400 if I disabled the texenv extensions. We probably need a config option for that. ut2k3 demo always used projective multi texturing despite what settings I tweaked so I couldn't get decent performance out of it. I'm not at all sure... It slows down to a crawl in a few different places. 1) The section of tunnel with textures on the ground that look like paper trash. This lasts until you pass the grate with steam coming out of it. 2) As the billboards are approached it slows down. (This happens twice.) 3) Heading towards the fire escape it slows down. 4) Right before it enters the tunnel on the building it slows down very briefly. ut2004 is almost playable with the g400 with the lowest settings. The Nvidia logo looks wrong and it's very slow. There are also some points on different maps where the framerate drops through the floor (on DM-Asbestos for instance, when you look at the sunken area where the rocket launcher appears, the framerate drops to single digits. The sunken area is supposed to be filled with water, but there is no water visible with the g400.) I didn't include ut2003/2004 in the list of benchmarks because I didn't figure any of the cards would handle it. I'll try including on of them next time. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
--- Jon Smirl [EMAIL PROTECTED] wrote: Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. I don't know what it will take to fix locking to allow this, maybe one of the original DRM authors will pop in here with the answer. Until locking is adjusted we can't add the schedule call. From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) Also DRI allready runes with it off in ioctls, every time there is a sleep. This is why DRI has spinlocks, right? Now if we turn BKL off for our ioctls we defeat the pupose it was turned on for, what is that? Would it be posible to use differed execution instead of blindly droping the BKL? As for the other DRI-spinlocks the code presented by Ingo Molnar lookes correct, no arguments here. I just don't see why DRI needs to drop the BKL any sooner then any other part of the kernel? After all DRI dosen't request it, it's just one of many victums of the ioctl BKL. So I think it would be best to let upstream fix the DRI BKL problem. --- Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] wrote: On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: I don't believe the DRM drivers are holding any global kernel locks when they do wait_for_fifo. Any locks held would be internal to DRM and can be changed if needed. There must be a lock. I used to use a patch that I found somewhere (that does conditional reschedules), but it triggers the scheduling while lock held kernel oops if you enable that option in the kernel configuration. -- Fernando --- Lee Revell [EMAIL PROTECTED] wrote: On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: What's the right way to write a loop like this that meets the above requirements and also satisfies the audio needs? I think it depends on which locks you are holding, and what kind of locks they are. Lee = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
--- Ingo Molnar [EMAIL PROTECTED] wrote:
* Jon Smirl [EMAIL PROTECTED] wrote:
--- Ingo Molnar [EMAIL PROTECTED] wrote:
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then you can sleep precisely up to completion:
Interrupts are not a good solution. The hardware would generate
millions of them per second. This is the same problem network cards
have, you can interrupt the machine to death.
you'd only have to enable interrupt generation when you are not
busy-polling. In 99.9% of the cases (when !need_resched()) you could
busy poll as much as you want, and keep IRQ generation off. Very likely
IRQ generation can be turned on/off via a single PCI write on most 3D
hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
following property is a must:
This lookes like a great idea. We turn on interrupt generation just after
we drop our spinlock(in the if need_resched() block). This would greatly
improve system proformance as IRQs would only be used when we wait for
long periods.
I would expect the best solution is to make a few passes through the
loop delaying a couple usec to catch the common case of quick
completion. Then switch to doing need_resched().
no. If need_resched() is set then the code *must* try to schedule ASAP.
There is no excuse for not doing so - 'performance will suffer' is not a
correct argument becase _if_ need_resched() is true then the system (and
the user) doesnt want the 3D app to run right now. There will be no
performance difference to the 3D app, since by having high latencies the
DRI code does not give any extra performance to 3D apps, it only
increases the scheduling latency! The timeslices of the 3D app are used
up depending on how long the 3D app runs - so if it burns cycles
busy-polling it will in fact get less CPU time on average. (if the CPU
is contended.)
I see jerky ness alot with Q3, where frame rate spikes for one frame.
This lookes like a good explination, as the frame b4 and after would have
many of the same GL calls.
End Of Line.
Anyway, need_resched() set is not a common condition, and if it happens
then kernel code _must_ react. (In fact most kernel code will be
preempted right away - but the DRI code runs under spinlocks.)
So the correct solution is to add something like this to _at least_ the
busy-polling code:
if (need_resched()) {
... drop locks ...
cond_resched();
... reacquire locks ...
}
or, if there's a single spinlock held (the BKL doesnt count) then:
cond_resched_lock(driver-lock);
(but the locking obviously has to be correct and safe.)
ok?
Ingo
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
