RDP Global State

Several state are global to the RDP, usually to specify pipeline configuration and synchronization.

Cycle Type
To configure the pipeline for rendering, choose one of the cycle types that offers the functionality required at peak performance.

Table 1  gsDPSetCycleType(type)
Parameter Values
type G_CYC_1CYCLE
G_CYC_2CYCLE
G_CYC_COPY
G_CYC_FILL

Synchronization
You might ask �How does the primitive rendering pipeline synchronize with all of the different attribute states that the programmer can set?� Imagine that the last few pixels are being processed in the RDP pipeline when it receives a new attribute command, and this command affects the pixel currently being processed. You would not want the last few pixels of a primitive to have the attributes of a following primitive. You really want to have the attribute state only to modify the pixels of the primitive following the attribute state change. This synchronization is not implicit within the pipeline; the application must explicitly insert proper synchronization between attribute state changes and primitives.

Table 2  gsDPPipeSync()
Parameter Values
none none

This command synchronizes the attribute update with respect to primitive rendering. It ensures that the last pixels of a primitive are rendered prior to the attribute taking effect. Insert this in between an RDP primitive followed by an RDP attribute:

gDPSetCycleType(glistp++, G_CYC_FILL);
gDPFillRectangle(glistp++, 0, 0, 127, 127);
gDPPipeSync(glistp++);
gDPSetCycleType(glistp++, G_CYC_1CYCLE);

Note: After a primitive (eg. gSPTriangle, gDPFillRectangle, gDPTextureRectangle) and before an RDP attributes (eg. gDPSet*), you need to insert a gDPPipeSync.

After processing all of the RDP display list, the host processor must be interrupted and notified.

Table 3  gsDPFullSync()
Parameter Values
none none

gDPFullSync() also shuts down the RDP until given a new DP DL to eliminate excessive power consumption.

Span Buffer Coherency
For RMW cycles, the RDP is smart enough to prefetch a row of pixels as soon as the X, Y coordinates of the span are determined. The RDP preloads the framebuffer content of this span into an RDP onchip span buffer. The RDP then waits for the pipeline to process the parameters for the outgoing pixels. When the outgoing pixels are computed, they are �combined� with the preloaded framebuffer pixels before writing back to the framebuffer.

An example of this operation is z-buffer and transparency blending. (This was not shown in the logical pipeline description, to simplify the understanding of the pipeline.)

The RDP has enough onchip RAM to hold several span buffers. Therefore, if two spans in sequence happened to overlap the same screen area, the RDP would prefetch the first span into a span buffer while the pipeline starts processing this span. Then it would prefetch the next span into another span buffer.

This is where the problems occur: the pixel data for the next span is not yet computed. The RDP does have span buffer coherency, at the cost of some performance. If errors are objectionable in your animation, use gsDPPipelineMode(G_PM_1PRIMITIVE) to cause all primitives to add between 30 to 40 null cycles after the last span of a primitive is rendered. These dead cycles can be expensive in terms of fill rate so it is recommended not to use the 1PRIMITIVE mode be used unless absolutely necessary.

Table 4  gsDPPipelineMode(mode)
Parameter Values
mode G_PM_1PRIMITIVE
G_PM_NPRIMITIVE

These dead cycles can be expensive in terms of fill rate so it is recommended not to use the 1PRIMITIVE mode be used unless absolutely necessary.

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