Crimson/Power Series/RealityEngine Info
Last updated: April 13, 2000


Power Series RealityEngine pictures and slot details

Onyx RealityEngine2 RM5 Raster Managers in Crimson/PowerSeries RealityEngine

How Many RealityEngine Raster Managers do you need?

RealityEngine Boardset Revision Numbers and gfxinfo

Crimson/Power Series Parts List

RealityEngine Graphics Buffers Configuration

Just how good is RealityEngine when compared with Impact?

RealityEngine and Performer

Other Links

R4400 IP17 and R4000 IP17 differences

Power Series with VGX and VGXT Graphics

Power Series with GTX Graphics and CG2 GENLOCK option

Power Series Fans

Jumper Settings on IO3/IO3B for R3000 and R4000

All the images shown in these pages are thumbnails - so clicking on them should get you a higher resolution image.

Power Series 4D/360 RealityEngine and Crimson RealityEngine

These pictures were taken by Michael Stromberg at KTH, Sweden before he removed the boards. I used them to install the RealityEngine boardset and Multiple Channel Output (MCO)VME card into my Power Series Rack which is running an IP17 R4400/150MHz and IO3B from a Crimson.

Front I/O Panel. The two fat black cables on the left are from the MCO VME card. The fat black cable in the centre comes from the RealityEngine DG2 board.

 The populated card cage. The slots and cards are as follows:
VME Slot 1 MCO  which connects to the DG2 via paddle boards and three silver cables (Onyx and Crimson/PowerSeries MCO are the same board).
VME Slot 2,3,4,5,6 Empty
Slot 7 IO3B
Slot 8,9,10 IP7 CPU boards with 2 x 33MHz R3000 on each board
Slot 11 Empty
Slot 12 MC2 memory board
Slot 13 Empty
Slot 14 GE8 Geometry Engine board
Slot 15 DG2 display generator - the paddle board connects to the MCO via the three white connectors, the top small red two pin connector is for stereo glasses, the lower two pin connector is for the swap-ready gangdraw control plate.
Slot 16 Empty
Slot 17 RM4 Raster Manager
Slot 18 Empty
Slot 19 RM4T  Raster Manager
Differences for Crimson config: 
Slot  8 IP17 CPU board with 1 x 150MHz R4400SC or 1 x 100MHz R4000SC or 1 x 100MHz R4400SC (soon)
Slot  9-13 Empty
Slot 16,18 Two additional RM4 Raster Managers for a total of 160Mb of Frame Buffer memory.

Front I/O Panel (closed) - From the left hand side, the first 4 columns are for 4 MCO BNC output channels, Genlock etc. The next two occupied columns are the usual 13W3 monitor, SVHS, Composite Video etc connectors from the DG2 card which are supplied with all RealityEngine machines. Next column has the ethernet and SCSI connectors and is connected to the IO3B. After that you have the usual serial port, keyboard and the unused RGB+Sync BNC connectors. Note: whilst the MCO channels are in use, the DG2 outputs (including the 13W3 connector) are not available.

Onyx RealityEngine2 RM5 Raster Managers in Crimson/PowerSeries RealityEngine

Onyx RealityEngine2 DG2 and RM4 boards have the same part numbers as those used for Crimson/PowerSeries RealityEngine. When I queried this on comp.sys.sgi.hardware, I received a number of replies indicating that all RealityEngine2 and RealityEngine boards are interchangeable except the GE8 and the GE10. This is because the graphics bus in Onyx RealityEngine2 is the same as that used in Crimson/PowerSeries RealityEngine. The really nice outcome of this is that an Onyx RealityEngine2 RM5 Raster Manager with 16Mb of Texture RAM should also work in Crimson/PowerSeries RealityEngine.

I've just received (Sept 99) an RM5 raster manager (030-0347-002). RM5s have the same termination requirements as the RM4s but there is no special version of the RM5 that must be in the last RM slot. Any RM5 can be in that slot, however it must have 9 resistors installed in the resistor banks adjacent to the backplane connectors. If you see this warning generated early on in the PROM messages:

WARNING RE pipe 0: Illegal RM4 Termination

and it is followed by a PROM warning about unrecognized graphics, then you have an RM5 in the last RM slot which is not terminated and you should install the required resistors in the resistor banks adjacent to the backplane connectors.

Tests that I've done so far (in performer and our own OpenGL stuff) show that the full 16Mb of texture memory is available and works so using an RM5 in a Crimson/PowerSeries is definitely ok!

