Overview

The Reality Display Processor (RDP) rasterizes triangles and rectangles, and produces high-quality, Silicon Graphics style pixels that are textured, antialiased, and z-buffered.

The RDP has four main configurations where all the individual blocks work together to generate pixels. These main configurations are called “cycle types,” because they indicate how many pixels are generated per cycle. Keep in mind that these peak numbers are typically realized on large rectangle primitives. Triangles have variable short and long spans and these numbers degrade rapidly. The following table lists the RDP’s performance.

Table 1 Cycle Types

Type | Performance
FILL | 4 16 bit pixels/cycle 2 32 bit pixels/cycle
COPY | 4 pixels/cycle
1CYCLE | 1 pixel/cycle
2CYCLE | 1 pixel/2 cycles

Note: These are theoretical peak performances. In reality, due to the memory latency and buffering overhead, actual performance numbers are lower.

RDP Pipeline Blocks
The RSP performs 3D geometric transformations while the RDP pipeline rasterizes the polygon. The RDP consist of several pipeline subblocks. There are six major logical RDP blocks: the RS, TX, TF, CC, BL, and MI. The connections between these blocks can be reconfigured to the four cycle types listed in Table 12-1, to perform different rasterization operations.

Table 2 Basic Operations of RDP Subblocks

Block | Functionality
RS | The RaSterizer generates pixel coordinates and their attributes’ slopes. Pixel coordinates consist of X and Y. Attributes consist of R, G, B, A, Z, S/W, T/W, 1/W, L, pixel coverage.
TX | The TeXturizing unit contains texture memory and samples the texture, based on which texel represents the pixel being processed in the pipeline.
TF | The Texture Filter performs a 4-to-1 bilinear filter of 4 texel samples to produce a single bilinear filtered texel.
CC | The Color Combiner performs general blending of color sources by linearly interpolating between two colors with a coefficient. For example, it may take the filtered texel samples and the shading color (RGBA) and combine them together.
BL | The BLender blends the pipeline-processed pixels with the pixels in the framebuffer. The blender can do transparencies and also sophisticated antialiasing operations.
MI | The Memory Interface performs the actual read/modify/write cycles to and from the framebuffer.

Note: The six RDP blocks (RS, TX, TF, CC, BL, and MI) are purely logical blocks. For example, the hardware implementation of RS consist of several blocks. However, for programming, each can be treated as a single logical block.

One-Cycle-per-Pixel Mode
The pipeline configuration illustrated in Figure 12.1.1 shows how the RDP blocks are connected in one-cycle-per-pixel mode.

Figure 12.1.1 One-Cycle Mode RDP Pipeline Configuration

Table 3 RDP Pipeline Block Functionality in One-Cycle Mode

Block | Functionality
RS | Generates pixel and its attribute covered by the interior of the primitive.
TX | Generates 4 texels nearest to this pixel in a texture map.
TF | Bilinear filters 4 texels into 1 texel, or performs step 1 of YUV-to-RGB conversion.
CC | Combines various colors into a single color, or performs step 2 of YUV-to-RGB conversion.
BL | Blends the pixel with framebuffer memory pixel, or fogs the pixel for writing to framebuffer.
MI | Fetches and writes pixels from and to the framebuffer memory.

One-cycle mode fills a fairly high-quality pixel. You can generate pixels that are perspectively corrected, bilinear filtered, modulate/decal textured, transparent, and z-buffered, at one-cycle-per-pixel peak bandwidth.

Note: Reaching peak bandwidth is difficult. The framebuffer memory is organized in row order. In small triangles, it is rare to have long horizontal runs of pixels on a single scanline. In these cases, the pipeline is often stalled, pending memory access for read or write cycles.

Two-Cycles-per-Pixel Mode
The RDP blocks can be reconfigured into a two-cycle-per-pixel pipeline structure for additional functionality. Figure 12.1.2 shows the RDP pipeline in 2-cycle mode where one pixel is generated every 2 clocks.

Figure 12.1.2 Two Cycle Mode RDP Pipeline Configuration

Table 4 RDP Pipeline Block Functionality for Two-Cycle Mode

Block | Functionality
RS | Generates a pixel and its attribute covered by the interior of the primitive.
TX0 | Generates 4 texels nearest to this pixel in a texture map. This can be level X of a mipmap.
TX1 | Generates 4 texels nearest to this pixel in a texture map. This can be level X+1 of a mipmap.
TF0 | Bilinear; filters 4 texels into 1 texel.
TF1 | Bilinear; filters 4 texels into 1 texel, or step 1 of YUV-to-RGB conversion.
CC0 | Combines various colors into a single color, OR linear interpolates the 2 bilinear filtered texels from 2 adjacent levels of a mipmap, OR performs step 2 of YUV-to-RGB conversion.
CC1 | Combines various colors into a single color, OR chroma keying.
BL0 | Combines fog color with resultant CC1 color.
BL1 | Blends the pipeline pixels with framebuffer memory pixels.
MI0 | Read/modify/write color memory.
MI1 | Read/modify/write Z memory.

Two-cycles-per-pixel mode contains more features than one-cycle- per-pixel mode. In addition to all of the features of one-cycle mode, two-cycle mode can also do mipmapping and fog.

Note: MI0 and MI1 represent two cycles of the MI that access color and z framebuffer cycles, respectively. This is only a logical representation. The MI does not need to run two cycles to perform color and z-buffer access. One cycle per pixel mode can also perform color and z-buffer accesses. The reason for this representation is to show that two MI access cycles are balanced in the two-cycle mode. In one-cycle mode, the pipeline is often stalled at MI, waiting for the framebuffer when accessing both color and z.

These RDP blocks are very flexible and can be configured to do many things. Table 12-4 outlines the typical usage of these blocks for a powerful rasterization pipeline. Study the following sections to understand what attribute state is programmable within each RDP block to master the raster subsystem.

Fill Mode
For high-performance framebuffer clearing, the RDP has a fill mode, which can fill 64 bits per clock. A programmable RDP color attribute is written into the framebuffer during each 64-bit write cycle. The RDP arithmetic pipeline is largely unused, because the computation can not keep up with the pixel fill rate. The fill mode is most commonly used for clearing color and z-buffers.

Note: In fill mode, use the render mode g*DPSetRenderMode(G_RM_NOOP, G_RM_NOOP2) to put the blender into a safe state. Attempting to read Z when in fill mode can cause the RDP pipeline to hang.

Copy Mode
For high-performance image-to-image copies, RDP also supports a copy mode that can copy 64 bits or 4 pixels per clock. The RDP texture memory in the TX is just a buffer capable of holding up to 4 KB worth of image pixels. You can load bitmaps into this buffer as well as writing back out to the framebuffer. The is a common bit blit operation that many 2D graphics hardware systems support. Once again, the RDP arithmetic pipeline is largely unused in copy mode. One important operation that does work in copy mode is alpha compare. This allows RDP to blit an image into the framebuffer and conditionally remove image pixels with alpha = 0. Usually, images with alpha = 0 represent transparency. Please see Section 15.5.4, “Alpha Compare Calculation” for additional information.

In copy mode, use the render mode g*DPSetRenderMode(G_RM_NOOP, G_RM_NOOP2) to put the blender into a safe state.

Copyright © 1999 Nintendo of America Inc. All Rights Reserved Nintendo and N64 are registered trademarks of Nintendo Last Updated January, 1999