[mapesdhs]

Can you monitor CPU usage while the test is running? What's it doing? Just one CPU active? If so, to what degree?

Ian.

[Irinikus]

I'll have to run it in a windowed mode to do that and the colour depth in the settings will change to default as a result.

I'll do this for you on the Tezro. (I've just fired it up for this purpose!!!!)

As far as I know it's not multithreaded. (I have tried to get it running in a multithreaded mode in the past without success)

---

Here are a few screenshots:









It's not making use of a full thread, so I doubt that multithreading would help!

[Irinikus]

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



Here's the Octane2's hinv:

---

Here are the Indigo2 Max IMPACT's results:



Here's the Indigo2's hinv:

---

So the results are the following: (max settings@1280x1024)



I really can't believe that the Indigo2 Max IMPACT outperforms the top spec O2!!!!! (The results speak for themselves!)

[mapesdhs]

I really can't believe that the Indigo2 Max IMPACT outperforms the top spec O2!!!!! (The results speak for themselves!)

I'm surprised you're surprised; as you've shown earlier the game on an SGI does not appear to be CPU-bound, in which case it's more likely to be fill rate limited, probably texture fill, in which case O2 is severely underpowered in a manner not helped by a faster CPU (tex fill rateof 33M/sec max, vs. 119M/sec for Max; text tri rate of 400K/sec for O2 vs. 1.6M/sec for Max). See:

http://www.sgidepot.co.uk/gfxtables.html

It's possible for O2 to match HighIMPACT because its Gouraud rate is similar, but texture mapping was never its forte. I wonder though whether the TRAM option would speed up the Max config somewhat due to the way textures in a 1MB config are stored.

That btw is what I meant about O2+ being a farce. And note a VW320 with a PIII/500 has almost identical base performance to MaxIMPACT, but with the arch advantages of O2, hence my comment about how much more impressive O2+ would have been if it had used Cobalt instead of purple plastic. Whoever was responsible for O2+ presumably came from the bling school of performance enhancements:





Ian.

[Irinikus]

Thanks for the good info as always!!!

I suppose it's easy for people to think that the O2 was the follow on from the Indigo2, when in fact the Octane was!

[mapesdhs]

Exactly, something which burned ILM for example. They were sold O2s as upgrades over HighIMPACT Indigo2s, a disaster. They were not best pleased. Hence why the reseller model I thought would ultimately be the death of SGI no matter what they did, too many resellers were ripping people and companies off with secretive/manipulative pricing, and selling inappropriate systems just to get the sale.

O2 was excellent for those tasks that were a natural match for the architecture. People forget now but after launch it held the Challice/Shake records for ages, and a surgeon in South Africa told me that for prepping CRT scan summary reports it cut the prep time from an hour to 5 or 10 mins, it was so much faster than previous systems for volumetric imaging, and much cheaper. Complex imaging & video, VRML, textile manufacturing, medical imaging and numerous other tasks, it was great for that. I once sold five O2s to a hospital in NYC. It really did deserve a proper followon with the same arch. People at ILM who followed Nekochan chatter (but couldn't post) were drooling over the idea of an R9K/1GHz 16MB, doing compositing in L2. With its actual specs though, O2 didn't have very good general performance, the CPU/RAM speed is pretty low (try running STREAM on O2, compare it to your Octane2 and Tezro, and see what happens on O2 as you drop the display from 1280x1024 32/32 down to 640x480 16/16, it's amusing). Hard to say whether SGI made a mistake not releasing a more general low end system as SUN typically did, but then SUN did some odd things too at times.

Btw, SGI people told me they'd never intended R10K to be used in O2, but it was so much quicker than R5K that customers just wanted it anyway, but that of course was more expensive, and presumably drew resources away from developing the R5K side. Worse though was having an R5000PC option and selling systems with only 64MB RAM, that should never have been done.

I really like the O2 (infact I've just downgraded from a Tezro to an O2 for my main SGI, fitted a dual-channel Adaptec with case mod for two extra external SCSI ports), but the O2+ was an embarassment. 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.

Hmm, I wonder how MXI and MXE would handle your test? Especially MXI. Same tech in theory, though the command ASIC is faster IIRC. Curious as to the gains from the better bandwidth & latency, if any.

Ian.

[Raion]

I think at this point we could have some of the N64 decompilation guys decompile the entire O2 PROM if someone has a PROM file. It will take some pressure and possibly a crowd fund of compensation for them to do it, but I'm interested in seeing if we can get more of our hardware PROMs dumped so we can get a better picture of the machines we have.

[mapesdhs]

That would be cool! I seem to recall Joe thought it wasn't practical, but who knows, it's been a long time since then.

Ian.

[rbz]

Hmm, I wonder how MXI and MXE would handle your test? Especially MXI. Same tech in theory, though the command ASIC is faster IIRC. Curious as to the gains from the better bandwidth & latency, if any.

I wouldn't mind trying to run this on my Octane w/ MXE, is the Q3 being used this one? http://nekofiles.irixnet.org/Games/Quake/sgiquake3/

[Irinikus]

That’s the one. If you do run it, make sure to use the settings that I did, to keep all things equal.

Also post your machine’s hinv.