Scheduling Issues

The Nintendo 64 audio and graphics chores are shared between the host CPU and the RCP. The work to be performed is expressed using an array of primitives called a command list.

The host CPU is responsible for command list generation. Audio command lists are generated by calling alAudioFrame(). Graphics command lists are generated by calling the various graphics macros defined in gbi.h. In addition, the host CPU is responsible for assembling command lists into RCP tasks (which consist of command lists, RCP microcode and execution state information), and for downloading the task at the appropriate time to the RCP.

The RCP is responsible for command list processing. The RCP microcode loaded by the host CPU parses the command list, executes the appropriate core rendering routines, and writes the results to the video frame or audio buffer.

Since the video frame buffer must be updated at a regular rate (usually 30 frames per second) and the audio buffers must be updated before they are emptied by the audio DAC to prevent clicks and pops, the application must make schedule the command list generation and processing chores so that they happen in a “timely manner”. This chapter identifies the relevant scheduling issues and describes the libultra Scheduler that addresses them.

Command List Generation
Command lists are usually generated during the frame before they are to be processed. Though command list generation should take less than a frame time to complete, there are infrequent occasions when it may take longer. When the host CPU misses its completion deadline, host overrun is said to have occurred.

The effects of host overruns are usually undesirable. If an audio command list is not ready to be processed during the next frame time, clicks and pops will be introduced into the audio stream. If a graphics command list is not ready to be processed, the video frame buffer will not be updated until the following frame, which may cause the graphics stream to appear “jerky”.

The effects of host overruns on the audio stream can be minimized if the audio and graphics command lists are generated in separate threads. Specifically, if the audio thread runs at a higher priority than the graphics thread, the host CPU can schedule the audio task even though the graphics task may not be completely generated, preventing clicks and pops from being introduced into the audio stream.

Alternately, one could implement a dynamic buffering scheme to prevent overrun by dynamically varying the audio data buffer size to accommodate any graphics overrun. This approach would require somewhat larger buffers and is more difficult to implement since overrun is dependent on things that are not known until runtime.

Note: Calls to alAudioFrame() generate DMA requests, which are assumed to be complete when the audio command list is processed. The DMA latency depends on the operation of the audio DMA callback which is implemented by the application.

Command List Processing
While audio command list processing time is deterministic (based on the number of active voices), the graphics command list processing time is variable (based on the complexity of the scene and the perspective of the viewer). Unless great care is taken in the construction of the graphics command lists, they may require more than a frame time to process. This is call graphics (RCP) overrun.

The effects of graphics overrun can be minimized by suspending the overrunning task and running the waiting audio task at the beginning of a video frame. Graphics tasks can be suspended with the osSpTaskYield() function. See the osSpTaskYield man pages for more information.

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