Quake III performance across a range of SGI's

kaigan

Member
Jul 1, 2019
35
29
8
I have some more results to add to the list:

Onyx4 Octo R16K @ 1.0 GHz, Voyager: 1260 frames 35.6 seconds 35.4 fps 9.0/28.2/52.0/7.0 ms (fast, but not IR4 fast!)
Tezro Rackmount Quad R16K @ 800 MHz, V12: 1260 frames 53.4 seconds 23.6 fps 19.0/42.4/85.0/8.6 ms (pretty close but slightly slower than a quad 1.0 GHz, whch makes sense)

I also tested my Fuel (500 MHz, V10), and got a score of around 9 6 fps, which I was a little surprised by. I guess the texture memory really makes a difference? I'll redo the run and check the exact stats. I thought I got a picture taken on my phone but it seems to have gone missing.

EDIT: So, here are the numbers for the Fuel R14K @ 500 MHz, V10: 1260 frames 199.7 seconds 6.3 fps 31.0/158.5/285.0/64.7 ms
 
Last edited:

kaigan

Member
Jul 1, 2019
35
29
8
I've installed my V8 into my Octane, so I'll have results for you on that soon, too. I'll also put an SE in there and see how it compares. I'll be curious to see it against the MXI.

I'd also be very curious to see if any other V10 (or V6) owners get similar results in Quake with the low frame rates. It seems like with those settings, it would have occasional bits of speed followed by significant slowdowns. If I cut the settings to low, it performed at a respectable rate in the low 20s. I wonder if the textures are just large enough that it had to keep swapping things in and out of RAM, leading to the issue. Not sure, but more data will help! :)
 
Last edited:
  • Like
Reactions: Irinikus

kaigan

Member
Jul 1, 2019
35
29
8
Octane2 Single R12K @ 400 MHz, V8: 1260 frames 70.1 seconds 18.0 fps 24.0/55.6/91.0/12.1 ms

SE results soon!
 
  • Like
Reactions: Elf

kaigan

Member
Jul 1, 2019
35
29
8
Here's the SE (with TRAM, of course, on max settings): Octane Single R12K @ 400 MHz, SE+TRAM: 1260 frames 299.6 seconds 4.2 fps 98.0/237/8/538.0/44.4 ms

EDIT: I'm really impressed with how big of a leap the Odyssey graphics is over the older Impact graphics. I'd be very curious to see how an Indigo2 with a suitable configuration would fare. Sadly, mine is pre-Impact, so no textures. Kinda makes it unsuitable for the test. :D
 
Last edited:

stormy

Active member
Jun 23, 2019
133
55
28
I don't see the screen resolution used in this chart? Surely that is even more important than 'game settings max' when it comes to the results obtained... Also what version of Q3? There are a few dotted around the net, the original 1.17 version released by SGI (the ver I think we *should* be using for the benchmark, IMO we shouldn't be using any of the nekoware versions based in ioQ3, reason being that Nekoware uses dependancies, dependancies that can change depending on Nekoware versions installed which can effect performance results. The SGI version is self contained and accesses native SGI protocols)
 
Last edited:

kaigan

Member
Jul 1, 2019
35
29
8
Irinikus put a screenshot of his settings in the original post, including a resolution of 1280x1024. All of my results used those settings. I used ioQuake3 from the Nekoware repository available through the IRIX Network, as it's fairly convenient to install and run. That said, I'd be happy to re-run any of my benchmarks with another version to see how they compare.
 

stormy

Active member
Jun 23, 2019
133
55
28
Ok - I guess these settings need to be in the graph then :) A bit like a 90's PC magazine review, they always listed game version & resolution in the graphs. I do think my concerns about the game version are valid. There are two versions in nekoware, current and beta. Then the original from ID/SGI v1.17.

You can get the original SGI 1.17 version here:
 

kaigan

Member
Jul 1, 2019
35
29
8
The versioning on my side has been Nekoware Current in all cases. I'll grab that original SGI version and run a couple of tests to see if there's a statistically-relevant difference in FPS.
 

drmadison

Member
Jun 30, 2020
33
20
8
Some people in discord showed some surprise at how "poorly" the SGIs of that era did and I clarified some of the reason there, but figured I'd also call it out here as well.

First: note the resolution. This is a game that came out in 1999. Most PCs of the time struggled to play the game at 20fps, and those that did were typically playing at 640x480. This is important to note, as the FPS numbers above are all taken at 1280x1024, over 4x the pixels. Today anything under 100fps is frowned upon, but in the late 90s, if your game ran at >15fps it was called "smooth" - my how times have changed!

