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:

• Anti-Aliasing - anti-aliasing on RealityEngine involves multisampling. Images are effectively rendered into memory at a much higher resolution than the 1280x1024 frame buffer. To do this and maintain a decent size window you need lots of frame buffer memory (see how to work out exactly what you can use in the RealityEngine graphics buffer configuration section) and lots of pixel processing power! More raster managers certainly help here - each raster manager adds 40Mb of frame buffer memory and more parallel pixel processing power. Why do you want anti-aliasing? The multisampling technique on which it is based has all kinds of uses eg. removing unwanted effects from visual simulations (eg. sparkling texture pixels which are distant from the viewpoint).

 
• Pixel Fill Limitations - in situations where the graphics bottleneck is actually getting a large number of pixels processed and displayed, additional raster managers can improve frame rates. The reason is that the raster managers work in parallel on their own copies of the pixel data. Unfortunately this only ever really occurs on RealityEngine with very simple models and single buffer tests. There are at least two reasons why this is so:

 
• Each raster manager is pretty good at processing pixel data no matter how large the render area is (compare the MW versus SW results for the single raster manager config in Ian Mapleson's test suite). It would be interesting to see whether this remains true with a 3d texture, as visualizing such a texture involves much higher pixel fill demands.

 
• Other factors such as CPU speed and probably powerpath throughput tend to dominate in Crimson RealityEngine much more than pixel fill limitations whenever the rendered model becomes (usefully) complex. (I suspect this would be different with the Onyx RE2 due to its 1.2Gb/sec backplane throughput and multiple (sometimes faster) cpus).

 
• Higher resolutions: 1600x1200 and HDTV resolutions are only possible with two or four raster manager configurations.

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?

• RM4/RM4T board revisions. According to the RealityEngine technical report, RM4 boards that return rev 0101 or later in gfxinfo can be used with a wider variety of video output formats than those that return lower revs. Mixing the different revisions that I have has not caused any problems.

 
• DG2 and the MCO card. According to an old dejanews article I read, the MCO card is apparently sensitive to the version of DG2 used to drive it. It was my understanding that SGI had been to this site and replaced the DG2 board three or four times before it would drive the MCO correctly. Symptoms of a dodgy/incompatible DG2 apparently include frame tearing and (other) frame timing problems on the channels produced by the MCO.

 
• DG2 and the RM5. DG2 revs older than 030-0513 don't seem to work reliably with the RM5 board. For example, I first used the older 030-0223 DG2 we have with the RM5. Everything worked except there was no blue output channel. Odd - but probably consistent with the fact that the Onyx RealityEngine2 DG2 was listed as 030-0513.

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 (robj@reading.sgi.com) 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:
 

• Texture download/paging performance is nowhere near as good as Octane SI+tex. This is to be expected since Octane has faster memory etc. It can be partially dealt with by using RGBA4 or RGB5_A1 texture internal formats which is a good idea anyway because RE doco is littered with references to 16 bit texels being the optimum format.

 
• Some important OpenGL texture extensions that are useful for Visual Simulation are present on Impact but NOT present on RealityEngine. In particular:

 
• EXT_texture_lod - this extension allows you to control which mipmap levels are paged into texture memory. This is very useful for stopping machines with limited texture memories from dragging in heaps of unwanted mipmap levels and so killing the simulation. If only SGI had been able to implement this on Crimson RealityEngine. It's not too late guys :-) For more details on this extension (and the next) check out Patrick Bouchard and Paul Hansen's TerrainFollowing program on the Developers Toolbox. With some modification the program runs on RealityEngine but performance dies due to texture page thrashing. If EXT_texture_lod worked on RealityEngine, this could be improved because fewer levels/per frame would be paged in/out of texture memory. It could also be that the texture hardware on RealityEngine doesnt have the necessary intelligence to support this extension(?).

 
• EXT_texture_select - this extension allows intensity only textures to be 4-way interleaved. Very useful for texture memory compression but I'm not too worried about this one because I dont use it much! :-).

 
• EXT_packed_pixels - this extension allows you to match your (external) texture format with the RE preferred 16 bit internal texture formats. Unfortunately it isnt implemented on RE so this is annoying when you are desperately trying to save storage/transfer bandwidth!

 
• EXT_convolution - not mentioned by glxinfo! However the doco is a bit oblique. It states that RE doesnt support this extension whilst storing data in a texture object. However word (in this case an old article on dejanews) has it that you can still use the convolution functions whilst doing a glCopyPixels - I've yet to try this out though. If I do, it looks like I'll have to switch this on whilst copying pixels between pixel buffers.

 
• Anything which requires a lot of CPU preparation will suffer.

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 http://www.futuretech.vuurwerk.nl/perfcomp.html. 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  http://www.futuretech.vuurwerk.nl/octncomp.html.
 
 

Other RealityEngine Links

For pictures of RealityEngine in a Crimson case see SkyWriter's site at: http://www.reputable.com/~skywriter

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: http://www.futuretech.vuurwerk.nl/re.html

Comments to: simon@dpiwe.tas.gov.au