Onyx

Onyx with Multichannel option.

The Silicon Graphics Onyx (frequently known as the Onyx1 or Original Onyx, or by its form-factor specific codenames Eveready and Terminator) is a graphics supercomputer introduced by Silicon Graphics in 1993 to replace their short-lived Crimson. Also based on the POWERpath-2 Everest architecture, the Onyx is closely related to the Challenge L/XL systems offered by SGI during the same time period, and shares many parts. In general, the difference between an Onyx and a Challenge L/XL is that while the Challenge usually supports more CPUs and memory (with the exception of the Challenge DM), it does not support the installation of a graphics boardset (with the exception of the Challenge GR). The Onyx sat at the high-end of SGI's early-to-mid 1990s product line, above both the Indigo2 and Indy, and was used for tasks such as visualization, simulation, and early virtual reality systems. The system was succeeded on October 7th, 1996 with the launch of the Onyx2. Though production of new Onyxes ended in March of 1999, with the end of service in December of 2008, SGI continued to use the Onyx brand name on their most capable graphics systems until July of 2003, with the introduction of the Onyx4.

Onyx with the R10000 Badges

Variants and Naming

The Onyx is a highly modular system, and was offered in a number of processor and graphics combinations throughout its lifespan. Though some configurations (such as an R8000-based Onyx with VTX graphics) were not offered officially, most CPU/Graphics combinations were, each under a different name. There were ten different, individually named "major variants" of the Onyx. The table below describes these.

SGI Workstation/Client Periodic Table November 4th, 1994 demonstrates the naming discrepancy between Onyx and POWER Onyx systems with Extreme Graphics installed. While POWER Onyxes are labeled with a slash as POWER Onyx/Extreme, Onyxes are labeled without the slash.

In some cases, such as on their Periodic Tables, SGI also listed the number of processors after the first portion (the one which represents the CPU) of the name. For example, a system with RealityEngine2 graphics and four R4000 CPUs would be an Onyx/4 RealityEngine2, a system with RealityEngine2 graphics and twelve R8000 CPUs is a POWER Onyx/12 RealityEngine2 and so-on. Interestingly, R4000 systems with Extreme graphics do not use the "slash-CPU" notation, meaning that, for example, an system with two R4000s and a system with four R4000s, each with Extreme Graphics, are both known simply as the Onyx Extreme. The same goes for the R8000-based POWER Onyx, except that the slash is kept with only the number removed. All R8000-based Onyxes using Extreme Graphics are known simply as the POWER Onyx/Extreme. This strange phenomenon can be seen on the November 4th, 1994 Workstation/Client Periodic Table (image on right) and the very similar Workstation/Client Periodic Table rev. 2/14/95 (the only difference of which is a change to the aesthetic of the title and the removal of the Crimson RealityEngine and its replacement with the Reality Station, which is, redundantly, known there as the Reality Station RealityEngine2). While this discrepancy between the POWER Onyx and the regular, R4000 Onyx's naming schemes could be mistaken for a typo, its presence on two similar but different revisions of the Periodic Table makes this unlikely.

Architecture

A diagram explaining the basic system architecture of the Onyx RealityEngine2

A diagram explaining the basic system architecture of the Onyx InfiniteReality

The architecture of the SGI Onyx can be roughly divided into two main parts — the POWERpath-2 bus (frequently known as EBus) and the HIO bus (also known as IBus), including the buses and interfaces which interface with the system via it. While the POWERpath-2 bus provides a high-speed interconnect for CPUs, memory, and the I/O subsystem, the HIO bus provides both direct expansion capabilities using the HIO connectors on the IO4, and interfaces to a number of other system components over FCI (via the F Controller ASICs), VMEbus (via the FCI-connected VMECC), SCSI (via the S1IC) and numerous miscellaneous interfaces (via the EPC).
POWERpath-2 is the successor to SGI's POWERpath architecture, which they had previously used in their PowerSeries and Crimson systems. While it is officially known as POWERpath-2, it is often called EBus, short for "Everest Bus", Everest being the codename for the system architecture shared by the Onyx and Challenge L/XL. While not the "true" name of the bus, the "EBus" moniker is frequently used both by Onyx owners and by SGI themselves (such as on the slot number label affixed below the slots of the Onyx cardcage). The 256-bit POWERpath-2 bus has a data transfer rate of 1.2GB/s (as compared to the 64MB/s of the original POWERpath), and is used exclusively for the system's core components, the IP19/21/25, MC3, and IO4 boards (not for add-on options or graphics boards). POWERpath-2 is unique to Everest systems (Onyx and Challenge L/XL), and was replaced with the S2MP architecture in the later Onyx2 and Origin2000.

