From: John L. <dri...@ni...> - 2004-08-22 06:07:46
|
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 pretty little graphs. So....any suggestions, comments, feedback? John |
From: John L. <jo...@ni...> - 2004-08-21 18:09:21
|
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. So....any suggestions, comments, feedback? John |
From: Ian R. <id...@us...> - 2004-08-23 17:37:25
|
John Lightsey wrote: > Once I have all the benchmarks together I'll make some pretty little graphs. > > So....any suggestions, comments, feedback? First off, great work! Hopefully you'll be willing to re-run those tests to look for regressions in future releases. ;) I have only two criticisms. First, demo4 is a crummy Quake3 benchmark, and demo1 is a crummy Quake2 benchmark. I've got a couple Quake3 demos that I recorded for DRI testing that I can post in the next day or so. Something like "massive1" or "crusher" would be a much better Quake2 benchmark (that really turns back the way-back clock for me!). My other critical comment is that you only have texture intensive benchmarks. It would be nice to add a couple purely polygon intensive benchmarks. I know that viewperf is a pain to run, but it does it's job well. Do any of the open-source modeling packages (i.e., Blender) have a benchmark mode? I think that might be intersting to a lot of Linux people. |
From: John L. <dri...@ni...> - 2004-08-24 00:24:22
|
On Monday 23 August 2004 12:36, Ian Romanick wrote: > John Lightsey wrote: > > Once I have all the benchmarks together I'll make some pretty little > > graphs. > > > > So....any suggestions, comments, feedback? > > First off, great work! Hopefully you'll be willing to re-run those > tests to look for regressions in future releases. ;) > > I have only two criticisms. First, demo4 is a crummy Quake3 benchmark, > and demo1 is a crummy Quake2 benchmark. I've got a couple Quake3 demos > that I recorded for DRI testing that I can post in the next day or so. > Something like "massive1" or "crusher" would be a much better Quake2 > benchmark (that really turns back the way-back clock for me!). > I'll look into those Quake2 demos for the next try. Benchmarking Quake2 and Quake3 is very fast, so including another demo or two shouldn't be a problem. > My other critical comment is that you only have texture intensive > benchmarks. It would be nice to add a couple purely polygon intensive > benchmarks. I know that viewperf is a pain to run, but it does it's job > well. Do any of the open-source modeling packages (i.e., Blender) have > a benchmark mode? I think that might be intersting to a lot of Linux > people. I'd be interested in average FPS for things like blender, chromium, bzflag, etc... Perhaps they'll take patches to add it in if the code isn't there already. I gave up on specviewperf after waiting over half an hour for the Voodoo 5 to run it. It's just too time consuming. Are there one or two tests that stand out in particular? The HTML version with lots of pretty pictures and graphs is online here: http://www.nixnuts.net/benchmarks/040815/ Thanks to everyone that has given feedback. I'll run another round of benchmarks in a month or two and try to submit bug reports on everything that doesn't work in the mean time. DRI is an amazing piece of software.... Many thanks to everyone for the great work. John |
From: Philipp K. K. <pk...@sp...> - 2004-08-24 10:04:52
|
John Lightsey schrieb: > > I gave up on specviewperf after waiting over half an hour for the Voodoo 5 to > run it. It's just too time consuming. Are there one or two tests that stand > out in particular? > > I'd propose 3dsmax-02, ugs-03 and proe-02 since in the Radeon driver comparison done by Ronald Schneidegger these three were the ones were most rendering errors occured, so running these should find rendering errors in addition to benchmarking. See http://homepage.hispeed.ch/rscheidegger/ for the comparison. Philipp Klaus Krause |
From: John L. <jo...@ni...> - 2004-08-21 23:46:18
|
-----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 <jo...@ni...> To: dri...@li... 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 that I was unable to get working with this machine. Once I have all the benchmarks together I'll make some pretty little graphs. So....any suggestions, comments, feedback? John - ------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBJ+DFBYeybkXz+/kRAoI3AKDQ6nUo6PQx63wCZKyvDayUic6+tgCgnpSo Ym15SdTOlNBMOIjotpQYNCY= =zAUt -----END PGP SIGNATURE----- |
From: Adam J. <aj...@nw...> - 2004-08-22 06:52:27
|
=2D----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 testcas= es=20 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=20 benchmarks, which might show interesting variations compared with glxgears= =20 (the other canonical synthetic benchmark). Maybe. Also several of the=20 xscreensaver GL demos have benchmarks; glblur, blocktube, flurry, and=20 lavalite are particularly punishing, and menger and sierpinski3d are great= =20 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 th= e=20 DMA path is still busted? =2D - ajax =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBKEKcW4otUKDs0NMRAgKtAKCUxdHJ5lFXMK0i+o6lFcdqrHRN1ACfQoL9 Kk57HH8zm33OypDlRZbhW3A=3D =3Do0+S =2D----END PGP SIGNATURE----- |
From: John L. <jo...@ni...> - 2004-08-22 07:42:29
|
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 |
From: Moritz M. <jm...@in...> - 2004-08-22 21:32:18
|
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 |
From: Michael M. <ma...@ya...> - 2004-08-22 06:52:55
|
> 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 |
From: Steffen H. <ste...@gm...> - 2004-08-22 09:39:34
|
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) |
From: Michel <mi...@da...> - 2004-08-22 17:52:25
|
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 1024= x768 > > it usually froze. glxgears gave this one 518.6 fps. >=20 > 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? --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Steffen H. <ste...@gm...> - 2004-08-22 20:19:25
|
You're right. It's a 8mb mobility M3 in a dell latitude c600. Sorry, not my notebook ;-) |
From: Felix <fx...@gm...> - 2004-08-22 09:57:17
|
On Sun, 22 Aug 2004 01:16:18 -0500 John Lightsey <dri...@ni...> wrote: >=20 > Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears ga= ve > 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=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: John L. <dri...@ni...> - 2004-08-22 10:34:03
|
On Sunday 22 August 2004 04:59, Felix K=FChling wrote: > On Sun, 22 Aug 2004 01:16:18 -0500 > > John Lightsey <dri...@ni...> 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=20 helps. The crash with the IBM SR9 happens while the checkpoint demo is=20 loading. Some kind of texture loading problem perhaps? John |
From: Simon 'c. S. <cor...@fs...> - 2004-08-22 09:58:42
Attachments:
PGP.sig
|
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 |
From: John L. <dri...@ni...> - 2004-08-22 10:21:57
|
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 |
From: Alan C. <al...@lx...> - 2004-08-22 11:41:43
|
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 ? |
From: John L. <dri...@ni...> - 2004-08-22 18:01:54
|
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 |
From: Dave A. <ai...@li...> - 2004-08-22 12:11:37
|
> > 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 |
From: Alan C. <al...@lx...> - 2004-08-22 13:10:13
|
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. |
From: Dave A. <ai...@li...> - 2004-08-22 23:17:30
|
> > 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 |
From: Michel <mi...@da...> - 2004-08-22 17:53:35
|
On Sun, 2004-08-22 at 01:16 -0500, John Lightsey wrote: > This is my third attempt sending this email. If sourceforge decides to l= et=20 > 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. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: John L. <dri...@ni...> - 2004-08-22 20:42:18
|
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 |
From: Alan C. <al...@lx...> - 2004-08-22 21:44:25
|
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 |