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 I used to run the test from the Quake console was:
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 Indy 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 | 124.1 108.8 32.5 21.5 Fuel V12 | | R12000/400 8MB | 111.9 85.4 Onyx2 IR2E 2RM | | R16000/700 4MB | 94.9 51.3 23.8 15.2 Fuel V10 | | R10000/250 4MB | 64.2 25.2 11.4 7.5 Onyx2 IR2E 4RM | | R10000/195 | 35.2 14.3 6.8 4.4 Indigo2 Solid | | R10000/195 | 33.9 13.7 6.5 4.4 Indigo2 Max/4 | | R10000/175 | 34.4 13.4 6.2 4.2 Indigo2 Max/4 | | R10000/175 | 33.2 13.3 6.3 4.1 Indigo2 High/4 | | R10000/175 | 33.1 13.1 6.3 4.1 Indigo2 Solid | | R5000SC/200 O2 | 22.9 8.8 4.0 2.4 1MB L2 | | R4400SC/250 2MB | 23.7 8.5 4.0 2.4 (500x375=12.8) Indigo2 XL | | R4400SC/250 2MB | 21.7 8.3 3.8 2.5 Indigo2 High/4 | | R5000SC/180 O2 | 22.0 8.0 3.7 2.4 512K L2 | | R5000SC/180 | 18.4 7.6 3.6 2.4 Indy 24bit XL | | R4400SC/250 | 17.0 7.4 3.4 2.2 Indigo2 Extreme | | R4400SC/200 | 18.7 7.0 3.2 2.1 Indy 24bit XL | | R5000PC/150 | 14.8 6.3 3.1 2.1 Indy 24bit XL | | R4400SC/200 | 15.4 5.9 (500x375=8.7) Indigo2 Elan | | R4400SC/150 | 14.9 5.5 2.5 1.7 Indy 24bit XL | | R4600SC/133 | 14.3 5.5 2.5 1.6 Indy 24bit XL | | R4600PC/133 | 12.5 5.0 2.4 1.6 Indy 24bit XL | | R4600PC/100 | 10.6 4.2 1.9 1.3 Indy 24bit XL | |
For low-end systems, the CPU is important at low resolutions, but as the resolution increases pixel fill becomes dominant, which is why XL systems do comparatively well, eg. R5000SC/180 Indy XL beating R4K/250 Indigo2 Extreme.
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 in all but the silly resolution of 3840x1024. 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: Quake itself is not a particularly efficient graphics engine (same for Quake2), eg. a monster is always the same number of triangles no matter how far away it is. Plus, the SGI Quake 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 Quake 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. Ah well, such is the nature of game ports. :) There was a custom Quake engine written for Onyx2 InfiniteReality, but it wasn't released. Apparently it had all sorts of extra features such as shadows and fog.
Here are the results, shown in order of 1280x1024 speed, with detail texture turned on (figures in round brackets are the results with Detail Texture turned off - an option not available on O2). Turning off Detail Texture can give a good speedup, and in reality the gameplay is so fast that one doesn't really notice the difference in the visuals. Results for other miscellaneous resolutions are given in square brackets at the far right of the table.
| Screen Res -> | 640x480 | 1024x768 | 1280x1024 | ------------------------------------------------------------------------- | R10000/250 4MB L2 | 60.0 (60.0) 60.0 (60.0) 60.0 (60.0) [3840x1024=29.3] Onyx2 IR2E 4RM64 | | R4400SC/250 2MB | 27.3 (32.2) 16.6 (23.2) 11.5 (16.2) Indigo2 Max/4 | | R10K/195 1MB L2 | 28.4 (35.2) 16.3 (23.4) 11.3 (16.1) Indigo2 Max/4 | | R10K/175 1MB L2 | 27.5 (32.4) 16.2 (22.4) 11.0 (15.7) Indigo2 Max/4 | | R7000SC/600 O2 | 25.8 (N/A) 14.8 (N/A) 9.5 (N/A) 256K/1MB L2/L3 | | R5000SC/200 O2 | ? (N/A) 12.7 (N/A) 8.5 (N/A) 1MB L2 | | R5000SC/180 O2 | 21.1 (N/A) 12.7 (N/A) 8.3 (N/A) 512K L2 | | R4400SC/250 2MB L2 | 19.7 (?) 10.0 (?) 5.9 (?) Indigo2 High/4 | | R10K/175 1MB L2 | 19.7 (25.4) 9.5 (13.5) 5.6 (7.3) Indigo2 High/4 | | R10K/195 1MB L2 | 19.1 (24.4) 9.4 (13.5) 5.6 (7.3) Indigo2 High/4 | |
O2 does well because of its architecture, ie. not having to move texture data around. However, id Software told me that, because Quake was written for PC designs, the SGI version of Quake has not been written to particularly take advantage of O2's abilities, ie. as stated earlier it's really just a straight port. O2 could do better if Quake was written native rather than ported, and since the main CPU does geometry and lighting on O2, something like an R12K/400 O2 should give significantly better results than R5K/200 O2.
R4K/250 HighIMPACT is close to O2 at low-res. Presumably the standard system design of Indigo2 somewhat offsets HighIMPACT's theoretically faster pixel fill. As the resolution increases, one might expect HighIMPACT to overtake O2 (better pixel fill), but in fact it doesn't - again, O2's architecture shines through. It's also interesting that HighIMPACT results are better with an R4K/250, probably because the larger L2 and higher clock allow loads and stores to the graphics engine to happen faster. The same seems to happen for MaxIMPACT results, though the differences are less. Still, the data show once again that a 2nd-hand R4K/250 MaxIMPACT is a good starter system for 3D graphics, though these days a simple Octane2 VPro is a better choice.
Note that the hardware-rendered results table above does not include any data for VPro systems because Quake1 does not run properly on VPro systems with hardware rendering. Something about the way transparency or related effects makes the performance on a VPro system go very slow whenever a flash effect occurs. For a performance comparison that includes VPro systems, see the Quake2 results.
Your feedback is welcome!