Note that the software results table includes data for systems that one would not actually use in software mode, eg. O2. However, one can also use the table as a CPU benchmark, and it's useful to see how much faster the hardware results are compared to software at the same resolution on a particular system.
Software-rendered gives lower visual quality than hardware-rendered. Software mode results in pixelisation, limited colour quality, etc.
If someone has a system such as an R4K/200 SolidIMPACT Indigo2, it's definitely worth upgrading to HighIMPACT or better.
The command sequence I used to run the test from the Quake2 console was:
timedemo 1 map demo1.dm2
Here are the results given in order of 640x480 speed. In the case of a tie, the order is via the next higher speed, and so on. Note that if you're using a system which is too slow at 640x480, try running at 500x375 instead; the resolution reduction is enough to give a good speedup, but the window isn't so small as to be unwatchable. Works quite well on XL systems. Also remember to exploit any lower monitor resolutions that may be available, eg. 1024x768.
| Screen Res -> | 320x240 | 640x480 | 1024x768 | 1280x1024 | ---------------------------------------------------------------- | R16000/900 8MB | 122.2 60.3 30.7 20.6 Fuel V12 | | R12000/400 8MB | 69.7 31.4 15.6 10.8 Onyx2 IR2E 2RM | | R12000/400 2MB | 55.5 26.4 13.6 9.0 Octane2 V6 | | R12000/300 2MB | 45.0 20.4 10.4 ? Octane MXI | | R10000/250 4MB | 39.1 16.8 9.0 6.2 Onyx2 IR2E 4RM | | R10K/195 1MB | 24.4 11.0 5.6 3.7 Indigo2 High/4 | | R10K/195 1MB | 23.4 10.4 5.3 3.5 Indigo2 Max/4 | | R10K/175 1MB | 22.9 10.3 5.3 3.5 Indigo2 High/4 | | R10K/175 1MB | 21.6 9.7 5.0 3.3 Indigo2 Max/4 | | R10K/175 1MB | 19.6 9.0 4.6 3.0 Indigo2 Solid | | R4400SC/250 2MB | 15.4 6.8 3.4 2.2 Indigo2 XL | | O2 R5K/200 1MB | 15.3 6.7 3.4 2.2 | | R4K/250 | 14.1 6.6 3.2 2.1 Indigo2 High/4 | | R4K/250 | 12.5 6.0 3.0 2.0 Indigo2 Solid | | R4K/200 | 10.3 4.7 [512x384=6.2] Indigo2 Elan | |
I've not tested many lower-spec systems yet.
NOTE: it appears that this test runs double-buffered on SGIs, which is a pity because that means the fps results can never be higher than the monitor refresh rate; thus, the Onyx2 I tested just maxes out at 60Hz (I wasn't able to run it at 3840x1024 for reasons unknown). Does anyone know how to run the Quake benchmarks on SGIs in single-buffered mode? By contrast, PCs tend to run the tests single-buffered, resulting in apparently higher numbers. For this reason, do not use results that are obviously maxing out the monitor rate to make comparisons with PCs. In general, any result near to or more than half the monitor refresh should not be compared to a PC.
Another difference is visual quality. SGI's hardware OpenGL implementation is much better than most PC cards, resulting in better quality textures, nicer filtering, etc. Additional special effects are also available on some systems.
A final warning about using this as an SGI vs. non-SGI benchmark: the SGI Quake2 port was not a custom version written just for SGIs and thus able to take advantage of any special features and abilities - it was just a straight port. If one wrote a Quake2 engine from scratch for a particular SGI system, one could definitely create a graphics engine that would give much better fps results than the data shown here.
Here are the results, shown in order of 1280x1024 speed (the two Onyx2 entries will likely swap round once I can run the R10K config in single buffered mode); if there's a tie then the ordering is next by 1024x768. Note that unlike the Quake1 results, SGI Quake2 doesn't seem to have any Detail Texture option so there is just one set of results.
| Screen Res -> | 640x480 | 1024x768 | 1280x1024 | 1600x1200 | ---------------------------------------------------------------------- | R10000/250 4MB L2 | 60.0 60.0 60.0 (run double-buffered) Onyx2 IR2E 4RM64 | | R12000/400 8MB L2 | 182.8 91.1 58.3 61.1 Onyx2 IR2E 2RM64 | | R16000/900 8MB L2 | 147.0 75.4 49.8 36.7 Fuel V12 | | R12K/400 2MB L2 | 72.8 46.0 40.5 Octane V12 | | R12K/400 2MB L2 | 61.6 37.0 28.2 23.0 Octane2 V6 | | 2x R14K/600 2MB L2 | 47.4 26.3 17.9 11.6 Octane MXE | | 2x R12K/400 2MB L2 | 45.4 25.9 17.7 10.6 Octane MXE | | R12K/400 2MB L2 | 44.5 25.8 17.7 11.5 Octane MXE | | R12K/300 2MB L2 | 42.1 25.0 17.4 11.4 Octane MXE | | R12K/270 2MB L2 | 40.7 24.6 17.2 11.4 Octane MXE | | R10K/250 2MB L2 | 40.0 24.3 17.1 11.3 Octane MXE | | R10K/250 1MB L2 | 38.8 23.9 16.9 11.2 Octane MXE | | R12K/300 2MB L2 | 31.2 19.9 14.3 Octane MXI | | R10K/195 1MB L2 | 25.8 17.4 13.1 Indigo2 Max/4 | | R10K/175 1MB L2 | 25.3 17.3 13.0 Indigo2 Max/4 | | R10K/195 1MB L2 | 18.8 11.2 7.9 Indigo2 High/4 | | R10K/195 1MB L2 | 17.9 10.9 7.8 Indigo2 High/1 | | O2 R7000/600 | 20.5 11.8 7.6 256K/1MB L2/L3 | | O2 R5K/200 1MB L2 | 14.3 9.4 6.4 | | R10K/175 1MB L2 | 16.3 9.2 6.3 Indigo2 High/4 | | R4K/250 2MB L2 | 14.6 8.7 6.1 Indigo2 High/4 | |
O2 does well because of its architecture, ie. not having to move texture data around, though compared to Quake1 O2 doesn't compare so well to faster systems such as MaxIMPACT despite O2's architecture, probably because pixel-fill is more critical for Quake2 compared to Quake1. See the notes at the end of the Quake1 Benchmark page for more details.
NOTE: The Fuel/900 data was done single-buffered; yes, I finally found out how to do this! Namely via this setting:
setenv DECOUPLE_SWAPBUF y
The results clearly show how much a double-buffered test can make it look like a gfx system is slower than it really is. Presumably the Onyx2 results would be way higher if run single-buffered. Over time I will update these results with tests done in single-buffer mode.
Your feedback is welcome!