O2/Indigo2 Comparison

I first wrote this page at a time when Octane had just been released as the new mid-range to replace Indigo2, initially using the same CPU and graphics technologies as Indigo2 but offering massive improvements over Indigo2 when one is working with complex data sets and/or memory-intensive applications, much better response and feel, more advanced peripheral options and support technologies such as newer SCSI standards, Ethernet, PCI support, etc. I've rewritten this page because much of the information originally given here can now be found in the I2 Buyers' Guide in a much more concise form.

The information on this page is intented to be relevant to people who are either interested in Indigo2, or perhaps considering an O2 instead of upgrading from Indigo2 Extreme to Indigo2 SolidIMPACT or Octane. Some may have no idea what the options are at all (perhaps they are more familiar with non-SGI systems). The information given here attempts to cover a few of the questions people may have about the new systems and includes a summary of raw graphical performance figures. SGI's site has largely removed information on older systems such as Indigo2, so I have collected some practical comparison information and written a detailed description of Indigo2, namely the 2nd-hand Indigo2 Buyers' Guide. Please read the guide before consulting this page.

Although Octane was supposed to be the mid-range replacement, some people were under the impression that O2 was supposed to be an upgrade from Indigo2, which caused some confusion. O2 was actually supposed to replace Indy, but confusion was perhaps not surprising since its abilities also exceeded Indigo2 Extreme in many ways. O2 is certainly better than Indigo2 in some respects, but not others. It depends on the intended task. Thus, for someone wishing to upgrade beyond an R4K Indigo2 Extreme (the older generation of Indigo2s), it may not be as simple as just choosing Octane because it's supposed to be the mid-range replacement, or choosing O2 because O2 has hardware texture mapping while Extreme doesn't. Other factors may mean O2 is a better choice, but not all the time. The Indigo2 buyers' guide deals with some of the issues, but this page will delve into them in more detail.

