[Irinikus]

Hi John,

Thanks for doing all the testing!!!

Nick

[Donjon]

Here are the results from the Octane2 with the same settings:

I'm not sure everything is with the same settings; in particular, I think the IR4 has different graphics settings. The screenshots of Q3DM1 have really flat lighting, which looks to me like Quake 3's vertex lighting mode.

The screenshots for everything else look like they're using the much better looking but typically slower (it's an additional texture on all map surfaces) lightmap mode.

[Irinikus]

The pictures that I showed of the IR4 system running was not the test. The test ran at a lower frame rate and looked much better! The IR4 system performs better and produces a much better looking output than the Odyssey systems do! I can assure you that the same settings were used for all the tests I conducted!

[Irinikus]

Here's the latest chart including the performance of my latest SGI:

[jan-jaap]

I tried to get the PROM source code released (the sysadmin of sgi.com helped apply some pressure aswell), so that the dual-core R9K/1GHz would become viable (Joe Page had talked to IBM about using a 50% faster 16MB L2), but alas no joy, management said a flat no.

If you go to vetusware.com, and navigate to os -> unix, there's a tarball of IRIX 6.5.7 source and more:

Code:

Source code for SGI IRIX 6.5.7. Contain source code for IP19, IP20, IP21, IP22, IP25, IP26, IP27, IP28, IP30, IP32 PROM, Integrated Diagnostic Environment (IDE) and subset of IRIX source code. No build environment and graphics stacks (X11, IRIS GL, OpenGL, GPU driver) included.

The IP32 PROM code seems to be rev 4.13, which may be from before the RM7000. Then again, to extract RM7000 cache setup routines from a later PROM and merge them back into this one shouldn't be the end of the world.

Happy hacking!

[stormy]

I have a funny feeling that people aren't enabling "setenv DECOUPLE_SWAPBUF y" correctly. Either in the .cshrc or .bashrc (I think the command might be slightly different in a bashrc?) They also could be using tcsh.

[Irinikus]

In the tests that I’ve run, the results haven’t been capped at either 30 or 60 FPS, so the performance reflected should be the correct.

The IR4 setup achieves more than 60 FPS when running the standard levels. (The first level) The time demo seems to be built the stress the graphics systems more, hence the lower frame rates reflected in the results.

Last night I ran the same test with the same settings on my Alienware equipped with a Quadro Plex 1000 model IV, and it achieved a result of 110.3 FPS. (This system was released in 2006!)

[stormy]

In the tests that I’ve run, the results haven’t been capped at either 30 or 60 FPS, so the performance reflected should be the correct.

The IR4 setup achieves more than 60 FPS when running the standard levels. (The first level) The time demo seems to be built the stress the graphics systems more, hence the lower frame rates reflected in the results.

Last night I ran the same test with the same settings on my Alienware equipped with a Quadro Plex 1000 model IV, and it achieved a result of 110.3 FPS. (This system was released in 2006!)

It doesn't really work the way that you are thinking. By default IRIX synchronises the FPS to half of your monitor refresh rate (In my experience) So you will find when running a 60hz monitor, when the scene is extremely simple (ie; load the map test_bigbox which places you inside a simple box, just type test_bigbox in the quake 3 console) You will see 30fps (as long as you have a fairly decent system) If you are running 120hz monitor, you should see 60fps (again, with a decent system)

A quirk of this is that if the system cannot maintain 60fps, it will drop down to 30fps. If it cannot maintain 30fps, it drops to 15fps.

for the timedemo (FYI the quake engine doesn't enable/disable vsync or anything on the OS side) take for instance a system running a 60hz monitor. This means the maximum FPS it can ever achieve is 30fps. So during the 'demo playback' it will fluctuate between 30fps, 15fps and 7fps. Your result will be the mean average of those.

If you correctly disable swap-buffering, it removes this monitor-dependant-hardlock. So if your machine cannot do 60fps, but can manage 47fps, it will output 47fps (and everything inbetween)

Hope this makes sense.

[mapesdhs]

It's worth mentioning that, unsurprisingly, the various Quake ports for SGIs are not remotely optimised for SGI gfx tech. They are, "quick and dirty ports". Who knows what natively written code might be capable of, properly exploiting what each different system can do, baring in mind how different they are (O2 vs. MGRAS vs. VPro vs. REx vs. IRx). Some systems have certain inherant limits, such as texture fill rates on O2, but certain aspects could be better optimised nonetheless, or unique features added (fade LOD on RE/IR would be cool). Still, the results are interesting, but it's hard to know how useful they are. In other words, performance results for Quake3 on SGIs may only tell us how Quake3 as it's been written behaves on SGIs, it probably shouldn't be used as a guide for anything else. This for example was the unfortunate down side of sending an O2 parts kit to Gamers Nexus for assembly review (just for fun really); despite my explaining beforehand about O2's market focus and unique arch, they focused way too much on running Quake1, also missing entirely that the resolution and quality settings they were using were ludicrously high compared to consumer gaming hw of the day (the Indigo2 parts kit review was better).

Alas so far I've not had time to do any Quake3 performance testing, but then it's less applicable than Quake2.

Ian.

[stormy]

It's worth mentioning that, unsurprisingly, the various Quake ports for SGIs are not remotely optimised for SGI gfx tech. They are, "quick and dirty ports". Who knows what natively written code might be capable of, properly exploiting what each different system can do, baring in mind how different they are (O2 vs. MGRAS vs. VPro vs. REx vs. IRx). Some systems have certain inherant limits, such as texture fill rates on O2, but certain aspects could be better optimised nonetheless, or unique features added (fade LOD on RE/IR would be cool). Still, the results are interesting, but it's hard to know how useful they are. In other words, performance results for Quake3 on SGIs may only tell us how Quake3 as it's been written behaves on SGIs, it probably shouldn't be used as a guide for anything else. This for example was the unfortunate down side of sending an O2 parts kit to Gamers Nexus for assembly review (just for fun really); despite my explaining beforehand about O2's market focus and unique arch, they focused way too much on running Quake1, also missing entirely that the resolution and quality settings they were using were ludicrously high compared to consumer gaming hw of the day (the Indigo2 parts kit review was better).

Alas so far I've not had time to do any Quake3 performance testing, but then it's less applicable than Quake2.

Ian.

Just to add to your information Ian, in regards to Quake 3 - as you said it is a 'quick and dirty port' with zero optimisation. There are two parts to optimisation for the game Quake 3 (which was written differently to Quake2) Firstly it is the QVM, the Quake Virtual Machine, which does all the background tasks and game logic. This QVM can use a native MIPS compiled version, but on the versions we have it hasn't been compiled and it 'drops back' to emulation mode. So that breaks SMP (multi processing) which is usually enabled with r_smp 1 in the config file. So we don't have any SMP available.

Then we have renderer specific optimisations, as you mentioned there aren't any. The Vpro has a terrible bug with the Quake 3 Skyboxes which absolutely *tanks* the fps to single digits. So to be fair in benchmarking, we really should be using 'r_fastsky 1' to avoid the bug in Odyssey hardware. Because benchmarking with that bug is clearly unfair for the hardware. I don't know if the bug is Odyssey driver related, or Quake engine related.

I hope to try and compile a more native and enhanced version of Quake 3, with the help of the Sgug software compiler environment & the help of the guys over on the ioQuake3 forums (They are always eager to help) But I just haven't had the time to dedicate to doing this yet.

For your information, here is a great explanation of how the Quake 3 engine works:
https://fabiensanglard.net/quake3/qvm.php