Several states are global to the RDP, usually to specify pipeline configuration and synchronization.
To configure the pipeline for rendering, choose one of the cycle types that offers the functionality required at peak performance.
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 primitive that follows. 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.
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 (i.e.,. gSP1Triangle, gDPFillRectangle, gSPTextureRectangle) and before an RDP attribute (i.e.,. gDPSet*), you need to insert a gDPPipeSync.
After processing all of the RDP display list, the host processor must be interrupted and notified.
gDPFullSync() also shuts down the RDP until given a new DL to eliminate excessive power consumption.
For RMW (Read/Modify/Write) cycles, the RDP is smart enough to pre-fetch a row of pixels as soon as the X, Y coordinates of the span are determined. The RDP pre-loads the framebuffer content of this span into an RDP on-chip 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 pre-loaded 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 help simplify the explanation.)
The RDP has enough on-chip RAM to hold several span buffers. Therefore, if two spans in succession happened to overlap the same screen area, the RDP would pre-fetch the first span into a span buffer while the pipeline started processing this span. Then it would pre-fetch 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 unless absolutely necessary.