Here is a reminder of the old vs. new Indigo2 technologies (this is a copy of Fig 6 from the I2 Buyers' Guide):

           Older (Earlier)             Newer (Later)

CPUs:      R4000SC 100MHz (1MB L2)     R8000 75MHz (2MB L2)
           R4600SC 133MHz (512K L2)    R10000 175MHz (1MB L2)
           R4400SC 100MHz (1MB L2)     R10000 195MHz (1MB L2)
           R4400SC 150MHz (1MB L2)
           R4400SC 175MHz (1MB L2)
           R4400SC 200MHz (1MB/2MB)      
           R4400SC 250MHz (2MB L2)             

Graphics:  XL24                        SolidIMPACT
           GR2-XZ                      HighIMPACT
           GR3-Elan                    MaxIMPACT
           Extreme

Video:     Indigo2Video                Indigo2Video-for-IMPACT
           Cosmo Compress              IMPACT Compression
           Galileo Video               IMPACT Video
                                       IMPACT Colour Space daughtercard
                                       IMPACT Channel Option

Fig 6: Older (Earlier) vs. Newer (Later) I2 Components

• "What are the differences between the various graphics options for Indigo2?"

Please see section 3 of the I2 Buyers Guide for a detailed description of the various options and comparison between them. Note my page comparing the Viewperf numbers for IMPACT vs. Compaq Gloria-L - these clearly show how SolidIMPACT is not appropriate for textured tasks, while at the same time showing how Solid and HighIMPACT are identical for any non-textured task.

NB: if you hear the description, "Killer IMPACT", this refers to a Solid IMPACT system which has a 175MHz R10000 instead of a 195MHz CPU, ie. Killer IMPACT was a marketing term born out of the lower cost CPU.

• "What is best for me? Solid IMPACT or Killer IMPACT? High or Max?"

Most of these questions are answered in the Buyers' Guide. However, to emphasise the main differences once more: if you're doing textured work, then you need High or Max IMPACT. If you don't need textures, then Solid is fine, but Max does have 2X faster shaded/wireframe speed than Solid so Max may be better even if you don't need textures - clearly, having the option of Max's speed without the extra cost of texture hardware would have been nice, but this gap wasn't filled until Octane's SSI gfx option was released (essentially a Max set with no texture). If you do use textures, High will give a huge speed increase over Extreme's software-rendered textures and you may be happy with High's speed; however, Max is 2X faster if extra speed is required, but remember Max takes up more space in the chassis. Lastly, there's colour quality. If you want better quality visuals, such as full 32bit textures, etc., then you must have the TRAM option to give High or Max 4MB TRAM instead of 1MB TRAM.

Another confusing factor was the release of the R8000 chip set - an Indigo2 with an R8000 was called a POWER Indigo2. R8000 systems were targeted towards markets such as CFD that need a high double precision floating point performance and a large L2 cache. Such markets may not be all that interested in fancy graphics options (although these days 3D gfx and VR is widely used for visualisation of such complex data sets) - my guess is that most users who'd prefer to use a Power Indigo2 would be happy with the Solid IMPACT option, unless they need texturing for some reason, eg. to help with emphasising data. Anyway, all the Indigo2 figures referred to here are for non-R8000 Indigo2s, so please bare this in mind if you're someone who might be more interested in an R8000-based system for whatever reason. Note that the R8000 chip set is not so easy to code for, so if you have the chance I recommend going for R10000, not R8000. In fact, if you're doing CFD-style work, you're much better off with Octane since the improvements Octane offers are perfectly suited to such work, namely dual-CPU support, much faster memory latency and memory bandwidth, and the ability to utilise modern CPUs such as the R12000, etc. At the time of writing this update (Oct/2002), R12000 Octanes have become quite cheap.

Comparing the O2's capabilities to Extreme is not as simple as just comparing graphics performance numbers; we're dealing with radically different machines with very different architectures (Indigo2 vs. O2). I'll deal with O2's extra capabilities that arise from its new architecture later.

First, it's worth noting the differences in available computational power for hardware geometry/lighting acceleration between the various Indigo2 graphics options:

   Indigo2 Graphics Type     Total GE MFLOPS

   XZ                        64
   Elan                      128
   Extreme                   256
   SolidIMPACT               480
   HighIMPACT                480
   MaxIMPACT                 960

By contrast, O2 does all its geometry and lighting calculations on the main CPU, which will offer between 300 and 1200 MFLOPS depending on the CPU type (the range includes 150MHz R5000 or R10000, through 175MHz R10000, 180MHz R5000 and 195MHz R10000, to 200MHz R5000, 250MHz R10000, 270MHz R12000, 300MHz R12000, 400MHz R12000 and the CPU-mod 600MHz R7000C). The fact that the above Indigo2 options always do geometry/lighting calculations in hardware, whilst O2 does them in software, can be important for certain types of task; I'll come back to this later.

The main primitive graphical numerical performance differences between Extreme and O2 arise from the fact that Extreme does not have texturing hardware, whilst O2 does. So, for anything involving texturing the O2 can be as much as 100 times faster (depends on scene complexity), whilst for other things Extreme might be faster; however, note that faster CPUs in O2 will automatically improve geometry/lighting calculations and hence the performance figures - this is not the case with Indigo2 Extreme. Other main differences include:

• O2 has antialiasing hardware whilst Extreme only supports this in software.

• O2 has a 32bit hardware Z buffer as standard whilst Extreme has to do 32bit Z buffering in software.

• O2 can do stereo in a window, Extreme cannot.

• O2 has no limit on texture RAM size (limited only by main system RAM size), ie. O2 will handle large texture data sets very well indeed. I have personally tested a 810MByte 2D image (16000x16000 pixels) and O2 was able to rotate the image using the roam program quite easily.

• O2 has a powerful set of features for video-as-texture processing, eg. mipmapping in hardware, the ability to combine 3D and image processing operations, etc. Indigo2/Extreme cannot do any of these things; it is possible to do video-as-texture with IMPACT Video and the IMPACT ColourSpace daughtercard, but it's not as flexible as O2's design.

The R10K will benefit a different kind of O2 user, namely people whose main focus is not 3D graphics but who might require some kind of image/graphical ability (if image/video/graphics wasn't important at all, they'd be better off looking at the Origin systems instead). The R10K will also help for tasks like rendering in Maya. But when it comes to price performance, don't dismiss the R5K simply because it's not an R10K - know the nature of your application and come to a sensible conclusion. Study the R5K and how it works, the optimisations built into it, etc.; understand its intended use before deciding on what to purchase, eg. although R10K is faster for integer processing, an R5K O2 is better for video because O2 is optimised for the way the R5K performs memory accesses (R10K has to access RAM through an extra intermediate ASIC, which makes real-time video processing slightly less reliable). The real world is just not as simple as a SPEC number. Also note that, due to various factors discussed elsewhere, floating point (fp) processing on R10K O2 does not perform so well compared to other newer SGIs, but integer (int) processing on R10K O2 performs very well indeed, almost always beating older SGIs such as Power Challenge and even matching Octane for some types of int task.

I mentioned earlier the issue of available geometry/lighting processing power. It is important to realise that if one's application involves complex geometry/lighting (eg. multiple spotlights), it is perfectly possible for even a low-end O2 to significantly outperform an R10000 or R4400/250 Indigo2 Extreme. The same effect means an Indy XL can outperform an Indy XZ. The reason is that graphics systems like XZ, Elan and Extreme must do their geometry/lighting calculations in hardware. Such systems will find it hard to cope with multiple complex lights, often resulting in the graphics FIFOs filling up, the main CPU being told to stall before sending more data, and a significant degree of context switching (see the gr_osview man page for details). On the other hand, systems like O2 and Indy XL do all their geometry/lighting calculations in software. Thus, when the lighting becomes complex, they experience no FIFOs filling up, few context switches and the main CPU runs at maximum potential.

From the point of view of considering an upgrade, this means that (for example) someone doing VRML-style work (dynamic 3D scenes with complex lighting, etc.) on an 180MHz R5000SC Indy XL is far better off upgrading to an R5200/300 or R14K/400 O2 rather than an Indigo2 Solid or High IMPACT, even though the latter's raw pixel fill is 2X faster than O2. In theory, something like a 300MHz R12000 O2 should outperform an R10K Indigo2 SolidIMPACT for scenes with complex lighting, though IMPACT's better pixel fill might just keep IMPACT in the lead; this is a testable theory now, but I haven't been able to check yet. For a much more detailed analysis on these issues with example performance figures for a typical 3D scene with complex lighting, please see the HolliDance Benchmark page. Note that these issues do not apply to 3D scenes that have simple, little or no lighting, eg. CAD modeling involving flat or 1-light directional-lit Gouraud shading.

There are other things to bare in mind when comparing Indigo2/Extreme to O2. Consider the supplied hardware that comes with O2:

• 10/100MBit Ethernet
• 2 UFW SCSI channels
• ICE (Image Compression Engine for hardware video capture/edit/playback)
• 2 fast serial ports (460Kbit/sec each)
• 1284 Parallel port (minature)
• 12X CDROM (older models used a 4X CDROM)
• PCI64 expansion slot
• Fast memory (100MHz) and large capacity (1GB)
• Fast internal memory graphics/RAM bandwidth (2.1GB/sec peak)
• The usual audio abilities (4 channel stereo, 8 to 48KHz sampling, etc.)

• Composite video I/O
• S-video I/O
• Digital O2 Camera
• Digital video input for the O2Cam (this can be converted to full CCIR601 digital video I/O via the use of a 3rd-party adapter).

The architecture in O2 allows one to do tasks that are not possible with Extreme (eg. real-time capture of 3D application to disk as a hardware compressed video file, or send screen to video out if one has the ProVideo option). Further, O2's design allows one to do such things as using an incoming video stream as the source for a texure in a 3D model. O2 can do many 2D/3D things at once, while Extreme cannot.

Many of these differences arise because O2 is a newer system with a different architecture, whereas the Indigo2 is an older design (of course, O2 was supposed to replace the Indy, but in my experience most questioners compared it to Indigo2/Extreme which is rather ironic).

"So what are the specs? Comparing old vs. new and comparing to O2?"

Note the maximum memory capacities:

R4400 Indigo2:  384MB
R8000 Indigo2:  640MB
R10000 Indigo2: 1GB     (recently updated information)
O2:             1GB

If you decide to examine the Viewperf pages at the SPEC site, or on my own comparison page, please be very wary of comparing mismatched Viewperf results, eg. comparing R4400-based Max IMPACT to R10000-based Solid IMPACT. Actually, I think I'll include a personal Viewperf-related moan-at-the-world here: if you intend using Viewperf results when comparing systems, please take the time to investigate properly how the Viewperf tests actually work. Like the SPEC CPU tests, each Viewperf test is a combination of several different tasks, although Viewperf combines the results in a different way. As a result, final Viewperf results can hide key differences between systems (just like SPEC does between processors), as my own study of Indigo2 vs. Compaq Gloria-L shows very clearly.

For people considering Indigo2 processor upgrades, speed-ups from the R4400 to R10000 will range from roughly 2X to 5X depending on the specifics of your application, how well it matches the R10000 design and what the clock speed is of the older R4400 being used. See my R10K/195 performance page for details and example speedups with Fortran77 code. Recompilation will give the best improvement (the application can take advantage of the MIPS IV instruction set architecture which the R10K uses), but make sure you use the latest MIPS Pro Compilers (check on www.sgi.com to see which is the latest compiler release).

Typically, expect to see around a 97% performance improvement in main computation without recompilation (for R10000/195 compared to R4400/200). The improvement will also vary depending on whether your work involves mainly integer or floating point computation and on where the bottlenecks are in your application. Also note that R10K in Octane can run applications 2 to 3 times faster than R10K in Indigo2 - the larger and more complex the data set, the bigger the speedup when Octane is used. R10K also performs better in Octane or Origin compared to O2 by a factor of 2 or 3 for floating point work, but the reasons for this are in some cases not the same as the Indigo2-->Octane speedup (note however that integer work with R10K O2 is generally quite good, easily beating older SGIs such as Power Challenge and sometimes matching Octane for certain types of code).

General Advice

For those contemplating upgrades from Indigo or Indigo2, as a low cost solution you might consider an O2 workstation instead of Octane, eg. if you want your workers to be able to carry on working at home, or if you want a much larger number of lower-power workstations, or if you want low-end texturing performance for intermediate tasks, etc. And as said earlier, if you are currently using a system which has no hardware geometry acceleration (eg. Indy XL), do not immediately assume that something like an Indigo2 Elan will automatically be faster - see the HolliDance Benchmark page for a complete discussion.

Don't be fooled into thinking the O2 is better than any High/Max IMPACT/SI/SSI/MXI/MXE machine at basic graphics rendering (eg. textured triangles per second), because it often isn't. The O2 has some superior standard video, image processing, memory bandwidth and I/O capabilities over the Indigo2 (and the O2 has an architecture which Indigo2 users may envy, eg. texture memory is limited only by main RAM size, and video-as-texture is automatically mipmapped in hardware), but the O2's graphics hardware is nowhere near as fast as IMPACT for raw performance. Of course, Indigo2 users can upgrade to Octane if they want more power, but that's a different story altogether.

O2 has image/video compression hardware supplied as standard, but doing this on an Indigo2 or Octane requires extra option cards; plus, the option cards for Indigo2 and Octane only support MJPEG compression/decompression, whereas O2's ICE ASIC can theoretically be programmed to support the acceleration of a variety of different codecs. As standard, O2 can playback MPEG files and certain other formats in hardware. Ironically though, the freeware mplayer application can use IMPACT/VPro graphics hardware to accelerate video playback, which works very well.

Before you buy, it is highly advisable to test your application on the target system, and I don't mean just run your application and see how many frames/sec you get. Consider what your real daily tasks involve: what else do you do whilst working? Would you need to be able to capture what you're doing to video tape for promotional demomonstrations, presentations, etc.? Given the capabilities of a system like O2, what might you be able to do that you couldn't do before (but always wanted to)? Don't go spending alot of money without knowing how your application is going to perform, how your real-life workload will be handled and how future demands in your job may evolve. Finally, a quick note about texture mapping. As mentioned earlier, certain markets which didn't traditionally use texture mapping may benefit from its use in data visualisation. This includes CAD, engineering, medical and biological disciplines. SGI has a brief introduction to texture mapping concepts, but if you're interested then read the molecular modeling application brief that I've typed up on the subject.

I hope you have found the information given here useful and I welcome any feedback that you may have.