Second: lightmapping puts SGIs at a major disadvantage over every graphics card from the RivaTNT (released in 1998) on. None of the SGI graphics architectures supported multitexturing. This means another multiple of work that the SGI is having to do over a PC card for a similar effect.

This is super simplified, but...
For a graphics card rendering a poly that supports multitexturing, following the transform phase, it involved sampling the albedo/base texture, sampling the lightmap texture, blending those values and drawing to the screen. We'll assume bilinear filtering here as I don't have a machine that runs Q3A up right now and can't remember if it does trilinear at the max settings. That means 1 z-buffer read, 4 samples (reads) from base texture, 4 samples from the lightmap texture, some math, and a single write to the framebuffer, and a write to the z-buffer.

For a card that DOESN'T support multitexturing, you get a second pass over the entire scene. This means twice as much geometry work as the hardware wasn't caching transform data in those days. But ignoring the geometry load, let's focus on fillrate / pixel pushing issues. First layer is a z-buffer read, read 4 samples from the base texture, 1 z-buffer write, and 1 framebuffer write. Then for the second (lightmap) pass, you have 1 z-buffer read, read 4 samples from the lightmap texture, 1 framebuffer read, a blend operation, and 1 framebuffer write.

Or in short..
PC has 1 z-buffer read, 1 z-buffer write, 8 texture reads, 1 framebuffer write
SGI has 2 z-buffer reads, 1 z-buffer write, 8 texture reads, 1 framebuffer read, 2 framebuffer writes

So not only is it doing double the geometry work, but also twice the z-buffer reads, twice the framebuffer writes, and additional framebuffer reads that the PC isn't doing, all at over 4x the pixel count.

Oh, and also note that PC cards of the time focused on performance not accuracy, and used a lot of cheats along the way typically, while SGI being the standard for graphics aimed at reliability and accuracy in the produced image.

Now as for why SGI didn't support multitexturing? My guess is it wasn't needed by their actual markets. CAD doesn't need texturing at all typically. 3D modeling for games / movies would use just a single texture as all the heavy effects / lighting was done at render time not at modeling time. And realtime simulations were focused on pushing more pixels, not necessarily more detail in each of the pixels.
 

kaigan

Member
Jul 1, 2019
35
29
8
The versioning on my side has been Nekoware Current in all cases. I'll grab that original SGI version and run a couple of tests to see if there's a statistically-relevant difference in FPS.
The SGI version of Quake 3 crashes on my Octane after displaying the intro cutscene, so I won't be able to use it for a benchmark comparison for those results unless I can get it fixed. I'll try it on another system as well to see if it crashes there.
 

stormy

Active member
Jun 23, 2019
133
55
28
The SGI version of Quake 3 crashes on my Octane after displaying the intro cutscene, so I won't be able to use it for a benchmark comparison for those results unless I can get it fixed. I'll try it on another system as well to see if it crashes there.
Don't worry - I just checked out the SGI version and it has issues, ie; it cannot do full-screen. It also uses the old demo001 timedemo and not the later 'four' demo. So I guess the neko version is best for benchmarks... I just wish we could get a Sgug version one day rather than requiring neko dependancies.
 

kaigan

Member
Jul 1, 2019
35
29
8
As an interesting point of comparison, I recently picked up a Blue and White G3 Power Macintosh, 400 MHz, with a Radeon 7000. Its Quake III results at the same settings as the SGI tests were: 1260 frames, 77.3 seconds, 16.3 fps. I don't imagine the stock Rage 128 these normally came with would have done quite as well.

I plan to try the test out on my recently set up 1.0 GHz Pentium III test bench setup at some point as well. It has a GeForce FX 5500 in it, so that should be an interesting latter-era comparison as well, with all the caveats that drmadison mentioned above well noted, of course. :D
 

Jan

Member
May 26, 2022
47
27
18
Germany
That’s very interesting to see how these machines compare to each other.
So I can forget about Q3 on the O2 :ROFLMAO:.

My own fist real 3D experience was on a Power Mac 7600/PPC604@132 MHz on a 3Dfx Voodo 1 with Unreal running on Glide - that looked nice for that time period. The next thing was on W98 with a PII/400 and a Riva TNT - that was way better and obviously the slowly beginning of the end of SGI :cry:.
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu