Display List Processing

Understanding the basics of the RSP display list processing is necessary to construct efficient, compact display lists for an application.

The display list (or command list) can be thought of as a hierarchical structure, up to 10 levels deep. A display list may contain a pointer to another display list, and so on. The RSP processes the display list using a stack, pushing and popping the current display list pointer.

For animation, it will be desirable to “double-buffer” parts of the display list; rendering one frame while the data for the next frame is updated. In this case, only the minimum amount of data need be duplicated; only the data which will change for each frame. Swapping between doubled buffers is efficiently done by changing the segment base addresses (and organizing your display list appropriately).

During computation by the RSP, all display lists and their data must remain in the same location until the RSP is finished. This sounds obvious, but is a very common bug, usually the result of incorrect usage of double-buffering techniques. In addition, if the RSP task is interrupted (please see “Section 8.8, "Signal Processor (SP) Functions”), all of the data must remain in the same location when/if the task is restarted.

Connecting Display Lists
Hierarchical display list connection can be made with the gsSPDisplayList() macro. The current display list location is pushed on the display list stack and processing begins with the new display list.

Table 1 gsSPDisplayList(Gfx *dl)

Parameter | Values
dl | pointer to the display list to attach

Branching Display Lists
A display list branch without a push allows you to “chain” together fragments of display lists for more efficient memory utilization.

Table 2 gsSPBranchList(Gfx *dl)

Parameter | Values
dl | pointer to the display list to attach

Ending Display Lists
All display lists must terminate with an “end” command.

Table 3 gsSPEndDisplayList(void)

Parameter | Values
none | none

A Few Words About Optimal Display Lists
The display list processor running on the RSP caches display list commands in groups of about 32. This means the optimal display list size is a multiple of 32. A display list of 33 commands (or 65, etc.) would require the display list cache to be refilled during processing, possibly causing a wait state (depending on the DMA engine activity). Obviously not all display lists can keep the list processor running 100% optimally, but it is something to keep in mind when tuning your application.

Another form of display lists which cause less than optimal processing are display lists that look like the following:

Since the display list engine is stack-based, a display list that has lots of unnecessary indirect pointers will cause lots of unnecessary pushes and pops, which do have a cost.

Constructs like this are unavoidable at times, for example, when sharing geometries among objects. Therefore, when you have a choice try not to group indirect display list pointers together.

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