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, you should "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.1, "Signal Processor (SP) Functions", all of the data must remain in the same location when/if the task is restarted.
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.
| Parameter | Values |
|---|---|
| dl | pointer to the display list to attach |
A display list branch without a push using the gsSPBranchList() macro allows you to "chain" together fragments of display lists for more efficient memory utilization.
| Parameter | Values |
|---|---|
| dl | pointer to the display list to attach |
All display lists must terminate with the gsSPEndDisplayList command.
| Parameter | Values |
|---|---|
| none | none |
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:
![[Figure]](gif/f11-01-00.gif)
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 will bring about an increase of 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.