Contents
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?
R4400 IP17 and R4000 IP17 differences
Power Series with VGX and VGXT Graphics
Power Series with GTX Graphics and CG2 GENLOCK option
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:
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 (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:
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:
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.
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