More about the GE8 and GE10 boards. Unfortunately, the GE8 and the GE10 geometry engine boards are not interchangeable because apart from their obvious GE function they also interface the graphics bus to the system/CPU bus. On Onyx, the system/CPU bus is powerpath-2 (or Everest Bus better known as E-Bus) and is rated at 1.2Gb/sec whereas on Crimson/RealityEngine, the system/CPU bus is powerpath-1 and is rated at 64Mb/sec.

How Many RealityEngine Raster Managers do you need?

Just how many raster managers do you need? Does having more raster managers improve frame rates? I have tested the 1 x RM4, 2 x RM4 and 4 x RM4 RealityEngine Raster Manager configurations using Ian Mapleson's test suite and the following is a summary of the merits of adding additional raster managers:

Recommendation: two raster managers to do normal visual simulation. This provides for all required anti-aliasing tricks and allows an occasional foray into HDTV/1600x1200 resolutions. If you have the Multiple Channel Option (MCO) then you should have four raster managers. This is the only way to support anti-aliasing on the full 1280x2048 resolution. You do need to be careful with cooling for the four raster manager config - it runs hot! I think the predator/powercentre rack chassis with very noisy 240cfm fans is the only safe way to go here.

RealityEngine board revs and how they correspond to gfxinfo

We have three power series racks equipped with IP17, IO3B and RealityEngine boardsets. Interestingly all three machines have RealityEngine boardsets with different revisions. These revisions (at least in some cases) are reflected in different information displayed by the /usr/gfx/gfxinfo command. The first RealityEngine boardset has the following revisions:
GE8 030-0225-003
DG2 030-0223-008
RM4T 030-0239-004

The gfxinfo command for this boardset returns the following information:

Graphics board 0 is "REC" graphics.
        Managed (":0.0") 1280x1024
        Display 1280x1024 @ 60Hz
        8 GE (GE8 rev. 0x7/101)
        1 RM4 boards (rev. 00101)
        Small pixel depth
        10-bit RGBA pixels
        Not using Multiple-Channel Option

The second boardset has the multiple channel option (MCO) VME board and appears to be a later boardset than the one described above (this is the one pictured above with 2 x RM4 but we run it with 4 x RM4 in the Predator rack only since it runs HOT). Its revisions are as follows:
MCO 030-0284-004 (in VME slot 1)
GE8 030-0225-003
DG2 030-0513-004
RM4 x 3 030-0359-001
RM4T 030-0360-001

The gfxinfo command for this boardset returns the following information:

Graphics board 0 is "REC" graphics.
        Managed (":0.0") 1280x2048
        Display 0 1280x1024 @ 60Hz
        Display 1 1280x1024 @ 60Hz
        8 GE (GE8 rev. 0x7/101)
        4 RM4 boards (rev. 00112/00112/00112/00112)
        Medium pixel depth
        10-bit RGBA pixels
        Driving Multi-Channel Option

The third boardset we have has an RM5 from an Onyx RealityEngine2 in it. Its revisions are as follows:
GE8 030-0225-003
DG2 030-0513-004
RM5 030-0347-002

The gfxinfo command for this boardset returns the following information:

Graphics board 0 is "REC" graphics.
        Managed (":0.0") 1280x1024
        Display 1280x1024 @ 60Hz
        8 GE (GE8 rev. 0x7/101)
        1 RM5 board (rev. 00112)
        Small pixel depth
        10-bit RGBA pixels
        Not using Multi-Channel Option

What are the implications of the different revisions?

RealityEngine Graphics Buffer Configuration

