This chapter explains
When you use the Combiner to set video combinations for InfiniteReality's multichannel capability, you must take into account
DAC output bandwidth
framebuffer memory and read/write bandwidth
These procedures are explained in this section.
All video formats that run together in a video combination must provide time for housekeeping operations such as updating cursor position and glyph, setting parameters for dynamic pixel resampling, and so on. This updating and resampling might be done at field boundaries, frame boundaries, or, in certain cases, across multiple frames. The interval consumed by such housekeeping operations is called the video format's maximum swap rate.
The swap rate must be the same for all video formats in a combination so that the InfiniteReality Video Display subsystem can perform these housekeeping services for all running video formats at the same time. Generally, the 525 formats imply a 60-Hz swap; the 625 formats imply a 50-Hz swap rate.
All of the following formats, which run at 60 Hz, would make up a legal combination:
30-Hz interlaced NTSC (swap rate is the 60 Hz field rate for this format)
60-Hz noninterlaced 1280 x 1024
120-Hz stereo (swap rate is the 60-Hz frame rate)
180-Hz color field sequential (swap rate is the 60-Hz frame rate)
Examples of illegal combinations are NTSC (60-Hz swap rate) and PAL (50-Hz swap rate), or the 60-Hz and 72-Hz versions of 1280 x 1024.
|Note: Although NTSC really runs at 59.94-Hz field rates, it is close enough to be run with 60-Hz 1280 x 1024. In general, if the swap rates are close enough to allow the video formats to be reliably synchronized to one another, they are considered “equal.” This tolerance is usually less than 2 percent.|
The swap rate for the video output format for a channel is displayed in its Channel Attributes window. Consult /usr/gfx/ucode/KONA/dg4/vfo/README for complete information on each format, including its swap rate.
Digital video data is sent serially from the InfiniteReality framebuffer to the video subsystem. Each video channel uses a portion of the system's aggregate video transmission bandwidth. The bandwidth each channel requires depends on the resolution of the video output format running on that channel and on the type of video it receives from the framebuffer. The requirements of all video channels must total less than the aggregate video bandwidth of the system.
Depending on the number and precision of color components requested from the framebuffer by each video channel, the video transmission bandwidth ranges from approximately 290 million pixels per second (for 10-bit RGB or 12-bit color field-sequential video) to 210 million pixels per second (for 10-bit RGBA or 12-bit RGB video). The digital data stream from the framebuffer to a particular video channel must be of a single type and precision, for example, 10-bit RGB. However, different video channels (and their associated digital video streams from the framebuffer) can be mixed: one channel can request 10-bit RGB, another channel can request 12-bit RGB, and yet another channel can request 10-bit RGBA.
The transmission format for video is not the same as the depth of pixels in the framebuffer. Pixel depth (Small, Medium, Large, X–Large) must be uniform across the entire managed area of the framebuffer. As explained in the preceding paragraph, the format of the colors transmitted as video from the framebuffer to the video display subsystem can vary for each channel to conserve the aggregate video transmission bandwidth.
Framebuffer memory stores a lot of nonvideo information about each pixel (like multisample and Z information); the color fields are a subset of the framebuffer pixel storage. Thus, it is important to distinguish between the framebuffer representation of pixels and the format selected for video transmission to the video display subsystem so as to understand and optimize the performance of both the framebuffer memory and the video display subsystem.
|Note: The total framebuffer-to-video-subsystem bandwidth is independent of the number of RM boards in the system.|
The DACs of the first two video channels, 0 and 1, have a bandwidth limit of 220 million pixels per second; the remaining six have a bandwidth limit of 170 million pixels per second. Because of each channel's dynamic resampling capability, the actual video resolution as output by the DAC (and seen by the display monitor connected to the channel) can be higher than the resolution of the rectangular region of the framebuffer assigned to that channel. Therefore, in a video format combination, always assign the video formats with the highest bandwidth video to Channels 0 and 1.
Dynamic resampling can be used to statically resample a region of the framebuffer area, allowing a smaller region of the framebuffer to be enlarged (zoomed) to fit the resolution of the video format of the video channel assigned to that region of the framebuffer. This feature facilitates efficient use of framebuffer memory without requiring nonstandard video formats.
A video format combination must all be able to tile rectangular subregions of a rectangular framebuffer. Depending on the depth of the pixels selected and the number of RM boards installed, some combinations can require more than one RM board. When specifying the framebuffer pixel depth, take into account the quality of multisampling, the precision of the z-buffer, RGB component resolution, and total fill-rate requirement of the application.
Although adding RM boards does not increase the total framebuffer-to-video subsystem bandwidth, it does increase the total drawing fill rate available and amortizes the video refresh overhead over the additional RM boards, leaving more fill capacity available for drawing.
Finally, refreshing the video channels entails considerable overhead for the framebuffer. The greater the number and resolution of video channels, the more the pixel fill rate of the framebuffer is reduced. A particular combination of formats might fit into a one- or two-RM configuration, but it also might reduce the fill rate unacceptably.
If the combination uses too much bandwidth, you can reduce the size of the input image, but what is sent to the monitor is not changed. This technique is useful if you are using a fixed-frequency monitor that supports only certain formats.
The InfiniteReality system software includes an Emergency Backup Combination (EBC). If the system software cannot load a combination during the boot process because the combination saved to the EEPROM is not valid (for example, if it exceeds the capacity of the system), it uses the EBC.
The EBC is a video format combination consisting of the minimum configuration possible: one RM board, two channels, no option boards, and one video format, 1280x1024_60, on Channel 0. This file is editable only by Silicon Graphics engineering personnel.
If the InfiniteReality system is using the EBC, load the EEPROM with a combination you prefer:
In the File menu, select “Open...” and specify the filename.
In the File menu, select “Save to EEPROM...”.