The cardcage label below the POWERpath-2 slots of a deskside Onyx, reading "EBus"
While core components are connected to POWERpath-2, their interface with the rest of the system is provided by the IO4 board. The IO4 uses an internal 64-bit bus, which, like POWERpath-2, has two names, those being HIO and IBus. When referring to add-on cards connected to the IO4 using it, it is usually referred to as the HIO (high-speed I/O) bus. However, it is also used internally on the IO4, and it seems that the term "IBus" is preferred here. IBus has a bandwidth of 320MB/s, and is shared by HIO add-ons, VME devices and the graphics subsystem (via F Controller ASICs and the VCAM), and the IO4's built-in EPC I/O controller (which, in turn, creates another bus used for basic I/O devices, the 16-bit PBus) and S1IC SCSI controller. VME devices and graphics boards do not connect directly to IBus. Instead, the IO4 also contains two F Controller ASICs, each of which connects to IBus and creates an FCI, or Flat Cable Interface. These two FCI interfaces are exposed on two connectors towards the rear of the IO4. Attached to these connectors (resting on standoffs above the IO4's PCB, much like the HIO options in front of it) is another board known as the VCAM, or VME Channel Adapter Module. The VCAM serves two primary functions, each using one of the FCI interfaces created on the IO4.
As the name of the device states, one of these functions is to act as an adapter between the system and its VME add-on boards. VMEbus is an industry-standard bus developed by Motorola for systems based on their 68000 processor, and used in many systems both with and without the 68000. Though the Everest family were the final SGI systems to use VMEbus, it was far from the first, with many previous SGI systems and add-ons also using it. The Onyx implements VME Revision C, as well as the A64 and D64 modes of Revision D, allowing VME bandwidth up to 60MB/s when DMA is used. The deskside Onyx has 4 VME slots, one of which is filled by the VCAM, while the rack has either four or twelve slots, depending on cardcage configuration (see below for details). The VCAM provides this VME interface using its onboard VMEBus controller chip, and interfaces the VME bus to one of its FCI interfaces using the VMECC (VME Cache Controller).
The other FCI interface provided to the VCAM is simply passed through to the backplane, for use by the graphics subsystem. This is the other primary function of the VCAM. The graphics subsystem communicates with the host system over its FCI interface using its GFXCC (meaning unknown, but probably "Graphics Cache Controller", in the vein of "VME Cache Controller").

In an Onyx Rack, the number of VME slots available depends on whether the system's third cardcage is used. When only two cardcages are used, the rack Onyx has four VME slots, all in Cardcage 2, one of which is filled by the VCAM attached to the IO4. This is the same configuration found in deskside systems. When the third cardcage is used, eight more VME slots, for a total of twelve, are made available. These slots are divided into two groups, found in slots 1, 2, 3, 4 and 12, 13, 14, 15 in Cardcage 3. Slots 1 and 12, the first of each group, contain a VCAM-like board known as an RVCAM, or Remote VCAM, which provides a VME bus to the three slots next to it. No RVCAMs are required if only two cardcages are used, as the VCAM connected to the system's IO4 is sufficient to control the VME slots in Cardcage 2.
In systems equipped with Extreme Graphics, the VCAM is replaced with a GCAM (meaning unknown, but likely "GIO Channel Adapter Module", in the vein of "VME Channel Adapter Module"), effectively replacing the system's VME bus with a GIO64 bus (albeit in a strange form factor). While the exact components of the GCAM are unknown, it likely uses an ASIC in order to interface the GIO bus to one of the FCI interfaces usually used by the VCAM. Assuming the naming scheme for FCI-connected devices was followed, this chip was likely known as the GIOCC. An adapter is then used to install an Indigo2 Extreme Graphics option in a "VME" (the actual protocol is GIO, but the same physical slots on the backplane are used) slot. While both the GCAM and the adapter are relatively unknown and extremely rare, the adapter is especially hard to find details about. It has been mentioned only a few times on Nekochan Forums, with user "whiter" referring to it as "the GIO2VME adapter" in one post and "AB5 (GIO64 to 9u VME shoehorn)" in another, and user "thegoldbug" referring to it as "a small circuit board (SLAG2) with resistors that connects to the VME bus", going on to conclude that "The GCAM must be doing all the work". In a thread about this board created by whiter, another user, "kshuff", says that he owns an Onyx with Extreme Graphics, and that it was factory-installed in his system. The board appears to have been named the AB5 (possible meaning Adapter Board 5), though the names GIO2VME and SLAG2 are also possibilities, and is seemingly smaller than a usual VME-like board, while consisting of "resistors". Based on this, it is likely a small board, the electronics of which consist solely of passives, located at the rear of a VME slot and containing a GIO64 connector of the sort seen in the Indigo2. In order to mount the non-VME-sized Extreme Graphics boardset in the Onyx cardcage, as well as to affix it to the adapter board, some form of carrier, likely a simple metal frame, was probably used. How the Extreme Graphics boardset's ports were moved to the expansion panels in the cardcage door or the graphics bulkhead below is unknown. It has been noted that a spare GCAM and AB5 board could be used with an Extreme Graphics boardset from an Indigo2 in order to add graphics capabilities to a Challenge L/XL, however thegoldbug, one of the owners of this hardware mentioned above, claims to have attempted this configuration twice, using two different AB5 boards, unsuccessfully. The possibility of adding a non-Extreme GIO64 board such as an IMPACT graphics boardset or other Indigo2 card to an Everest system using the GCAM and AB5 has also been raised, however the conclusion seems to be that it would not be possible due to driver problems.

CPU

The Onyx's CPUs reside on the IP board, which is installed in a POWERpath-2 slot. Though there are 22 different CPU boards available for the Onyx, they are divided into three main categories by their IP number. While most SGI systems spanning multiple processor families use only one IP number (such as the O2, which is an IP32 system regardless of whether an R10000 or R5000 is installed), the IP number of the Onyx and its CPU board(s) is determined by its CPU family. The IP19 board contains one, two, or four R4400 (R4000-family) processors, and was originally the only processor board offered in Onyx systems. With the introduction of the POWER Onyx and the R8000, the IP21 board, containing either one or two R8000s, was released. Note that because there is no IP21 board with four processors, the usual maximum processor count of 4 in desksides and 24 in racks is halved to 2 and 12, respectively. Finally, with the introduction of the Onyx 10000, the R10000-based IP25 board was introduced, which, like the IP19 board, can contain one, two, or four processors.

Desksides allow one IP CPU board, which must be installed in its designated slot (labeled on the sticker below the cardcage). Given the maximum of four CPUs per board, this means the maximum number of CPUs that can be installed in a deskside system is four. Rack systems are significantly more flexible, having eleven EBus slots, five in Cardcage 1 and six in Cardcage 2. Slot 6 in Cardcage 2 must be filled by the master IO4 board, however the ten remaining slots can be used for either IP CPU boards or MC3 memory boards. Additionally, the five remaining EBus slots in Cardcage 2 (those not filled by the mandatory Master IO4 in Slot 6) may be used for additional IO4 boards, though the five slots in Cardcage 1 cannot. Up to six of these slots may be filled with IP boards, allowing up to 24 CPUs in an Onyx rack system.

The secondary cache of the IP19 board is installed on SIMM modules, though these are not the same ones found in the MC3's slots. These are available in capacities of 256KB and 1MB. The 1MB SIMM is not only four times larger in terms of capacity, but also has a slightly reduced latency.

Memory

Memory is installed in the Onyx using one or more MC3 boards. A deskside system can take one MC3 board, while a rack can take up to 8. Note that this means that it is impossible for an Onyx rack to have both the maximum CPU configuration and the maximum RAM configuration, as there are simply not enough EBus slots for 8 MC3s and 6 IP boards, let alone any IO4 boards. The MC3 board has 32 slots, each of which can accept a single SIMM of special ECC-protected memory. Three different models of memory SIMM exist, in capacities of 16 and 64 megabytes (with the 64MB version existing in two different variants). The following is a list of MC3 board revisions. It is believed that all revisions should be interchangeable with no effect on compatibility with other parts. However, this has not been exhaustively tested, and as such it is recommended to leave a working system's MC3 board in place when possible, as all MC3 revisions are essentially equivalent in functionality.

List of Onyx MC3 Memory Board Revisions (by SGI Part Number)030-0245-00x

• 030-0604-xxx
• 030-0607-001
• 030-0613-xxx
• 030-0614-xxx
• 030-0614-106

The following is a table of available Onyx memory SIMMs, to be installed on the MC3.

Graphics

Throughout its lifespan, the Onyx was available with four different graphics options. Initially released with a choice of RealityEngine2 or VTX, options for Extreme graphics and InfiniteReality were introduced later.

The performance characteristics of these graphics options are provided in the table below, for easy comparison.

Note: Overlay and underlay plane specifications are confusingly worded in sources, and should be taken with
a grain of salt. Meaning of "32-pixel" measurements is unknown, and they are provided verbatim, as listed in
the original source (sgistuff.net). Numbers for dual-RM setups may be interpolated from listed single and quad
specifications, marked with ~ when 4-RM measurement is not precisely 4x the 1-RM measurement. BPP of 512
in dual-RM IR setup interpolated from single being 256 and quad being 1024, however an SGI brochure lists
the dual-RM i-Station as 1024. This is believed to be an error. This brochure also lists some InfiniteReality details
as "greater than" a certain measurement (presumably a conservative estimate). This ">SOMETHING" format is
preserved here. Details for Extreme Graphics are unknown at this time, and should be determined and added.
VTX specs marked "Presumably" are taken from an IR/RE2 comparison with no mention of VTX, and are based
on the single-RM RE2 figure (as VTX is architecturally identical, but has only one RM).

A Note on "RM"
The RealityEngine2, VTX, and InfiniteReality graphics options for the Onyx all utilize a board called the RMx, x being a version. In the case of the RealityEngine2 and VTX, this can be either the RM4 or RM5, whereas InfiniteReality uses one of two variants of the RM6 (RM6-16 or RM6-64). While, in most discussions, this board is referred to simply as the "RM", the meaning of the acronym is less clear than one might imagine. It appears that the majority of Onyx owners, as well as, in many cases, SGI themselves (see their website, circa 1994), refer to the board as the "Raster Manager". However, in the technical papers for both the RealityEngine2 and the InfiniteReality, the authors refer to it as the "Raster Memory" board. Because of this, it appears that, within SGI, there was either disagreement or confusion as to what "RM" stood for. While both would make for the "RM" acronym, it is generally accepted that "Raster Manager" makes more sense (as, while the board does contain memory, it also performs a significant amount of processing, rather than simply storing data).

RealityEngine2
RealityEngine2, often known as "RE2", was, at the time of its release, the highest end graphics option for the Onyx. While it was later repurposed as a lower-end counterpart to the new InfiniteReality, it was originally the most powerful option available. The RealityEngine2 is an improved version of the RealityEngine graphics offered in Crimson and PowerSeries systems, the differentiating factor being the replacement of the eight processor GE8 with the twelve processor GE10. Additionally, the need to terminate Raster Manager boards using a special "terminated" RM4T board (an RM4 with resistors installed in a socket on the board) was removed, with termination now being handled by the system's backplane. The RealityEngine2 consists of three types of board, installed in specialized graphics slots on the backplane.

The GE10 board contains 12 Geometry Engines, at the center of each is an Intel I860XP (not to be confused with the similar but mostly unrelated terms "i386", "x86", "i586", and so-on) RISC processor. While the i860 family of processors never saw use as widespread as hoped, they were found in numerous other niche uses at the time, such as the NeXTcube's NeXTdimension color graphics board, as well as computers from Oki, Stardent, Hauppauge, and Olivetti. It also saw use in Intel's iPSC/860 and Paragon series supercomputers. In the RealityEngine2, these i860XP processors are used to perform geometry calculations for graphics. Each one of these chips has a combined ALU plus floating point performance of 100 megaflops, meaning that, multiplied by the Geometry Engines on the board, each containing one processor, the total compute performance of the GE10 board is 1.2 gigaflops. Each i860XP processor is provided with two megabytes of DRAM. The GE10 also houses the command processor, which is used to control the graphics subsystem and to implement the OpenGL graphics language. The output of these twelve individual geometry engines is transmitted on the Triangle Bus, for use by the RM board. Interestingly, the design of the Triangle Bus on the RealityEngine2's GE10 board is identical to that of said Triangle Bus on the original RealityEngine's GE8 board. While the increased load of the GE10's four extra geometry engines does increase utilization of Triangle Bus bandwidth, the bus was designed to support more than twice the bandwidth required by the original RealityEngine, meaning that in theory, it would work even with 16 Geometry Engines. This meant that the Triangle Bus did not need to upgraded or redesigned during the development of the GE10. The GE10 board does not connect to the edge connector board, and as such installation of a GE10 only requires that the board be inserted into the backplane, like a regular EBus or VME board.

The RM board inputs geometry data from the Triangle Bus, and outputs digital video data to the DG2. The RM board consists of two main types of processor, the Fragment Generator and the Image Engine. Each Raster Manager board consists of five Fragment Generators, with each Fragment Generator driving sixteen Image Engines. While the functionality of the Raster Manager is complex and spans many different tasks (as discussed in the "RealityEngine Graphics" paper, linked below), the basic architecture of the board inputs data from the GE10's triangle bus, before distributing it between five Fragment Generators. The Fragment Generator consists of four ASICs and eight 16 megabit (2 megabyte) DRAM chips, for a total of 16 megabytes per Fragment Generator and 80 megabytes per RM board. The output of the Fragment Generator is then fed into the input of the Image Engine. The RM4 board contains 20 IMP7 Image Engine chips, each of which contains four individual Image Engines. Each one of these IMP7 chips is surrounded by four four megabit (512 kilobyte) DRAM chips, one for each Image Engine inside. The output of these 80 Image Engines is then output to the DG2 board, by way of the edge connector board, which must be installed. The RM4 board provides 40MB of framebuffer memory per board, and adding more RM4 boards can increase this to a total of 160MB (in a four board setup). The RM4 also provides 4MB of texture RAM, though this capacity is not increased by the addition of further RM4 boards. The closely related RM4T is simply an RM4 with some resistors installed in a jumper block towards the rear of the board, for use as a terminated RM4 in a Crimson or PowerSeries system. If installing an RM4T board in an Onyx, these resistors should be removed from the jumper block prior to use, as the Onyx does not require Raster Manager termination. The newer RM5 maintains the same 40MB of framebuffer RAM, but increases texture RAM to 16MB, again not increased when additional boards are installed.

The DG and RM boards must be connected using an edge connector board, installed at the front of the cardcage and connecting all boards below it. The part number of this edge connector is 030-0233-001. This board carries 160 serial, one-bit 50mhz data paths, which together carry the output of the Image Engines to the DG2. In a single-RM system, half of these paths are used, one for each of the 80 Image Engines. In a dual-RM setup, each data path is assigned to a single Image Engine, with all 160 used. In a quad-RM system, these data paths are multiplexed, with each path carrying the output of two Image Engines. This multiplexing is likely the primary reason why a triple-RM system is not possible, as it would require a strange configuration, such as a half-multiplexed, half-direct use of all 160 paths, or some other special-case implementation. With all 160 paths in use, this board provides a bandwidth of 500 megabytes per second.