In search of an answer to the questions, "how do I work out how many raster managers are needed for antialiasing on RealityEngine?" and "how much space can be allocated to the various graphics buffers with each raster manager config?", I came across a nice summary and calculation methodology based on a Pipeline article and posted to info-performer by Rob Jenkins of SGI in the UK ( in 1996. The following is my simplification and understanding of that article.

To understand what raster manager memory is available for the various graphics buffers (antialiasing is done via the multisample buffers on RealityEngine), you need to understand how all the RealityEngine graphics buffers can be configured. Each RealityEngine raster manager board has approx 40Mb of memory for the storage of these buffers. The maximum pixel depth that can be allocated to the buffers for the different raster manager configs at the typical 1280x1024 resolution is:
Number of Raster Managers resolution width x height (pixels)  Maximum depth (bits)
 1  1280x1024 256 (small pixel depth in gfxinfo)
2 1280x1024 512 (medium pixel depth in gfxinfo)
4 1280x1024 1024 (large pixel depth in gfxinfo)

The allocation of the bits in the maximum depth figure to the various graphics buffers is flexible - not all of the available bits need be used because the full 48 bit rgba pixel capability may not be required or some buffers (eg. accumulation buffer) may not be desired. The potential allocations for each buffer are as follows:
front colour buffer 32 bits or 48 bits
back colour buffer (always same as front buffer) 32 bits or 48 bits
accumulation buffer 0, 12 or 24bits/component
z-buffer (or depth buffer) 32 bits
overhead (overlay, underlay etc) 64 bits
stencil buffer 0 or 8 bits
multisample buffers (for antialiasing) 0,4,8 or 16 * (y + size of z-buffer) + (2 x size of front buffer) 
where y = number of components * size (in bits) of component

It's clear from the above that RealityEngine with one raster manager board can never do antialiasing at 1280x1024 - the front and back buffers must take at least 64 bits, the z-buffer has to have another 32 bits and there is a fixed 64 bit overhead ie. 160bits out of the total 256bits are reserved regardless of the size and number of components of the data that is actually in the colour buffer. Indeed the only way to obtain sufficient memory to do multisampling with one raster manager is by reducing the resolution.

Lastly, I suspect that if you don't need an optional buffer(s) then you should try to choose an OpenGL visual that doesnt contain it/them (you can see the OpenGL visuals for a 1rm RealityEngine and a 4rm RealityEngine). The reason is that RealityEngine supports the accelerated pixel buffer rendering extension under OpenGL and pixel buffers are allocated from spare raster manager memory. Obviously, the more available raster manager memory you have, the more pixel buffers you can use.


Just how good is Crimson RealityEngine when compared to Impact?

It is still surprisingly effective. Our Visual Simulation application (VisKit) runs on RealityEngine at better than 10 frames per second over two 1280x1024 screens with antialiasing. RE geometry performance seems similar to my Octane SI+tex but there are some very important caveats you should bear in mind before you leap out and buy a second hand Crimson RealityEngine:

How do we deal with the lack of the EXT_texture_lod and consequent affects on texture paging? At the moment I just lose the highest level of detail in the mipmap stack. Since this is not suitable for very close in viewing I am looking at getting around this by keeping some of the level 0 mipmaps in frame buffer memory as pixel buffers (yay! RE supports the pixel buffer extension!) and using glCopyTexSubImage2D to get them in when the user requires. This is ok because unless you really need a close in view (eg. stopped and looking at a couple of tiles), the level 1 mipmaps are quite suitable.

Further searching through the dejanews archives shows some references to sub textures being the best way to deal with textures that change rapidly and often on RealityEngine. To test this out I compiled the ImageProcessing Roam demo with the subtexture option. Performance is a lot lot faster than the default texture object paging version. Interestingly performance was also significantly less jerky with the subtexture option on my Octane SI+Tex. More on this as things become clearer....

How do we deal with the lack of CPU power? Grin and bear it - it's really not that bad. Swear at SGI for not dumping the R10000 into RealityEngine before Onyx came along and curse at my state government for not being rich enough to afford such a beast.... :-)

What resolutions are we talking about here? These tests have been done on an 1120x1200 point terrain which we texture with a 4604x4806 image which is in turn split into 392 (level 0) 256x256 16 bit texel tiles. Initially we were using a simple development of the Bouchard/Hansen TerrainFollowing program to test all this out but now we have moved to performer 2.2. You can check out our progress by looking at our Performer and RealityEngine page (some of the points made here are also made there).

To see where the line about "RealityEngine geometry performance being similar to Octane SI+tex" comes from, see the appropriate Inventor graphics tests in Ian Mapleson's benchmark suite on However, when looking at the tests keep in mind the following historical perspective. With RealityEngine, the situation seems to be that general CPU and bandwidth are fairly limited, so keeping the geometry engine fed and taking care of texture download/paging/roaming plus any additional model preparation is difficult. These days (with Octane) you get lots more CPU power and bandwidth which you can apply to texturing and model preparation. In fact it seems to me that this is why Octane came out with Impact graphics - it could get so much more out of Impact because the bandwidth was now available to keep it fed and busy. Thus it could be said that RealityEngine (and Indigo2 Impact) geometry performance is only comparable to Octane when bandwidth issues do not dominate eg. when required textured data fits into texture memory and/or doesnt change too rapidly. This would explain why Octane SI+Tex starts to really outperform RealityEngine for the more complex tests in Ian's suite and for texture paging in our VisSim applications.

For a good discussion and comparison of Octane and Indigo2 together with some figures supporting the above, see Ian Mapleson's

Other RealityEngine Links

For pictures of RealityEngine in a Crimson case see SkyWriter's site at:

Much that is here is based on tech reports/benchmarks suites and/or discussion with Ian Mapleson. If you are in the SGI game at all then you'd better look at his site. For the RealityEngine enthusiast, see the RealityEngine tech report on Ian's site at:

Comments to: