Graphics system interface

Abstract

An interface for a graphics system includes simple yet powerful constructs that are easy for an application programmer to use and learn. Features include a unique vertex representation allowing the graphics pipeline to retain vertex state information and to mix indexed and direct vertex values and attributes; a projection matrix value set command; a display list call object command; and an embedded frame buffer clear/set command.

Claims

We claim:

1. A graphics system command stream for use in a graphics system having an internal frame buffer and plurality of pixel engine registers within a graphics pipeline, the graphics system command stream being operable upon execution to set said internal frame buffer, said graphics system command stream comprising:

a stream command 0x614F providing access to said registers and defining a pixel engine copy clear alpha/red command that designates a first register of said plurality of pixel engine registers which contains an alpha value and a red value, herein said first register includes a 1-byte pad, a 1-byte alpha value and a 1-byte red value;

a stream command 0x6150 providing access to said registers and defining a pixel engine copy clear greenlblue command that designates a second regis er of said plurality of pixel engine registers which contains a green value and a blue value, wherein said second register includes a 1-byte pad, a 1-byte green value and a 1-byte blue value; and

a stream command 0x6151 providing access to said registers and defining a pixel engine copy clear z command that designates a third register of said plurality of pixel engine registers which contains a 24-bit z value,

wherein upon execution of the graphics command stream the embedded frame buffer is set with said alpha value, said red value, said green value, said blue and said z value.

2. A computer readable storage medium encoded with an executable command stream for use in a graphics system having an internal frame buffer and plurality of pixel engine registers within a graphics pipeline, the grapics system command stream being operable upon execution to set said internal frame buffer, said storage medium comprising:

a stream command 0x614F providing access to said registers and defining a pixel engine copy clear alpha/red command that designates a first register of said plurality of pixel engine registers which contains an alpha value and a red value, herein said first register includes a 1-byte pad, a 1-byte alpha value and a 1-byte red value;

a stream command 0x6150 providing access to said registers and defining a pixel engine copy clear green/blue command that designates a second register of said plurality of pixel engine registers which contains a green value and a blue value, wherein said second register includes a 1-byte pad, a 1-byte green value and a 1-byte blue value; and

a stream command 0x6151 providing access to said registers and defining a pixel engine copy clear z command that designates a third register of said plurality of pixel engine registers which contains a 24-bit z value,

wherein upon execution of the graphics command stream the embedded frame buffer is set with said alpha value, said red value, said green value, said blue and said z value.

3. For use in a graphics system having an internal frame buffer and plurality of pixel engine registers within a graphics pipeline, a method of setting said internal frame buffer using a graphics system command stream, said method comprising:

generating a stream command 0x614F which provides access to said registers and defines a pixel engine copy clear alpha/red command that designates first register of said plurality of pixel engine registers which contains an alpha value and a red value, wherein said first register includes a 1-byte pad, a 1-byte alpha value and a 1-byte red value;

generating a stream command 0x6150 which provides access to said registers and defines a pixel engine copy clear green/blue command that designate a second register of said plurality of pixel engine registers which contains a green value and a blue value, wherein said second register includes a 1-byte pad, a 1-byte green val e and a 1-byte blue value; and generating a stream command 0x6151 which provides access to said registers and defines a pixel engine copy clear z command that designates a third register of said plurality of pixel engine registers which contains a 24-bit z value,

wherein upon generation of the command stream the embedded frame buffer is set with said alpha value, said red value, said green value, said blue and said z value.

4. A graphics command stream decoder for use in a graphics system having an internal frame buffer and plurality of pixel engine registers within a graphics pipeline, the decoder being operable to set said internal frame buffer, said decoder comprising:

a first decoding section decoding a stream command 0x614F providing access to said registers and defining a pixel engine copy clear alpha/red command that designates a first register of said plurality of pixel engine registers which contains an alpha value and a red value, wherein said first register includes a 1-byte pad, a 1-byte alpha value and a 1-byte red value;

a second decoding section decoding a stream command 0x6150 providing access to said registers and defining a pixel engine copy clear green/blue command that designates a second register of said plurality of pixel engine registers which contains a green value and a blue value, wherein said second register includes a 1-byte pad, a 1-byte green value and a 1-byte blue value; and

a third decoding section decoding a stream command 0x6151 providing access to said registers and defining a pixel engine copy clear z command that designates a third register of said plurality of pixel engine registers which contains a 24 bit z value,

wherein the embedded frame buffer is set by said decoder with said alpha value, said red value, said green value, said blue and said z value.

Description

FIELD OF THE INVENTION

The present invention relates to computer graphics, and more particularly to interactive graphics systems including but not limited to home video game platforms. Still more particularly this invention relates to an advantageous software programming interface including binary command functions for controlling a graphics chip and to methods for generating, storing and decoding same.

BACKGROUND AND SUMMARY OF THE INVENTION

Many of us have seen films containing remarkably realistic dinosaurs, aliens, animated toys and other fanciful creatures. Such animations are made possible by computer graphics. Using such techniques, a computer graphics artist can specify how each object should look and how it should change in appearance over time, and a computer then models the objects and displays them on a display such as your television or a computer screen. The computer takes care of performing the many tasks required to make sure that each part of the displayed image is colored and shaped just right based on the position and orientation of each object in a scene, the direction in which light seems to strike each object, the surface texture of each object, and other factors.

Because computer graphics generation is complex, computer-generated three-dimensional graphics just a few years ago were mostly limited to expensive specialized flight simulators, high-end graphics workstations and supercomputers. The public saw some of the images generated by these computer systems in movies and expensive television advertisements, but most of us couldn't actually interact with the computers doing the graphics generation. All this has changed with the availability of relatively inexpensive 3D graphics platforms such as, for example, the Nintendo 64.RTM. and various 3D graphics cards now available for personal computers. It is now possible to interact with exciting 3D animations and simulations on relatively inexpensive computer graphics systems in your home or office.

A problem graphics system designers confronted in the past was how to provide a control interface for a graphics system that enables fast, efficient and flexible use of the graphics system by applications designed to be executed thereon. Various application programming interfaces (APIs) and application binary interfaces (ABIs) have been developed in the past for the purpose of enabling graphics application programmers to control the operation of a graphics chip provided in a graphics system. Perhaps the most commonly-used 3D graphics application programming interfaces in current use are Microsoft's Direct3D interface and the OpenGL interface developed through cooperation with Silicon Graphics. See, for example, Kovach, Inside Direct3D: The Definitive Guide to Real-Time 3D Power and Performance for Microsoft Windows (Microsoft Press 2000); and Neider et al., OpenGL Programming Guide: The Official Guide to Learning OpenGL Release 1 (Addison-Wesley Publishing Co. 1993).

As explained in the Kovach book, Microsoft's DirectX application programming interface (API) provides a set of interfaces offering efficient control of multimedia hardware on a computer running Microsoft Windows. Kovach states that DirectX lets programmers work with commands and data structures that are very close to those that the hardware can natively process, without being so low level that code has to be written differently for each device. By writing device-independent code, programmers can create software that will theoretically always perform at its best (according to Kovach)--even as users enhance their systems with new and improved 3D graphics accelerators, sound cards, input devices and other system capabilities.

Kovach explains that the device-independence of DirectX is obtained because the DirectX APIs are built on a hardware abstraction layer (HAL) that hides the device-specific dependencies of the hardware. In fact, DirectX defines some hardware acceleration support features that aren't available on much of the hardware built today in order to provide extensibility for the future.

While the DirectX approach has been widely adopted and is successful in providing compatibility across a wide range of different platform configurations, the use of a thick hardware abstraction layer and associated hardware emulation layer is not particularly suitable for current low cost dedicated video game platforms at the current time. The DirectX API was primarily designed for personal computers costing many hundreds or thousands of dollars and manufactured in a variety of different configurations and permutations. While the DirectX API has been successful in providing compatibility across a wide range of such different platform configurations, this compatibility has come at the expense of efficiency and performance. In the context of a dedicated low-cost video game platform, it is possible to do much better in terms of providing a fully capable programming interface that is very close to the hardware while providing a highly capable and flexible interface for achieving a wide variety of interesting 3-dimensional graphics effects.

One prior approach is described in U.S. patent application Ser. No. 08/990,133 filed Dec. 12, 1997 by Van Hook et al., entitled "Interface For A High Performance Low Cost Video Game System With Coprocessor Providing High Speed Efficient 3D Graphics And Digital Audio Signal Processing." However, further improvements are possible and desirable. In particular, some people criticized the interface described in this prior Van Hook et al., patent application because they thought it was difficult to write applications to. In the home video game arena, it is desirable to maximize performance while keeping the interface used to invoke and control such performance and capabilities as simple and easy to use as possible. Requiring application programmers to write to an unduly complicated interface may increase the time it takes to develop such applications. This can have devastatingly negative effects when it comes time to launch a new video game platform--since the success of the platform may often depend on achieving a certain "critical mass" in terms of the number of games or other applications available at launch time. As some developers of prior new home video game platforms found out, no one wants to buy a new video game system if there are no games to play on it. It is therefore desirable to provide a graphics programming interface that is simple and easy to use and yet is very powerful and flexible.

The present invention solves this problem by providing new and improved interface for graphics systems that is designed to be as thin as possible in order to achieve high performance, while also providing a logical and orthogonal view of the graphics hardware.

The present invention provides a graphics system programming interface with graphics commands allowing geometry to be rendered with many attributes. The interface provides two main methods for drawing geometry. An immediate mode allows the command stream source to send a stream of graphics commands directly to the graphics processor for consumption. This immediate mode interface is useful when the main processor must synthesize geometry data from a higher-level description (e.g., a height field or Bezier patch). The second method feeds a command stream to the graphics processor using a memory-resident display list format. This interface provides superior performance for static data. The immediate interface and the display list interface both support configurable vertex representations. The configurable vertex representations include, for example, direct or indexed vertex components. Vertex components (e.g., position, normal, color and texture coordinates for a number of textures) can all be indexed independently from arrays, or placed directly in the command stream. Additional flexibility is provided by allowing each vertex component to have a differently-sized representation and precision. The available direct types may include, for example, 8-bit signed and unsigned integer, 16-bit signed and unsigned integer, and 32-bit floating point. A scale is available to position the decimal point for the integer types. The indirect types (e.g., 8-bit index or 16-bit index) can be used to index into an array of any of the direct types. This flexible representation allows the game developer to organize vertex data in a way that is appropriate for the game. The ability to index each component separately eliminates a great deal of data duplication.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages provided by the invention will be to better and more completely understood by referring to the following detailed description of presently preferred embodiments in conjunction with the drawings, of which:

FIG. 1 is an overall view of an example interactive computer graphics system;

FIG. 2 is a block diagram of the FIG. 1 example computer graphics system;

FIG. 3 is a block diagram of the example graphics and audio processor shown in FIG. 2;

FIG. 4 is a block diagram of the example 3D graphics processor shown in FIG. 3;

FIG. 5 is an example logical flow diagram of the FIG. 4 3D graphics processor;

FIG. 6 is a general flow chart of functions performed by an example application for the FIG. 1 graphics system;

FIG. 7 is a flow chart showing the functions of FIG. 6 in more detail;

FIG. 8 shows example simple graphics command stream;

FIG. 9 shows an example binary level interface for setting the embedded color and depth buffer of the FIG. 1 system to a particular (e.g., initial) value;

FIG. 9A shows example pixel engine copy clear register formats;

FIG. 10 shows an example vertex data structure hierarchy including example description information;

FIG. 11 shows an example binary level interface defining a vertex attribute array;

FIG. 12 shows an example binary level interface defining a vertex descriptor;

FIGS. 13A and 13B together show an example binary level interface defining a vertex attribute table;

FIG. 14 schematically illustrates an example vertex attribute format table;

FIG. 15 shows example graphics primitives that may be represented using the vertex data structures herein;

FIG. 16 shows an example binary level interface defining a projection matrix;

FIG. 17 shows an example binary level interface defining a display list to be called; and

FIGS. 18A and 18B show example alternative compatible implementations.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION

FIG. 1 shows an example interactive 3D computer graphics system 50. System 50 can be used to play interactive 3D video games with interesting stereo sound. It can also be used for a variety of other applications.

In this example, system 50 is capable of processing, interactively in real time, a digital representation or model of a three-dimensional world. System 50 can display some or all of the world from any arbitrary viewpoint. For example, system 50 can interactively change the viewpoint in response to real time inputs from handheld controllers 52a, 52b or other input devices. This allows the game player to see the world through the eyes of someone within or outside of the world. System 50 can be used for applications that do not require real time 3D interactive display (e.g., 2D display generation and/or non-interactive display), but the capability of displaying quality 3D images very quickly can be used to create very realistic and exciting game play or other graphical interactions.

To play a video game or other application using system 50, the user first connects a main unit 54 to his or her color television set 56 or other display device by connecting a cable 58 between the two. Main unit 54 produces both video signals and audio signals for controlling color television set 56. The video signals are what controls the images displayed on the television screen 59, and the audio signals are played back as sound through television stereo loudspeakers 61L, 61R.

The user also needs to connect main unit 54 to a power source. This power source may be a conventional AC adapter (not shown) that plugs into a standard home electrical wall socket and converts the house current into a lower DC voltage signal suitable for powering the main unit 54. Batteries could be used in other implementations.

The user may use hand controllers 52a, 52b to control main unit 54. Controls 60 can be used, for example. to specify the direction (up or down, left or right, closer or further away) that a character displayed on television 56 should move within a 3D world. Controls 60 also provide input for other applications (e.g., menu selection, pointer/cursor control, etc.). Controllers 52 can take a variety of forms. In this example, controllers 52 shown each include controls 60 such as joysticks, push buttons and/or directional switches. Controllers 52 may be connected to main unit 54 by cables or wirelessly via electromagnetic (e.g., radio or infrared) waves.

To play an application such as a game, the user selects an appropriate storage medium 62 storing the video game or other application he or she wants to play, and inserts that storage medium into a slot 64 in main unit 54. Storage medium 62 may, for example, be a specially encoded and/or encrypted optical and/or magnetic disk that stores commands for graphics and audio processor 114 and/or instructions controlling main processor 110 to develop such commands. The user may operate a power switch 66 to turn on main unit 54 and cause the main unit to begin running the video game or other application based on the software stored in the storage medium 62. The user may operate controllers 52 to provide inputs to main unit 54. For example, operating a control 60 may cause the game or other application to start. Moving other controls 60 can cause animated characters to move in different directions or change the user's point of view in a 3D world. Depending upon the particular software stored within the storage medium 62, the various controls 60 on the controller 52 can perform different functions at different times.

Example Electronics of Overall System

FIG. 2 shows a block diagram of example components of system 50. The primary components include:

a main processor (CPU) 110,

a main memory 112, and

a graphics and audio processor 114.

In this example, main processor 110 (e.g., an enhanced IBM Power PC 750) receives inputs from handheld controllers 108 (and/or other input devices) via graphics and audio processor 114. Main processor 110 interactively responds to user inputs, and executes a video game or other program supplied, for example, by external storage media 62 via a mass storage access device 106 such as an optical disk drive. As one example, in the context of video game play, main processor 110 can perform collision detection and animation processing in addition to a variety of interactive and control functions.

In this example, main processor 110 generates 3D graphics and audio commands and sends them to graphics and audio processor 114. The graphics and audio processor 114 processes these commands to generate interesting visual images on display 59 and interesting stereo sound on stereo loudspeakers 61R, 61L or other suitable sound-generating devices.

Example system 50 includes a video encoder 120 that receives image signals from graphics and audio processor 114 and converts the image signals into analog and/or digital video signals suitable for display on a standard display device such as a computer monitor or home color television set 56. System 100 also includes an audio codec (compressor/decompressor) 122 that compresses and decompresses digitized audio signals and may also convert between digital and analog audio signaling formats as needed. Audio codec 122 can receive audio inputs via a buffer 124 and provide them to graphics and audio processor 114 for processing (e.g., mixing with other audio signals the processor generates and/or receives via a streaming audio output of mass storage access device 106). Graphics and audio processor 114 in this example can store audio related information in an audio memory 126 that is available for audio tasks. Graphics and audio processor 114 provides the resulting audio output signals to audio codec 122 for decompression and conversion to analog signals (e.g., via buffer amplifiers 128L, 128R) so they can be reproduced by loudspeakers 61L, 61R.

Graphics and audio processor 114 has the ability to communicate with various additional devices that may be present within system 100. For example, a parallel digital bus 130 may be used to communicate with mass storage access device 106 and/or other components. A serial peripheral bus 132 may communicate with a variety of peripheral or other devices including, for example:

a programmable read-only memory and/or real time clock 134,

a modem 136 or other networking interface (which may in turn connect system 100 to a telecommunications network 138 such as the Internet or other digital network from/to which program instructions and/or data can be downloaded or uploaded), and

flash memory 140.

A further external serial bus 142 may be used to communicate with additional expansion memory 144 (e.g., a memory card) or other devices. Connectors may be used to connect various devices to busses 130, 132, 142.

Example Graphics and Audio Processor

FIG. 3 is a block diagram of an example graphics and audio processor 114. Graphics and audio processor 114 in one example may be a single-chip ASIC (application specific integrated circuit). In this example, graphics and audio processor 114 includes:

a processor interface 150,

a memory interface/controller 152,

a 3D graphics processor 154,

an audio digital signal processor (DSP) 156,

an audio memory interface 158,

an audio interface and mixer 160,

a peripheral controller 162, and

a display controller 164.

3D graphics processor 154 performs graphics processing tasks. Audio digital signal processor 156 performs audio processing tasks. Display controller 164 accesses image information from main memory 112 and provides it to video encoder 120 for display on display device 102. Audio interface and mixer 160 interfaces with audio codec 122, and can also mix audio from different sources (e.g., streaming audio from mass storage access device 106, the output of audio DSP 156, and external audio input received via audio codec 122). Processor interface 150 provides a data and control interface between main processor 110 and graphics and audio processor 114.

Memory interface 152 provides a data and control interface between graphics and audio processor 114 and memory 112. In this example, main processor 110 accesses main memory 112 via processor interface 150 and memory interface 152 that are part of graphics and audio processor 114. Peripheral controller 162 provides a data and control interface between graphics and audio processor 114 and the various peripherals mentioned above. Audio memory interface 158 provides an interface with audio memory 126.

Example Graphics Pipeline

FIG. 4 shows a more detailed view of an example 3D graphics processor 154. 3D graphics processor 154 includes, among other things, a command processor 200 and a 3D graphics pipeline 180. Main processor 110 communicates streams of data (e.g., graphics command streams and display lists) to command processor 200. Main processor 110 has a two-level cache 112 to minimize memory latency, and also has a write-gathering buffer 111 for uncached data streams targeted for the graphics and audio processor 114. The write-gathering buffer 111 collects partial cache lines into full cache lines and sends the data out to the graphics and audio processor 114 one cache line at a time for maximum bus usage.

Command processor 200 receives display commands in binary format from main processor 110 and parses and decodes them--obtaining any additional data necessary to process them from shared memory 112. The command processor 200 provides a stream of vertex commands to graphics pipeline 180 for 2D and/or 3D processing and rendering. Graphics pipeline 180 generates images based on these commands. The resulting image information may be transferred to main memory 112 for access by display controller/video interface unit 164--which displays the frame buffer output of pipeline 180 on display 102.

FIG. 5 is a logical flow diagram of graphics processor 154. Main processor 110 may store graphics command streams 210, display lists 212 and vertex arrays 214 in main memory 112, and pass pointers to command processor 200 via bus interface 150. The main processor 110 stores graphics commands in one or more graphics first-in-first-out (FIFO) buffers 210 it allocates in main memory 110 or elsewhere. The command processor 200 fetches:

command streams from main memory 112 via an on-chip FIFO memory buffer 216 that receives and buffers the graphics commands for synchronization/flow control and load balancing,

display lists 212 from main memory 112 via an on-chip call FIFO memory buffer 218, and

vertex attributes from the command stream and/or from vertex arrays 1000 in main memory 112 via a vertex cache 220.

Command processor 200 performs command processing operations 200a that convert attribute types to floating point format, and passes the resulting complete vertex polygon data to graphics pipeline 180 for rendering/rasterization. A programmable memory arbitration circuitry 130 (see FIG. 4) arbitrates access to shared main memory 112 between graphics pipeline 180, command processor 200 and display controller/video interface unit 164.

FIG. 4 shows that graphics pipeline 180 may include:

a transform unit 300,

a setup/rasterizer 400,

a texture unit 500,

a texture environment unit 600, and

a pixel engine 700.

Transform unit 300 performs a variety of 2D and 3D transform and other operations 300a (see FIG. 5). Transform unit 300 may include one or more matrix memories 300b for storing matrices used in transformation processing 300a. Transform unit 300 transforms incoming geometry per vertex from object space to screen space; and transforms incoming texture coordinates and computes projective texture coordinates (300c). Transform unit 300 may also perform polygon clipping/culling 300d. Lighting processing 300e also performed by transform unit 300b provides per vertex lighting computations for up to eight independent lights in one example embodiment. Transform unit 300 can also perform texture coordinate generation (300c) for embossed type bump mapping effects, as well as polygon clipping/culling operations (300d).

Setup/rasterizer 400 includes a setup unit which receives vertex data from transform unit 300 and sends triangle setup information to one or more rasterizer units (400b) performing edge rasterization, texture coordinate rasterization and color rasterization.

Texture unit 500 (which may include an on-chip texture memory (TMEM) 502) performs various tasks related to texturing including for example:

retrieving textures 504 from main memory 112,

texture processing (500a) including, for example, multi-texture handling, post-cache texture decompression, texture filtering, embossing, shadows and lighting through the use of projective textures, and BLIT with alpha transparency and depth,

bump map processing for computing texture coordinate displacements for bump mapping, pseudo texture and texture tiling effects (500b), and

indirect texture-processing (500c).

Texture unit 500 outputs filtered texture values to the texture environment unit 600 for texture environment processing (600a). Texture environment unit 600 blends polygon and texture color/alpha/depth, and can also perform texture fog processing (600b) to achieve inverse range based fog effects. Texture environment unit 600 can provide multiple stages to perform a variety of other interesting environment-related functions based for example on color/alpha modulation, embossing, detail texturing, texture swapping, clamping, and depth blending.

Pixel engine 700 performs depth (z) compare (700a) and pixel blending (700b). In this example, pixel engine 700 stores data into an embedded (on-chip) frame buffer memory 702. Graphics pipeline 180 may include one or more embedded DRAM memories 702 to store frame buffer and/or texture information locally. Z compares 700a' can also be performed at an earlier stage in the graphics pipeline 180 depending on the rendering mode currently in effect (e.g., z compares can be performed earlier if alpha blending is not required). The pixel engine 700 includes a copy operation 700c that periodically writes on-chip frame buffer 702 to main memory 112 for access by display/video interface unit 164. This copy operation 700c can also be used to copy embedded frame buffer 702 contents to textures in the main memory 112 for dynamic texture synthesis effects. Anti-aliasing and other filtering can be performed during the copy-out operation. The frame buffer output of graphics pipeline 180 (which is ultimately stored in main memory 112) is read each frame by display/video interface unit 164. Display controller/video interface 164 provides digital RGB pixel values for display on display 102.

Example Graphics System Application Interface

As described above, main processor 110 sends graphics commands to graphics and audio processor 114. These graphics commands tell the graphics and audio processor 114 what to do. For example, the graphics commands can tell the graphics and audio processor 114 to draw a particular image onto display device 56. Commands might also tell the graphics and audio processor 114 to produce a particular sound for output by loudspeakers 61. Still other commands might tell the graphics and audio processor 114 to perform so-called "housekeeping" commands and/or to set up a particular state in preparation for a subsequent "action" command.

In the example embodiment, the commands that main processor 110 sends to graphics and audio processor 114 can come from a number of sources. One source of commands is the main processor 110 itself. Under control of program instructions provided, for example, by mass storage access device 106 and/or boot ROM 134, main processor 110 can dynamically create or generate graphics commands under program control to send to graphics and audio processor 114. Main processor 110 can create and send graphics and audio processor 114 any command that the graphics and audio processor understands. Graphics and audio processor 114 will act on the commands and perform the action requested by the command.

Another source of graphics commands for graphics and audio processor 114 is mass storage access device 106. It takes some time for main processor 110 to dynamically create graphics commands. When system 50 is animating a scene in response to real-time inputs from hand controllers 52 or the like, there may be no alternative other than for main processor 110 to dynamically create the graphics commands telling the graphics and audio processor 114 to draw a particular cartoon or other character in a particular position. That way, as the user operates hand controllers 52 of system 50 responds to other input devices, main processor 110 can dynamically adjust or animate the displayed scene in response to those real-time inputs to provide interactive animation. Such fun and exciting interactive animation is generally provided by main processor 110 dynamically creating graphics commands "on the fly."

Sometimes, however, some part of a scene to be displayed is relatively static and does not change in response to real-time inputs. For example, a complicated 3D world background such as a castle, a mountain fortress, a landscape or an undersea world may not change much or at all as animated characters move through the world. In such cases, it is possible to use an offline authoring computer to develop the complex series of graphics commands required to draw the particular scene or portion of the scene and store them in a preconstructed display list. Similarly, sound effects, music and other sounds can be pre-generated off-line by a sound authoring system. The resulting display list(s) and/or audio list(s) can be stored on an optical disk 62 or other mass storage device. When it comes time to draw the scene and/or play the sound, the associated display list(s) and/or audio list(s) can simply be read from the mass storage device 62 and stored into main memory 112. Main processor 110 may then, under program control, tell the graphics and audio processor 114 where to find the preconstructed display list(s) and/or audio list(s), and instruct the graphics and audio processor to execute the lists. In this way, main processor 110 does not have to devote its processing resources to develop complicated display lists and/or audio lists since that task is off-loaded to an off-line authoring system that pre-compiles the lists in preparation for use by the graphics and audio processor 114. Such display lists can be stored by any storage device within system 50 or accessible to it, including but not limited to memory card 144, flash memory 140, boot ROM 134, audio memory 126, etc. The commands could be embedded in hardware such as gate arrays or the like, and communicated to system 50 via any of the external interfaces such as bus 142, bus 132, handheld controller ports, parallel bus 130, infrared, etc.

Still another possibility is for commands intended for processing by the graphics and audio processor 114 to arrive via a data communications connection such as network 138. In one example, graphics commands, audio commands and/or other commands intended to be processed by graphics and audio processor 114 may arrive from a data communications network 138 via modem 136. Such commands could be transmitted, for example, from a remote system 50 of the same configuration as that shown in FIG. 2 in order to provide interactive multi-user remote game play. The commands could originate from any other source including a personal computer, a mini-computer or main frame computer, a data transmitter, or any other data source.

Irrespective of how commands intended for graphics and audio processor 114 arrive and how they are stored before and/or after arrival, the first step in causing such commands to be processed by the graphics and audio processor 114 is to make them available to the graphics and audio processor. In the example embodiment, making the commands available to graphics and audio processor 114 can be accomplished either by having main processor 10 send the commands directly to the graphics and audio processor via a data bus in an immediate mode of command transfer, or by storing the commands in some memory accessible to the graphics and audio processor 114 (e.g., main memory 112, audio memory 126, or any other memory device to which the graphics and audio processor 114 is coupled) and informing the graphics and audio processor where to find the commands and instructing it to begin processing those commands.

Graphics Command Stream

In the example embodiment graphics and audio processor 114 may receive register and other commands from main processor 110 and/or some other source (e.g., main memory 112) in the form of a graphics command stream. Generally, the data that is sent from main processor 110 to the graphics and audio processor 114 can be called the "command stream." The command stream holds drawing commands along with vertices and their attributes and mechanisms for loading registers and changing modes in the graphics pipeline 180. The stream of graphics commands are sent to the graphics and audio processor 114 for processing in a generally sequential manner. Such stream commands can be provided in a so-called "immediate mode" directly from main processor 110 to the graphics and audio processor 114 through a write gatherer arrangement (see FIG. 4) to provide very efficient transfer of graphics and audio commands from the main processor 110 to the graphics and audio processor 114. The graphics command stream can also be provided to graphics and audio processor 114 via main memory 112 or other memory or other data communications capabilities within system 50. The cache/command processor 200 within the graphics and audio processor 114 performs tasks such as, for example, fetching the command stream from main memory 112; fetching vertex attributes (e.g., either from the command stream or from arrays in main memory); converting attribute types to appropriate formats (e.g., floating point); and transferring complete vertices to the remainder of the graphics pipeline 180 for processing.

As shown in FIG. 5, the command stream is fetched from the first-in-first-out buffer 210 (see also above-referenced Provisional Application No. 60/226,912, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,215, filed Nov. 28, 2000 (atty. dkt. no. 723-959), both entitled "Method and Apparatus for Buffering Graphics Data in a Graphics System", and read into a FIFO buffer 216. The command processor 200 strips and decodes the commands to decide the number of data associated with it. The data is then taken from the stream and/or fetched from an array in main memory 112, based on an index value. The vertex attributes are converted to floating point data that can be consumed by the transform engine 300.

The following are example command stream formats in the example embodiment:

    TABLE I
    Opcode               Opcode(7:0)     Next              Followed by
    NOP                  00000000        none              none
    Draw_Quads           10000vat(2:0)   VertexCount(15:0) Vertex attribute
     stream
    Draw_Triangles       10010vat(2:0)   VertexCount(15:0) Vertex attribute
     stream
    Draw_Triangles_strip 10011vat(2:0)   VertexCount(15:0) Vertex attribute
     stream
    Draw_Triangle_fan    10100vat(2:0)   VertexCount(15:0) Vertex attribute
     steam
    Draw_Lines           10101vat(2:0)   VertexCount(15:0) Vertex attribute
     stream
    Draw_Line_strip      10110vat(2:0)   VertexCount(15:0) Vertex attnbute
     stream
    Draw_Points          10111vat 2:0)   VertexCount(15:0) Vertex attribute
     stream
    CP_LoadRegs          00001xxx        Address[7:0]      32 bits data
    (for CP only registers)
    XF_LoadRegs          00010xxx        none              (N + 2) *32 bits
    (This is used for                                      First 32 bit:
    loading all XF                                         15:00 register
     address in XF
    registers, including                                   19:16 number of 32
     bit registers to be
    matrices. It can be                                    loaded (N + 1, 0
     means 1, 0xff means 16)
    used to load matrices                                   31:20 unused
    with immediate data)                                   Next N + 1 32 bits:
                                                           31:00 register data
    XF_IndexLoadRegA     00100xxx        none              32 bits
    (registers are in the                                   11:0 register
     address in XF
    first 4K address space                                   15:12 number of 32
     bit data, (0 means 1,
    of the XF. It can be                                   0xff means 16)
    used to block load                                     31:16 Index to the
     register Array A
    matrix and light
    registers)
    XF_IndexLoadRegB     00101xxx        none              32 bits
    (registers are in the                                   11:0 register
     address in XF
    first 4K address space                                   15:12 number of 32
     bit data, (0 means 1,
    of the XF It can be                                    0xff means 16)
    used to block load                                     31:16 Index to the
     register Array B
    matrix and light
    registers)
    XF_IndexLoadRegC     00110xxx        none              32 bits
    (registers are in the                                   11:0 register
     address in XF
    first 4K address space                                   15:12 number of 32
     bit data. (0 means 1.
    of the XF. It can be                                   0xff means 16)
    used to block load                                     31:16 Index to the
     register Array C
    matrix and light
    registers)
    XF_IndexLoadRegD     00111xxx        none              32 bits
    (registers are in the                                   11:0 register
     address in XF
    first 4K address space                                   15:12 number of 32
     bit data. (0 means 1,
    of the XF It can be                                    0xff means 16)
    used to block load                                     31:16 Index to the
     register Array D
    matrix and light
    registers)
    Call_Object          01000xxx        none              2 .times. 32
                                                           25:5 address (need
     to be 32 byte align)
                                                           25:5 count (32 byte
     count)
    V$_Invalidate        01001xxx        none              none
    SU_ByPassCmd         0110,SUattr(3:0) none              32 bit data
    (This includes all the
    register load below XF
    and all setup unit
    commands, which
    bypass XF)

    TABLE II
    Register name Register address[7:0]        Bit fields
    MatrixIndexA  0011xxxx                     5:0 index for position/normal
     matrix
                                               11:6 index for tex0 matrix
                                               17:12 index for tex1 matrix
                                               23:18 index for tex2 matrix
                                               29:24 index for tex3 matrix
    MatrixIndexB  0100xxxx                     5:0 index for tex4 matrix
                                               11:6 index for tex5 matrix
                                               17:12 index for tex6 matrix
                                               23:18 index for tex7 matrix
    VCD_Lo        0101xxxx                     16:00 VCD 12 to 0
                                               0 PosMatIdx
                                               1 Tex0MatIdx
                                               2 Tex1MatIdx
                                               3 Tex2atIdx
                                               4 Tex3MatIdx
                                               5 Tex4MatIdx
                                               6 Tex5MatIdx
                                               7 Tex6MatIdx
                                               8 Tex7MatIdx
                                               10:9 Position
                                               12:11 Normal
                                               14:13 ColorDiffused
                                               16:15 ColorSpecular
    VCD_ -Hi      0110xxxx                     15:00 VCD 20 to 13
                                               01:00 Tex0Coord
                                               03:02 Tex1Coord
                                               05:04 Tex2Coord
                                               07:06 Tex3Coord
                                               09:08 Tex4Coord
                                               11:10 Tex5Coord
                                               13:12 Tex6Coord
                                               15:14 Tex7Coord
    VAT_group0    0111x,vat[2:0]               32 bits
                                               08:00 Position parameters
                                               12:09 Normal parameters
                                               16:13 ColorDiffused parameters
                                               20:17 ColorSpecular parameters
                                               29:21 Tex0Coord parameters
                                               30:30 ByteDequant
                                               31:31 NormalIndex3
    VAT_group 1   1000x,vat[2:0]               32 bits
                                               08:00 Tex1Coord parameters
                                               17:09 Tex2Coord parameters
                                               26:18 Tex3Coord parameters
                                               30:27 Tex4Coord parameters
     sub-field[3:0]
                                               31 unused
    VAT_group2    1001x.vat[2.0]               32 bits
                                               04:00 Tex4Coord parameters
     sub-field[8:4]
                                               13.05 Tex5Coord parameters
                                               22:14 Tex6Coord parameters
                                               31:23 Tex7Coord parameters
    ArrayBase     1010.array[3:0]              32 bit data
                  array[3:0]:                  25:00 Base(25:)
                  0000 = attribute9 base register 31:26 unused
                  0001 = attribute10 base register
                  0010 = attribute11 base register
                  0011 = attribute12 base register
                  0100 = attribute13 base register
                  0101 = attribute14 base register
                  0110 = attribute15 base register
                  0111 = attribute16 base register
                  1000 = attribute17 base register
                  1001 = attribute18 base register
                  1010 = attribute19 base register
                  1011 = attribute20 base register
                  1100 = IndexRegA base register
                  1101 = IndexRegB base register
                  1110 = IndexRegC base register
                  1111 = IndexRegD base register
    ArrayStride   1011,array[3:0]              32 bit data
                  array[3:0]                   07:00 Stride(7:0)
                  0000 = attribute9 stride register 31:08 unused
                  0001 = attribute10 stride register
                  0010 = attribute11 stride register
                  0011 = attribute12 stride register
                  0100 = attribute13 stride register
                  0101 = attribute14 stride register
                  0110 = attribute15 stride register
                  0111 = attribute16 stride register
                  1000 = attribute17 stride register
                  1001 = attribute18 stride register
                  1010 = attribute19 stride register
                  1011 = atrribute20 stride register
                  1100 = IndexRegA stride register
                  1101 = IndexRegB stride register
                  1110 = IndexRegC stride register
                  1111 = IndexRegD stride register

    TABLE III
    Location in stream
    (in words)         Data                 Description
    0 to 2             X, Y, Z in 32b SPFP  Geometry information
                                            in single precision
                                            floating point format
    3 to 5             Nx, Ny, Nz in 32b SPFP Normal vector
    6                  RGBA in 32b integer  Color0 per vertex
                       (8b/comp)            (RGBA)
    7                  RGBA in 32b integer  Color1 per vertex
                       (8b/comp)            (RGBA)
    8 to 10            Tx, Ty, Tz in 32b SPFP Binormal vector T
    11 to 13           Bx, By, Bz in 32b SPFP Binormal vector B
    14 to 15           S0, T0 in 32b SPFP   Texture 0 data
    16 to 29           Sn. Tn in 32b SPFP   Texture 1 to n data

                             TABLE IV
                   VERTEX ATTRIBUTE TABLE (VAT)
    Attribute Attribute
     number   name        bits  Encoding
        0     PosMatIdx   0     Position/normal matrix index.
                                Always direct if present
                                0: not present 1: present
                                NOTE: position and normal matrices
                                are stored in 2 separate RAMs in
                                the Xform unit, but there is a one
                                to one correspondence between
                                normal and position index. If index
                                "A" is used for the position,
                                then index "A" needs to be
                                used for the normal as well
        1     Tex0MatIdx  1     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        2     Tex1MatIdx  2     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        3     Tex2MatIdx  3     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        4     Tex3MatIdx  4     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        5     Tex4MatIdx  5     TextCoord0 matrix index,
                                always direct if present
                                0: not resent 1: resent
        6     Tex5MatIdx  6     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        7     Tex6MatIdx  7     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        8     Tex7MatIdx  8     TextCoord0 matrix index, always
                                direct if present
                                0: not present 1: present
        9     Position    10:9  00: reserved 10: 8 bit index
                                01: direct 11: 16 bit index
       10     Normal      12:11 00: not present 10: 8 bit index
                                01: direct 11:16 bit index
       11     Color0      14:13 00: not present 10: 8 bit index
                                01: direct 11:16 bit index
       12     Color1      16:15 00: not present 10:8 bit index
                                01: direct 11:16 bit index
       13     Tex0Coord   18:17 00: not present
                                01: direct
                                10: 8 bit index
                                11: 16 bit index
       14     Tex1Coord   20:19 00: not present
                                01: direct
                                10: 8 bit index
                                11: 16 bit index
       15     Tex2Coord   22:21 00: not present
                                01: direct
                                10: 8 bit index
                                11: 16 bit index
       16     Tex3Coord   24:23 00: not present
                                01: direct
                                10: 8 bit index
                                11: 16 bit index
       17     Tex4Coord   26:25 00: not present
                                01: direct
                                10: 8 bit index
                                11: 16 bit index
       18     Tex5Coord   28:27 Same as above
       19     Tex6Coord   30 29 00: not present
       20     Tex7Coord   32 31 01:direct
                                10: 8 bit index
                                11: 16 bit index

    TABLE V
    Bit   Attribute Attribute     CompCount     CompSize               Shift
     amount
    field number    name          sub-field(0)  sub-field(3:1)
     sub-field(8:4)
    8:0    9        Position      0: two (x, y) 0: ubyte 1: byte 2: ushort
     Location of decimal point
                                  1: three      3: short 4: float 5-7  from
     LSB. This shift applies
                                  (x, y, z)     reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    12:9  10        Normal        0: three      0: reserved 1: byte    NA
     (Byte: 6, Short: 14)
                                  normals       2: reserved
                                  1: nine       3: short 4: float 5-7
                                  normals       reserved
    16:13 11        Color0        0: three      0: 16 bit 565 (three comp) NA
                                  (r, g, b)     1: 24 bit 888 (three comp)
                                                2: 32 bit 888x (three
                                                comp)
                                  1: four       3: 16 bit 4444 (four comp)
                                  (r, g, b, a)  4: 24 bit 6666 (four comp)
                                                5: 32 bit 8888 (four comp)
    20:17 12        Color1        0: three      0: 16 bit 565 (three comp) NA
                                  (r, g, b)     1: 24 bit 888 (three comp)
                                                2: 32 bit 888x (three comp)
                                                3: 16 bit 4444 (four comp)
                                  1: four       4: 24 bit 6666 (four comp)
                                  (r, g, b, a)  5: 32 bit 8888 (four comp)
    29:21 13        Tex0Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1:byte 3: short 5-7    from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    38:30 14        Tex1Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    47:39 15        Tex2Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from LSB
     This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    56:48 16        Tex3Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from LSB
     This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below)
    65:57 17        Tex4Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    74.66 18        Tex5Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    83.75 19        Tex6Coord     0. one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    92:84 20        Tex7Coord     0: one (s)    0: ubyte 2: ushort 4: float
     Location of decimal point
                                  1: two (s, t) 1: byte 3: short 5-7   from
     LSB. This shift applies
                                                reserved               to all
     u/short components and
                                                                       to
     u/byte components where
     ByteDequant is asserted
                                                                       (Below).
    93:93 FLAG      ByteDequant   (Rev B Only)  0: Shift does not apply to
     Shift applies for u/byte
                                                u/byte
     components of position and
                                                1: Shift does apply to texture
     attributes.
                                                u/byte
    94:94 FLAG      NormalIndex3  (Rev B Only)  0: Single index per Normal When
     nine normals selected
                                                1: Triple index per nine- in
     indirect mode, input will
                                                Normal                 be
     treated as three staggered
                                                                       indices
     (one per triple biased
                                                                       by
     component size), into
                                                                       normal
     table.
                                                                       NOTE!!
                                                                       First
     index internally biased
                                                                       by 0.
                                                                       Second
     index internally
                                                                       biased
     by 1.
                                                                       Third
     index internally
                                                                       biassed
     by 2.

        Register Address  Definition             Configuration
        0x0000            Matrix Ram word 0      32b matrix data
        0x0001-0x00ff     Matrix Ram word (n)    32b matrix data
        0x0100-0x03ff     Not used

        Register Address Definition           Configuration
        0x0400-0x402    Normal Ram words 0,1,2 20b data
        0x0403-0x045f   Normal Ram word (n)  20b data
        0x0460-0x05ff   Not used

        Register Address  Definition             Configuration
        0x0500            Matrix Ram word 0      32b matrix data
        0x0501-0x05ff     Matrix Ram word (n)    32b matrix data

    GXColor   ClearColor; //Color value to clear the framebuffer to
                          during copy.
    u32       ClearZ;     //24 bit Z value to clear the framebuffer
                          to during copy.

    GXAttr        Attr; //Which attribute (Position, Normal, Color, etc.)
    GXAttrType    Type; //Attribute Type (None, Direct, Indexed, etc.)

    GXVtxFmt      vtxfmt;     //Index into the Vertex Attribute
                              Table (0-7).
    GXAttr        Attr:       //Attribute Type.
    GXCompCnt     CompCnt;    //Number of components for the attribute.
    GXCompType    CompType    //Type of each Component.
    u8            Shift:      //Locatin of decimal point for fixed point
                              format types.

    GXAttr  Attr;   //Attribute type.
    u32     Base;   //Address (25:0) of the attribute data array
                    in main memory.
    u8      Stride; //Number of bytes between successive elements in
                    the attribute array.

    f32             Matrix[4][4] //Projection matrix.
    GXProjMtxType   type;       //Indicates if the projection is
                                orthographic.

                    TABLE VI
                     Hex                 Binary
                      0                   0000
                      1                   0001
                      2                   0010
                      3                   0011
                      4                   0100
                      5                   0101
                      6                   0110
                      7                   0111
                      8                   1000
                      9                   1001
                      A                   1010
                      B                   1011
                      C                   1100
                      D                   1101
                      E                   1110
                      F                   1111

• Inventors
  Parikh, Vimal; Moore, Robert; Cheng, Howard;
• Assignee
  Nintendo Co., Ltd. (Kyoto, JP)
• Published
  Feb-24-2004
• Current US Classes:
  345/503
  345/520
  345/522
  345/545
  712/208
  719/328
• Application #
  207120
• International Classes
  G06T 015/00
• Field of Search
  345/522 345/581 345/503 345/545 345/419 345/427 345/520 345/553 345/559 709/328 712/208 712/210
• Examiner
  Chauhan; Ulka J.
• Agent
  Nixon & Vanderhye P.C.
• US Patent References:
  4388620
  4425559
  4570233
  4658247
  4725831
  4736330
  4829295
  4862392
  4866637
  4901064
  4914729
  4945500
  5136664
  5170468
  5392385
  5392393
  5404445
  5421028
  5432900
  5438663
  5457775
  5504917
  5594854
  5608424
  5657479
  5687357
  5701444
  5721947
  5727192
  5751295
  5758182
  5764243
  5768626
  5768629
  5774133
  5777629
  5798770
  5801706
  5801716
  5805868
  5812147
  5815166
  5821949
  5870587
  5874969
  5884314
  5913054
  5917496
  5920326
  5920876
  5936641
  5940086
  5949424
  5949440
  5969726
  5995121
  5999196
  6002409
  6023738
  6025853
  6028611
  6037949
  6052133
  6057852
  6057863
  6092124
  6151602
  6173367
  6177944
  6181352
  6198488
  6226012
  6342892
  6401182
  6434625
  6466218
  6525737