On the receiving end of the output of the Image Engines is the DG2 board. This board generates the video outputs exposed on the graphics bulkhead's connectors. The data from the Image Engines is first reassembled into what is effectively a digital video signal by ten crossbar ASICs on the DG2, before the image is dithered from 12- to 8-bit color and passed through Digital-to-Analog converters (DACs) for output to the monitor. Like the RM boards, the DG2 board must be connected to the edge connector board. The DG2 board has connectors for the Graphics Bulkhead, which is installed lower in the chassis and connects to it via ribbon cables.

VTX
VTX is a cost-reduced variant of the flagship RealityEngine2 graphics. Architecturally, a VTX subsystem is identical to a RealityEngine2, however it contains half the Geometry Engines and is limited to a single Raster Manager board. While the single RM board and the DG board are identical to those used in a RealityEngine2, VTX replaces the twelve-GE GE10 board with the six-GE GE10V. An SGI Periodic Table from 1993 lists many variants of Onyx in otherwise-identical VTX and RealityEngine2 configurations. This conveniently allows the reader to determine the price of a VTX subsystem relative to a RealityEngine2, as in all cases, systems with VTX graphics cost $40,000 USD less than their RealityEngine2 counterparts. Despite this significant cost saving to the original buyer, it appears that today, at least with regards to systems owned by collectors and those sold on the used market, VTX-powered Onyxes are significantly less common than RealityEngine2 models, perhaps indicating that the lower cost of VTX was not worth the reduced performance to many original buyers. It appears that SGI may have responded to this apparent lack of sales later in the Onyx's life cycle, with late-era Onyx marketing materials usually omitting the option of VTX entirely (though this could also be said to be because of the introduction of the new InfiniteReality graphics subsystem, effectively rendering the once high-end RealityEngine2 the Onyx's budget graphics offering).

InfiniteReality
InfiniteReality is the later of the two flagship graphics options offered for the Onyx. Being the successor to the RealityEngine2, InfiniteReality is the most powerful graphics option available for the Onyx. Like the RealityEngine2 subsystem before it, InfiniteReality consists of three types of board, the GE, DG, and RM. The primary goal of InfiniteReality was to deliver graphics of a quality similar to that of RealityEngine2 at an increased frame rate. A key goal during the development of InfiniteReality's architecture was that it would not only be fully compatible with the Onyx (in addition to the later, higher-bandwidth Onyx2), but that it would be able to utilize most of its performance on both systems. This affected many elements of the boardset's design, from its physical partitioning into GE, RM, and DG boards (so as to fit into the graphics slots in an Onyx), to its use of a display list subsystem with significant architectural changes to that used in the RealityEngine2 (see linked InfiniteReality: A Real-Time Graphics System paper). These architectural changes were necessary to adequately utilize the InfiniteReality in the Onyx, which interfaced with its graphics at a data rate of approximately 200MB/s, in addition to the roughly twice-as-fast Onyx2, which managed 400MB/s.

Like the RealityEngine2, the InfiniteReality uses one GE board, one DG board, and one, two, or four RM boards, connected to the DG via frontplane card-edge connector board. It should be noted that InfiniteReality's RM boards have a greater power consumption than those used in the RealityEngine2, and, as such, only one or two can officially be used in a deskside (while four is limited to a rack). Despite this limitation, it is rumored that, by installing the power boards from a rack system in a deskside, the system could theoretically power four RMs. While it may be possible to provide sufficient power for the additional boards in a deskside, cooling them is still likely to be difficult for the deskside's smaller fans. While a four-RM deskside would certainly be a rare (possibly even unique), powerful, and compact system, those attempting this configuration should exercise extreme caution, understand that they risk severely damaging their system (especially if it seriously overheats), and should understand that this configuration is unsupported and potentially not even possible. Those seeking a reliable, known-good 4-RM InfiniteReality system are advised to look into an Onyx or Onyx2 rack system, where four RMs is an official configuration, and the system already has the necessary cooling and power capacity without any modification.

Like in the RealityEngine2, data moving through the InfiniteReality begins on the GE board. It is accessed from the host system using the Host Interface Processor, which then provides it to the Geometry Distributor. The Geometry Distributor handles distribution of geometry processing workload among the GE board's four Geometry Engines. The Geometry Distributor is capable of distributing data using either a round-robin or least-busy distribution scheme, though least-busy has a slight performance advantage. The Geometry Distributor provides data to the Geometry Engines in the form of commands, each of which contains an identifier assigned by the Geometry Distributor. The Geometry-Raster FIFO buffer later uses these identifiers to reconstruct the order of the commands before they were sent to the Geometry Engines.
Unlike RealityEngine2's twelve Intel i860 XP processors, InfiniteReality uses four custom in-house ASICs. The Geometry Engine chips used by InfiniteReality each contain three cores, meaning that, like it's predecessor's 12 i860 XPs, the InfiniteReality could be said to have twelve processors for geometry (three in each of the four ASICs). However, this analogy should be used with caution. While the RealityEngine2 truly did have 12 Geometry Engines, each three-core InfinteReality ASIC contains only one 2560-word (32-bit words) on-chip memory, shared by all three of its cores. As such, even ignoring the fact that they are no longer on separate chips, the cores that make up an InfiniteReality Geometry Engine are not as independent with regards to memory as the Geometry Engines are on the RealityEngine2 (where each i860 XP has access to 2MB of its own, off-chip DRAM). This single memory for all three cores also allows them to easily share data, if necessary.
At the output of the four Geometry Engines lies the Geometry-Raster FIFO, an SDRAM-based FIFO buffer capable of storing up to 65536 vertices. As stated above, this FIFO is also responsible for properly ordering its data, based on the identifiers assigned by Geometry Distributor.

The data then moves from the GE board to the RM boards, via the Vertex Bus. While the purpose of the Vertex Bus (to carry data between the GE and RM boards) is similar to that of the RealityEngine2's Triangle Bus, it is implemented differently (see paper linked below), resulting in a significant performance improvement. Data sent over the Vertex Bus is broadcast to all Fragment Generators. The InfiniteReality RM board contains a single Fragment Generator and 80 Image Engines. The Fragment Generator is, as was also the case with its predecessor, composed of multiple chips (the SC Scan Converter, TA Texel Address Calculator, eight TM Texture Memory controllers, and four TF Texture Filtering ASICs). Like on the RealityEngine2, data from the GE board is first processed by the Fragment Generator, then by the Image Engines. Because there is only one per RM board, an InfiniteReality RM board's single Fragment Generator uses all 80 of the image engines on the board, unlike on the RealityEngine2, where each of the five Fragment Generators is given 16 of the 80 total Image Engines. The InfiniteReality also continues the trend of combining four individual Image Engines onto a single Image Engine chip, meaning that only 20 Image Engine chips are needed.

Two variants of the Onyx InfiniteReality RM board are available. The RM6-16 has 16MB of Texture RAM (TRAM), while the RM6-64 has 64MB. Each RM board maintains one copy of texture RAM, meaning that, while the amount of physical texture memory in a system increases when additional RM boards are installed, the amount of usable texture memory remains the same, as the memory on the newly-installed RM board(s) is used simply duplicate the data on the existing RM(s). Because each board must retain its own copy of texture RAM, RM6-16 and RM6-64 boards cannot be mixed in a single system (as, having only a quarter the texture memory, an RM6-16 would be unable to store a full copy of the texture memory contents of an RM6-64). Both the RM6-16 and RM6-64 have 80MB of framebuffer RAM per RM board, double the 40MB seen on the RealityEngine2. Unlike TRAM, framebuffer RAM is not duplicated between RM boards, meaning that more RM boards will increase the total amount of framebuffer RAM in the graphics subsystem, up to a maximum of 320MB (with four RM boards).
Like on the RealityEngine2, the output of the RM boards is sent to the DG board via an edge connector board mounted at the front of the cardcage. The edge connector spans the four RMs, connecting to each, and also connects to the DG board, but does not connect to the GE board or any other boards in the cardcage. This edge connector carries 160 serial data paths, the same configuration used in the RealityEngine2, however their use is more flexible on InfiniteReality systems. The RealityEngine2 utilizes one path per Image Engine in one-RM and two-RM configurations, and multiplexes the outputs of each pair of Image Engines onto a single path in a four-RM configuration. This means that, while the video bandwidth of the frontplane is fully utilized in two-RM and four-RM setups, where all 160 paths are driven by at least one Image Engine, single-RM systems utilize only half of the bandwidth, leaving the other 80 paths unused. Though an InfinteReality system also has only 160 paths for its potential 320 Image Engines, it uses them more efficiently in single-RM configurations. While two RMs will assign one path to each of the 160 Image Engines, and four RMs will multiplex the output of 320 Image Engines onto 160 paths, single-RM InfiniteReality systems allow each of the 80 Image Engines to drive two of the 160 data paths on the frontplane, doubling per-Image-Engine bandwidth. Since InfiniteReality systems use all 160 data paths in all configurations, the bandwidth of the InfiniteReality frontplane is a fixed 1200MB/s.

These 160 signals are recieved by four ASICs at the input of the Display Generator board (these ASICs also add the cursor on top of the incoming video). The video is then sent to one of the Display Generator's two or eight (see below) channels. A DG channel is able to resize its video in realtime (e.g. for output as NTSC/PAL video), and can also control the timing of its output. This timing control is the purpose of the Genlock and Swap Ready BNC connectors on the graphics bulkhead, and is discussed in greater depth in the "InfiniteReality: A Real-Time Graphics System" paper linked below. The channel's 12-bit-per-component digital video signal is then passed through 8-bit DACs, which generate the final analog video signal. It should be noted that Channel 1 contains additional hardware, not found on other channels, allowing it to also output composite and S-Video signals.

InfiniteReality's DG4 board is available in two variants. The DG4-2 has two channels, and was the lower-end "standard" option, while the higher-end DG4-8 has eight channels. It should be noted that the DG4-2 PCB has footprints for the components required to provide extra six channels, however, these components are unpopulated. Particularly noticeable are the footprints for the six large BGA chips along the edge of the board, as well as the six QFPs beside them. Towards the middle of the board is a connector for the PAB2 Sirius Video paddleboard, which must be installed if the InfiniteReality boardset is being used alongside a Sirius Video board. The DG4 board has connectors for the Graphics Bulkhead, which is installed lower in the chassis and connects to it via ribbon cables.

Extreme Graphics

Extreme Graphics is the lowest-end graphics option available for the Onyx. It was also available in the Indigo2, where it was the highest-end option until the introduction of IMPACT graphics in 1995. While Extreme Graphics boardsets are relatively common in Indigo2s, they are a rare and largely undocumented option in the Onyx. While it is generally understood that the graphics boardset itself is identical to the one found in an Indigo2, the hardware used to connect it to the Onyx (which does not normally have GIO64 slots) is poorly documented. Further information about the adapters required for this configuration can be found in the "Architecture" section above. The graphics hardware itself is simply a regular Extreme Graphics boardset (see Indigo2). This configuration is rare, and this, combined with the fact that it is rarely mentioned in official SGI documents, is likely the reason for the scarcity of information surrounding it.

I/O

The IO4 I/O Controller implements the basic I/O functions for Onyx systems:

• Ethernet Controller
• two fast/wide 16 bit SCSI-2 controllers
• four serial ports (3x RS232, 1x RS422)
• a parallel port
• two Flat Cable Interfaces (for VME or Graphics)

In Onyx Deskside systems 1 IO4 controller can be installed, in rackmount Onyxes up to 6 of these boards can be installed.

Operating System Support

It is recommended to run IRIX 6.5.22 on all revisions/versions of this machine.

Troubleshooting

No power-on
If a previously working Onyx with no known power supply issues suddenly refuses to power on (specifically no DC GOOD light, no front panel controller functioning) it is possible the Dallas chip located on the System Controller Board (rear access panel of the Onyx) has gone bad. Replacing the Dallas DS12887 with a new production version will allow the system to power on correctly.

Links

• "RealityEngine Graphics" paper: http://www.sgistuff.net/hardware/graphics/documents/K.Akeley-RealityEngine.pdf
• "InfiniteReality: A Real-Time Graphics System" paper: http://people.csail.mit.edu/ericchan/bib/pdf/p293-montrym.pdf