Source: http://www.docstoc.com/docs/57564496/Graphics-System-With-Embedded-Frame-Butter-Having-Reconfigurable-Pixel-Formats---Patent-7576748
Timestamp: 2014-08-27 23:39:44
Document Index: 16168365

Matched Legal Cases: ['Application No.\n60', 'Application No. 60', 'Application No.\n60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No.\n60', 'Application No. 60', 'Application No.\n60', 'Application No.\n60', 'Application No. 60', 'Application No.\n60', 'Application No. 60', 'Application No.\n60', 'Application No. 60', 'Application No.\n60', 'Application No.\n60', 'Application No. 60', 'Application No. 60']

Graphics System With Embedded Frame Butter Having Reconfigurable Pixel Formats - Patent 7576748
United States Patent: 7576748
7,576,748
Graphics system with embedded frame butter having reconfigurable pixel
audio digital signal processor. The graphics system has a graphics
processor includes an embedded frame buffer for storing frame data prior
to sending the frame data to an external location, such as main memory.
The embedded frame buffer is selectively configurable to store the
following pixel formats: point sampled RGB color and depth, super-sampled
RGB color and depth, and YUV (luma/chroma). Graphics commands are
provided which enable the programmer to configure the embedded frame
buffer for any of the pixel formats on a frame-by-frame basis.
Van Hook; Timothy J. (Atherton, CA), Fouladi; Farhad (Los Altos Hills, CA)
11/398,531
11082854Mar., 20057075545
09722380Nov., 20006937245
345/546  ; 345/545; 345/547; 345/604; 345/605
G09G 5/36&amp;nbsp(20060101); G09G 5/02&amp;nbsp(20060101); G09G 5/397&amp;nbsp(20060101)
345/545-547,542,422,600,603-605,611,613
Alcokm et al.
Harumatsu et al.
0 778 536
0 802 519
GDC 2000: Advanced OpenGL Game Development, &quot;A Practical and Robust Bump-mapping Technique for Today&#39;GPUs,&quot; by Mark Kilgard, Jul. 5, 2000,
White paper, Kilgard, Mark J., &quot;Improving Shadows and Reflections via the Stencil Buffer&quot;(Nov. 3, 1999). cited by other
Feth, Bill, &quot;Non-Photorealistic Rendering,&quot; wif3 @ cornell.edu, CS490--Bruce Land, 5 pages (Spring 1998). cited by other
Press Releases, &quot;ATI&#39;s RADEON family of products delivers the most comprehensive support for the advance graphics features of DirectX 8.0,&quot; Canada, from ATI.com web site, 2 pages (Nov. 8, 2000). cited by other
Hart, Evan et al., &quot;Vertex Shadign with Direct3D and OpenGL,&quot; Game Developers Conference 2001, from ATI.com web site (2001). cited by other
11/082,854, filed Mar. 18, 2005 now U.S. Pat. No. 7,075,545, is a
continuation of U.S. application Ser. No. 09/722,380, filed Nov. 28, 2000
now U.S. Pat. No. 6,937,245, which was filed in accordance with 35 U.S.C.
.sctn.119(e)(1) and claims the benefit of the provisional application
Ser. No. 60/226,910 filed on Aug. 23, 2000, entitled &quot;Graphics System
With Embedded Frame Buffer Having Reconfigurable Pixel Formats.&quot;
This application is related to the following co-pending applications
described herein. Each of the following applications are hereby
incorporated herein by reference.   provisional Application No.
60/161,915, filed Oct. 28, 1999 and its corresponding utility application
Ser. No. 09/465,754, filed Dec. 17, 1999, both entitled &quot;Vertex Cache For
3D Computer Graphics&quot;, provisional Application No. 60/226,912, filed Aug.
23, 2000 and its corresponding utility application Ser. No. 09/726,215,
filed Nov. 28, 2000, both entitled &quot;Method and Apparatus for Buffering
Graphics Data in a Graphics System&quot;, provisional Application No.
60/226,889, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/722,419, filed Nov. 28, 2000, both entitled &quot;Graphics
Pipeline Token Synchronization&quot;, provisional Application No. 60/226,891,
filed Aug. 23, 2000 and its corresponding utility application Ser. No.
09/722,382, filed Nov. 28, 2000, both entitled &quot;Method And Apparatus For
Direct and Indirect Texture Processing In A Graphics System&quot;, provisional
Application No. 60/226,888, filed Aug. 23, 2000 and its corresponding
utility application Ser. No. 09/722,367, filed Nov. 28, 2000, both
entitled &quot;Recirculating Shade Tree Blender For A Graphics System&quot;,
provisional Application No. 60/226,892, filed Aug. 23, 2000 and its
corresponding utility application Ser. No. 09/726,218, filed Nov. 28,
2000, both entitled &quot;Method And Apparatus For Efficient Generation Of
Texture Coordinate Displacements For Implementing Emboss-Style Bump
Mapping In A Graphics Rendering System&quot;, provisional Application No.
60/226,893, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/722,381 filed Nov. 28, 2000, both entitled &quot;Method And
Apparatus For Environment-Mapped Bump-Mapping In A Graphics System&quot;,
2000, both entitled &quot;Achromatic Lighting in a Graphics System and
Method&quot;, provisional Application No. 60/226,900, filed Aug. 23, 2000 and
its corresponding utility application Ser. No. 09/726,226, filed Nov. 28,
System&quot;, utility application Ser. No. 09/585,329, filed Jun. 2, 2000,
entitled &quot;Variable Bit Field Color Encoding&quot;, provisional Application No.
60/226,890, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/726,227, filed Nov. 28, 2000, both entitled &quot;Method And
Apparatus For Dynamically Reconfiguring The Order Of Hidden Surface
Processing Based On Rendering Mode&quot;, provisional Application No.
60/226,915, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/726,212 filed Nov. 28, 2000, both entitled &quot;Method And
Apparatus For Providing Non-Photorealistic Cartoon Outlining Within A
Graphics System&quot;, provisional Application No. 60/227,032, filed Aug. 23,
2000 and its corresponding utility application Ser. No. 09/726,225, filed
Nov. 28, 2000, both entitled &quot;Method And Apparatus For Providing Improved
Fog Effects In A Graphics System&quot;, provisional Application No.
60/226,885, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/722,664, filed Nov. 28, 2000, both entitled &quot;Controller
Interface For A Graphics System&quot;, provisional Application No. 60/227,033,
09/726,221, filed Nov. 28, 2000, both entitled &quot;Method And Apparatus For
Texture Tiling In A Graphics System&quot;, provisional Application No.
60/226,899, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/722,667, filed Nov. 28, 2000, both entitled &quot;Method And
Apparatus For Pre-Caching Data In Audio Memory&quot;, provisional Application
No. 60/226,913, filed Aug. 23, 2000 and its corresponding utility
application Ser. No. 09/722,378, filed Nov. 28, 2000, both entitled
&quot;Z-Texturing&quot;, provisional Application No. 60/227,031, filed Aug. 23,
2000 entitled &quot;Application Program Interface for a Graphics System&quot;
2000, both entitled &quot;Graphics System With Copy Out Conversions Between
Embedded Frame Buffer And Main Memory&quot;, provisional Application No.
60/226,886, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/722,665, filed Nov. 28, 2000, both entitled &quot;Method and
Apparatus for Accessing Shared Resources&quot;, provisional Application No.
60/226,894, filed Aug. 23, 2000 and its corresponding utility application
Ser. No. 09/726,220, filed Nov. 28, 2000, both entitled &quot;Graphics
Processing System With Enhanced Memory Controller&quot;, provisional
Application No. 60/226,914, filed Aug. 23, 2000 and its corresponding
utility application Ser. No. 09/722,390, filed Nov. 28, 2000, both
entitled &quot;Low Cost Graphics System With Stitching Hardware Support For
Skeletal Animation&quot;, and provisional Application No. 60/227,006, filed
Aug. 23, 2000 and its corresponding utility application Ser. No.
09/722,421, filed Nov. 28, 2000, both entitled &quot;Shadow Mapping In A Low
1.  A graphics processor, including: image processing circuitry;  and an embedded frame buffer;  wherein the embedded frame buffer is selectively configurable to receive data in any of
the following formats: point sampled color and depth;  super-sampled color and depth;  and YUV, wherein the point sampled format is a 48-bit format and the super-sampled format is a 96-bit format.
2.  The graphics processor of claim 1, wherein the 48-bit format includes 24 color bits and 24 depth bits.
3.  The graphics processor of claim 2, wherein the embedded frame buffer is further configurable such that the 24 color bits selectively include either 8 bits for red, 8 bits for blue and 8 bits for green (RGB8) or 6 bits for red, 6 bits for
green, 6 bits for blue and 6 bits for alpha (RGBA6).
4.  The graphics processor of claim 2, wherein the 96-bit format includes color and depth data for three super-sample locations for a pixel.
5.  The graphics processor of claim 4, wherein the super-sample color data is 16 bits and the super-sample depth data is 16 bits.
6.  The graphics processor of claim 5, wherein the 16 bit super-sample color data includes 5 bits for red, 6 bits for green and 5 bits for blue (R5G6B5).
7.  The graphics processor of claim 1, wherein the YUV format is a YUV 4:2:0 format.
8.  The graphics processor of claim 1, wherein the embedded frame buffer is a dynamic random access memory (DRAM).
9.  A graphics system, comprising a graphics chip having graphics processing circuitry and an embedded frame buffer for storing frame data prior to sending the frame data to an external location, wherein the embedded frame buffer is selectively
configurable between the following pixel formats: RGB8 and 24 bit Z;  RGBA6 and 24 bit Z;  Three R5G6B5 color and 16 bit Z super-samples;  and YUV4:2:0.
10.  The graphics system of claim 9, wherein in the YUV 4:2:0 configuration, a color buffer of the embedded frame buffer is partitioned to store 720.times.576 Y, 360.times.288 U and 360.times.288 V image planes for a YUV 4:2:0 frame.
11.  The graphics system of claim 9, further including an interface to the graphics system that enables a programmer to selectively configure the embedded frame buffer.
12.  The graphics system of claim 11, wherein the interface enables the embedded frame buffer to be reconfigured on a frame-by-frame basis.
13.  In a graphics chip having pixel processing circuitry and an embedded frame buffer for storing pixel data prior to transferring the pixel data to an external destination, an improvement comprising: a reconfigurable embedded frame buffer
which can be selectively configured to store any of the following pixel formats: 48 bit point sampled color and Z;  96 bit super-sampled color and Z;  and YUV.
14.  The graphics chip of claim 13, wherein the embedded frame buffer is further selectively configurable to store the following 48 bit formats: RGB8 and 24 bit Z;  and RGBA6 and 24 bit Z.
15.  The graphics chip of claim 13, wherein the YUV format is a YUV 4:2:0 format.
16.  A method of using an embedded frame buffer in a graphics system, including the steps of: providing an embedded frame buffer that is selectively configurable to store image data in either RGB color format or YUV color format;  providing an
interface to the graphics system which controls the configuration of the embedded frame buffer;  and enabling the RGB color format to be configured as either a 48-bit point sampled color and Z format or a 96-bit super-sampled color and Z format.
17.  The method of claim 16, further including enabling the 48-bit format to selectively include an RGB8 and 24 bit Z format or an RGBA6 and 24 bit Z format.
18.  The method of claim 16, further including defining the YUV format as a YUV 4:2:0 format.  Description
The present invention relates to computer graphics, and more particularly to interactive graphics systems such as home video game platforms.  Still more particularly this invention relates to a graphics system having a reconfigurable embedded
frame buffer which advantageously enables the selection of particular pixel formats on a frame-by-frame basis for data stored therein.
A problem graphics system designers confronted in the past was to provide a powerful yet inexpensive system which enables various data formats to be stored and processed thereby in a efficient and advantageous manner.  Graphics chips used in
graphics systems have included a local or on-chip memory for storing data as it is rendered by the graphics pipeline.  When data is generated by the graphics chip it is transferred from the local memory to an external memory, where it can be used by, for
example, a video interface unit to display the data on a display device.  This external memory is typically part of the main memory of the graphics system and is referred to as the external frame buffer (XFB).  The processing path of the data between the
local memory and the external frame buffer may be referred to as the copy pipeline.
The local memory and the external frame buffer can have a variety of data formats for achieving various functionality in the graphics system.  One problem that graphics system designers have faced in the past is to determine what format(s) of
data to support in the local memory and the external frame buffer to enable advantageous and efficient use thereof by applications running on the system.  Various solutions to this problem were offered.  For example, graphics systems have used a variety
of data formats in an attempt to improve or maximize the overall operation of the system.  While some work has been done in the past in connection with such memories and data formats, further improvements are desirable.  Specifically, further
improvements are desired for high performance, low cost graphics systems, such as home video game systems.
The present invention addresses this problem by providing techniques and arrangements for use in connection with an embedded frame buffers in graphics systems.  The invention provides a combination of pixel formats for an embedded frame buffer
that is particularly advantageous when used in systems designed for playing interactive 3D video games.  The invention enables the embedded frame buffer to be reconfigured to and efficiently used in a variety of modes, including an anti-aliasing mode, a
deflicker mode and a YUV (i.e. luma/chroma) mode, thereby increasing the flexibility of the system to support a variety of applications.  The desired pixel format for each mode can be selected using, for example, a command to the graphics hardware on
which the embedded frame buffer is provided.
In accordance with the invention, the copy pipeline is advantageously used to further process the data from the embedded frame buffer prior to storing the data in the external frame buffer.  For example, the copy pipeline can be used to convert
the data between a variety of useful formats to, for example, reduce the amount of memory needed to store the data, and/or provide the data in desired format for use in further processing by the graphics system.  The copy pipeline can also be used to
further process the frame data in a manner that improves the display quality and/or modifies the display characteristics.
In accordance with one aspect provided by the invention, the graphics processor includes pixel processing circuitry for producing pixel data, and an embedded frame buffer which receives pixel data, wherein the embedded frame buffer is selectively
configurable to store the received pixel data in any of the following formats: RGB color and depth (Z); super-sampled RGB color and depth (Z); and YUV (luma/chroma).
In accordance with a preferred embodiment of the invention, the RGB color and depth is a 48-bit format which includes 24 color bits and 24 depth (Z) bits.  The embedded frame buffer is further configurable such that the 24 color bits selectively
include either 8 bits for red, 8 bits for blue and 8 bits for green (RGB8) or 6 bits for red, 6 bits for green, 6 bits for blue and 6 bits for alpha (RGBA6).  Preferably, super-sampled RGB color and depth is a 96-bit format which includes 16 bit color
and 16 bit depth data for three super-sample locations for each pixel.  The 16 bit super-sample color data preferably includes 5 bits for red, 6 bits for green and 5 bits for blue (R5G6B5).  The YUV format is preferably a YUV 4:2:0 format.  The embedded
frame buffer (EFB) may be a dynamic random access memory (DRAM).  In one embodiment of the invention the EFB is a IT SRAM, such as provided by Moses, which is a DRAM that acts as an SRAM.
In accordance with another aspect of the invention, a method of using an embedded frame buffer in a graphics system is provided.  The method includes providing an embedded frame buffer that is selectively configurable to store point sampled pixel
data including color and Z, super-sampled pixel data including color and Z, and YUV format data, and providing an interface, such one or more API commands, to the graphics system which enables the particular configuration of the embedded frame buffer to
be established by a programmer on a frame-by-frame basis.
testing 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
As generally shown in FIG. 4, the embedded frame buffer 702 receives data from the graphics pipeline 180.  The graphics pipeline renders primitives in RGB(A) format.  Thus, as will be explained in more detail below, the embedded frame buffer 702
can be configured to store pixel data in various RGB(A) formats.  As can be seen in FIG. 4, the processor interface 150 can be used, not only to supply data to the graphics pipeline 180, but also to enable the main processor (CPU) 110 to load data
directly into the embedded frame buffer.  This direct loading of the embedded frame buffer by the CPU enables pixel formats other than RGB-type formats to be sent to the embedded frame buffer, thereby increasing the flexibility of the system to support a
variety of applications.  Specifically, the processor interface 150 enables the main processor 110 to load pixel data in YUV format (i.e. luma/chroma format) into the embedded frame buffer from, for example, an optical disk or other storage media.  Once
YUV format data is in the embedded frame buffer, it can be copied out to main memory in various texture formats, using the copy pipeline, for use as a texture by the texture environment unit (TEV) during a later rendering process.  Thus, in accordance
with the instant invention, the embedded frame buffer is reconfigurable between various RGB(A) formats and a YUV format.  Each of these formats will be described in detail below.
In this example, the embedded frame buffer (EFB) has a memory capacity of approximately 2 MB.  The maximum pixel width and height of the frame buffer is determined by the size of each pixel.  In accordance with the invention, and as shown in FIG.
6, there are two different RGB pixel sizes that can be used for data in the embedded frame buffer 702.  These sizes are: 48-bit color and Z; and 96-bit super-sampled color and Z 48-Bit Pixel Size Configuration
The 48-bit format for the embedded frame buffer (EFB) is preferably intended for non-anti-aliasing, and has the following features: 24-bit color (either 8/8/8 with no alpha, or 6/6/6/6 with 6 bits of alpha) 24-bit Z.
In this non-anti-aliasing mode, the 48-bit format can, in this example, support a maximum resolution of 640.times.528.  Thus, the width must be between 0-640 and the EFB stride is fixed at 640 pixels.  This non-antaliasing mode is based on a
single point sample within each pixel.  As indicated above, the point sample of each pixel is given a 24-bit color value and a 24-bit Z value.  The color value may have 8 bits each for red, green and blue values when no alpha is used, or it may have 6
bits each for red, green, blue and alpha.
The 96-bit super-sampling pixel format is preferably used for anti-aliasing and has the following features: 3 samples of 16-bit color (5 bits of Red, 6 bits of Green, 5 bits of Blue, no alpha) 3 samples of 16-bit Z (depth).
This 96-bit format can support a maximum resolution of 640.times.264.  The width is preferably between 0-640 and the stride is fixed at 640.
In this example, the 96-bit format is used for anti-aliasing.  However, this format may be used to achieve functionality other than anti-aliasing where three supersamples per pixel are desired.  In other words, the 96-bit format provides the
ability to store three samples (super-samples) for each pixel, as opposed to the single point sample per pixel as used in the 48-bit configuration.
As can be seen from the above, there are inherent tradeoffs between the 48-bit and 96-bit pixel formats.  While the 96-bit anti-aliasing format enables an increase visual quality on the polygon edges and intersections, it does cost performance
and Z quality.  The 96 bit super-sampling EFB format requires twice as much memory as 48-bit point sampled pixels.  This mode also reduces Z buffering precision to 16 bits rather than 24 bits in other formats.  In this example, anti-aliasing also reduces
peak fill rate from 800 Mpixels/s to 400 Mpixels/s. However, if more than one stage is employed in the texture environment unit (TEV), this reduction is hidden, in that, in this example, using two TEV stages also reduces the fill rate to 400 Mpixels/s.
In one embodiment, the rendering rate with anti-aliasing activated drops down to two pixels/clock due to the embedded frame buffer 702 bandwidth limitations.  However, if two or more textures are turned on, the rate at which pixel quads are sent
to the pixel engine 700 drops down to less than or equal to one pixel quad every two clocks in this particular embodiment.  In this case, turning on anti-aliasing will not impact fill rate.  Thus, if a particular scene is geometry-limited, then
anti-aliasing will not adversely impact rendering performance.  On the other hand, if a particular scene is fill-limited, rendering performance may be substantially adversely impacted by activating anti-aliasing as opposed to using the point sampled
mode.  The same application can activate and deactivate anti-aliasing for different scenes and different images depending on whether the scenes or images are geometry-limited or fill-limited--or depending upon the image quality required in a particular
scene or image.  The ability to dynamically change the pixel format in the frame buffer to, for example, activate and deactivate anti-aliasing, on a frame-by-frame basis provides great flexibility in allowing an application programmer to make tradeoffs
between image quality and speed performance.
The particular and preferred anti-aliasing methods and arrangements for use in connection with the instant invention are disclosed in commonly owned and co-pending application Ser.  No. 09/726,226, filed Nov.  28, 2000 and entitled &quot;Method and
Apparatus For Anti-Aliasing In A Graphics System&quot;, which is incorporated by reference herein in its entirety.  A brief explanation of this anti-aliasing is provided below, in order to give a more complete understanding of the 96-bit pixel format for the
embedded frame buffer.
In accordance with the anti-aliasing embodiment, anti-aliasing is performed in two main phases.  In the first phase, data is loaded into the embedded frame buffer using three supersamples per pixel and the 96-bit pixel EFB format.  In the second
phase the data is read (or copied out) from the embedded frame buffer and further processed by the copy pipeline.  The 96-bit format is particularly advantageous for achieving the first phase of anti-aliasing, however, it can be used for any other
suitable purpose as well.
In this example anti-aliasing use of the 96-bit format, the first anti-aliasing phase occurs when the rasterizer is performing edge rasterization into the embedded frame buffer (EFB) 702.  Preferably, this rasterizer is an edge and z rasterizer
which generates x, y, z and coverage mask values for programmable super-sample locations within every visible pixel quad contained by the current triangle or other primitive being rendered.  The pixel quads have three programmable subpixel locations
within each pixel.  The pixel quad includes 4 pixels in a 2.times.2 configuration.  Within each pixel in the quad, three super-sample locations are programmably selected and specified.  Preferably, the programmer can set the subsample locations by
writing global registers.  Since the location of each of the super-samples in each pixel is programmable in the example embodiment, the particular sampling locations for each quad can be changed as desired for the particular application.  On the other
hand, in alternative embodiments, a particularly optimal multisample location values could be fixed (e.g., set in hardware) so the application programmer does not need to worry about it.  Thus, while the locations are programmable in the example
embodiment, a hardwired optional pattern could be used in lieu of programmability.  Whatever pattern is selected, it can be repeated across a certain number of neighboring pixels in a frame.
Once all of the primitives have been rendered for a frame, the embedded frame buffer will contain super-sampled pixel information for an entire frame.  Due to the fact that three supersamples are provided for each pixel, and each sample includes
16 bit color values and a 16 bit z value, each pixel is represented by 96-bits in the embedded frame buffer.  The embedded frame buffer is then ready for use by the copy pipeline, wherein the second phase of anti-aliasing can be performed.  This second
phase will be described in more detail below in connection with the copy pipeline.  Further details regarding anti-aliasing are provided in the co-pending applications identified above.
FIG. 7 shows a further configuration for the embedded frame buffer 702 which is designed to store pixel data in YUV (luma/chroma) format which, for example, enables motion compensation under the MPEG standards (e.g. MPEG2) to be supported by the
system.  In this YUV configuration, the color buffer is preferably partitioned to store Y (720.times.576), U (360.times.288) and V (360.times.288) image planes for a YUV 4:2:0 frame.  The partitioning of the color buffer preferably allocates as follows:
1024.times.640 8 bit Y image; 528.times.320 8 bit U image; and 528.times.320 8 bit V image.
The preferred location of the images are shown in FIG. 7.  The YUV data is preferably loaded into the embedded frame buffer by the main processor from an externally supplied medium, such as an optical disk or the like, or from any other suitable
source other than the graphics pipe.  It is noted that the graphics pipeline can render single component Y or U or V images, but it cannot draw 3 component YUV pixels.  As will be explained in detail below, the YUV data in the embedded frame buffer can
be further processed by the copy pipeline to either display the data or to convert the data to texture data for subsequent use by the graphics pipeline.
As explained above, the embedded frame buffer 702 can be selectively configured to support two RGB(A) pixel formats (48-bit and 96-bit) and a YUV format.  The desired pixel format can preferably be set on a frame-by-frame basis using the API.  An
example API function for this purpose is as follows:
TABLE-US-00001 GXPixelFormats Format //Sets pixel format for frame buffer GXZCmprFormats ZCmpr //Sets compression format for 16 bit z GXBool Ztop //Z compare before texture
This function sets the format of the embedded frame buffer.  The function is called before any drawing operations are performed.  The pixel format cannot be changed in the middle of a frame in the example embodiment.  The 16 bit Z values (in
multisample or anti-aliasing mode) can be uncompressed or compressed.  The compressed values give a better precision and range.  The Ztop flag can be used to perform depth comparisons before texture mapping (Z-before-texture).  This can improves the
texture bandwidth because less texels need to be fetched and filtered.
An exemplary interface between the pixel engine 700 and the embedded frame buffer 702 is shown in FIG. 8.  Preferably, as shown in FIG. 8, there are 4 copies of the embedded frame buffer (702a, 702b, 702c and 702d)--2 for color and 2 for Z. In
this example, a read or write access to the embedded frame buffer from the pixel engine transfers 96 bits of data or 4 quads of color and Z. There are 4 address/control and read buses to the core of each of the buffers.  The Z channels A and B preferably
share a write port 703a, and the color channels A and B preferably share a separate write port 703b.  The embedded frame buffer preferably has enough bandwidth to blend 4 pixels per clock for peak fillrate of 800M pixels per second.  The maximum size of
the embedded frame buffer is 640 .times.528.times.24b color and 24b Z. The embedded frame buffer is single-buffered and expected to transfer a finished image to the external frame buffer for display.  Double buffered display is achieved in this manner.
The address/control, read and write buses shown in FIG. 8 are defined in the following table:
TABLE-US-00002 Name: Description: za_addr (16:0) Z channel A quad address.  There are 3 subfields: 3:0 column(3:0) valid range is 0 to 9 10:4 row(7:0) valid range 0 to 127 16:11 bank(5:0) valid range is 0 to 32 za_reb Z change A read enable
(active low).  za_web Z channel A write enable (active low).  za_din(95:0) Z channel A quad read bus.  4 .times.  24 bit Z for a quad.  (23:0) Z for the upper left pixel in the quad (47:24) Z for the upper right pixel in the quad (63:48) Z for the lower
left pixel in the quad (95:64) Z for the lower right pixel in the quad zdout (95:0) Z channels A and B quad Z write bus.  4 .times.  24 bit Z for the quad Refer to za_din for pixel locations on the bus zb_addr (16:0) Z channel B quad address (refer to
za_addr for bit-fields) zb_reb Z channel B read enable (active low) zb_web Z channel B write enable (active low) zb_din (95:0) Z channel B quad read bus (refer to za_din for pixel locations) ca_addr (16:0) C channel A quad address.  There are 3
subfields: 3:0 column(3:0) valid range is 0 to 9 10:4 row(7:0) valid range 0 to 127 16:11 bank(5:0) valid range is 0 to 32 ca_reb Color channel A read enable (active low) ca_web Color channel A write enable (active low) ca_din (95:0) Color channel A quad
read bus.  4 .times.  24 bit color for a quad.  (23:0) color for the upper left pixel in the quad (47:24) color for the upper right pixel in the quad (63:48) color for the lower left pixel in the quad (95:64) color for the lower right pixel in the quad
Cdout (95:0) Color channels A and B quad color write bus.  4 .times.  24 bit color for the quad Refer to ca_din for pixel locations on the bus.  cb_addr (16:0) Color channel B quad address (refer to ca_addr for bit-fields) cb_reb Color channel B read
enable (active low) cb_web Color channel B write enable (active low) cb_din (95:0) Color channel B quad read bus (refer to ca_din for pixel locations)
Copy out operations, implemented in this example through what is referred to as the copy pipeline, is used to further process the pixel data from the embedded frame buffer (EFB) and to ultimately write the frame data in a selected format into the
external frame buffer (XFB) 113 of main memory 112 as display data for display by the video interface or as texture data for later use by the graphics pipeline (see FIG. 11).  RGB(A) or YUV420 data in the EFB can be copied out to main memory YUV422,
fields or frames.  YUV422 data is copied out in scan-line order.  There is a stride to allow skipping memory bytes between scan lines.  Y8 is the lowest address, followed by U8, Y8 and V8.  Copying in YUV format reduces the amount of memory used in main
memory by 1/3.
A general block diagram of the copy pipeline, as it mainly relates to the processing of data from the EFB when in either of the two RGB(A) pixel configurations, is shown in FIG. 9.  As shown in FIG. 9, this aspect of the copy pipeline includes an
anti-alias/deflicker section 622, a gamma correction section 623, an RGB to YUV conversion section 624, and a Y scale section 626.
A more complete block diagram of the copy out pipeline for all EFB configurations (i.e. RGB(A) and YUV) is shown in FIG. 12.  FIG. 11 shows the various paths that data can take between the various elements of the system.  As shown in FIG. 12, in
order to reduce the amount of buffering needed for filtering operation in this example, a copy rectangle is broken into 32.times.32 tiles.  The tiles are double buffered by using two tile buffers 625a and 625b, so that while one tile is being filled, the
other is being read and processed to be sent to main memory.  A rectangle is preferably decomposed into tiles in the Y direction, followed by tiles in the X direction.  Within a tile 4 pixels in a span are processed in one cycle.  The pixel quads are
processed in Y order followed by X.
Referring now more particularly to FIG. 12, the particular copy pipeline operation depends on the particular configuration of the data in the embedded frame buffer and on the programmers desired result of the copy out operation.  As explained
above, the color buffer may contain RGB8, RGBA6, R5G6B5 (anti-aliasing) or YUV420 data, and the Z buffer may contain 24-bit Z or 3.times.16-bit Z (anti-aliasing).  FIG. 12e shows a preferred conversion matrix for the various data formats available in
If the embedded frame buffer is configured for and contains data in any of the RGB(A) formats describe above, the copy pipeline performs anti-aliasing/deflickering operations, preferably using a programmable 7-tap vertical filter, as illustrated
by block 628 in FIG. 12.  As described in greater detail below, this filter blends the point sampled or supersampled (anti-aliasing) pixel data from multiple pixels and outputs a resulting pixel color.  Once blended, gamma correction is performed, as
illustrated by block 623.  An optional conversion can then be performed, if desired for the particular application, to convert the RGB data to YUV444 format (block 641).  If the data was converted to YUV 444 at block 641, then another optional conversion
can be performed at block 644 to convert from YUV444 to YUV422.  If the copy pipe is being used for display, this conversion to YUV422 can be performed to put the data in main memory display format, which is YUV422 in this example.  The tile data is then
buffered at tile buffers 625a and 625b as explained above.  Then, if the tile is intended for display, Y scaling is performed at block 626, and the scaled data is copied out to main memory in YUV422 format (block 642) for use by the video interface.  On
the other hand, if the data is intended to be used as a texture, Y scaling is not performed.  Instead, the tile data is formatted into the desired texture at block 640 and sent to main memory as a texture tile for possible use in a subsequent graphics
pipeline operation.  The possible texture formats in this example are shown in FIG. 12e and are listed below in connection with the texture copy commands and register bit definitions.
If the embedded frame buffer is configured for and holds data in YUV420 format as described above, the copy pipeline has a slightly different operation as shown by the lower portion of FIG. 12.  Specifically, the YUV420 data from the color buffer
is first converted to YUV444 format (block 646).  An optional conversion from YUV444 to RGB can then be performed at block 648.  The data path is then the same as described above with respect to the RGB(A) configurations.  That it, the tile can be
optionally converted, at block 644, to YUV422 (if previously converted to YUV444), then buffered and either scaled and sent to main memory as display data or converted to a desired texture format and stored as a texture tile in main memory.  FIG. 12f
shows an example of how texture tiles (e.g. tiles 1-4) are stored in main memory.
Textures can be created by copying the Embedded Frame Buffer (EFB) to main memory using the GXCopyTex function.  This is useful when creating dynamic shadow maps, environment maps, motion blur effects, etc.
All non-color index texture types except compressed textures (GX_TF_CMPR) can be created during the copy.  The texture copy operation will create the correct tiling and formatting of the texture so it can be read directly by the hardware.
Optionally, a box filter can be applied to the image in the EFB in order to create a lower level of detail (LOD) texture.  The box filter can be used to create mipmaps from the EFB data.  The following table shows exemplary texture copy formats and
conversion notes.
TABLE-US-00003 Format Conversion GX_TF_I4 RGB -&amp;gt; (Y)UV, AA and non-AA pixel formats GX_TF_I8 RGB -&amp;gt; (Y)UV, AA and non-AA pixel formats GX_TF_A8 A (6 bits) -&amp;gt; A (8-bits, 2 MSBs replicated in LSBs), only with pixel format GX_PF_RGBA6_Z24
GX_TF_IA4 RGBA -&amp;gt; (Y)UV(A), if pixel format is not GX_PF_RGBA6_Z24, then A = 0xf GX_TF_IA8 RGBA -&amp;gt; (Y)UV(A), if pixel format is not GX_PF_RGBA6_Z24, then A = 0xff GX_TF_RGB565 RGB -&amp;gt; RGB, bits truncated for non-AA pixel formats.  GX_TF_RGB5A3
RGBA -&amp;gt; RGBA, if pixel format is not GX_PF_RGBA6_Z24, then MSB = 1.  i.e., R5G5B5 GX_TF_RGBA8 RGBA -&amp;gt; RGBA, if pixel format is not GX_PF_RGBA6_Z24, then A = 0xff GX_TF_Z24X8 Z (24 bits) -&amp;gt; Z (32 bits), only when pixel format is non-antialiased,
GB_PF_RGB8_Z24 or GX_PF_RGBA6_Z24
Normally, the source and destination rectangles would have the same size.  However, when copying small textures that will be composited into a larger texture the source and destination rectangles may differ.  The format GX_TF_A8 is used
specifically to copy the alpha channel from the EFB into a GX_TF_I8 formatted texture.  The GX_TF_I8 will copy the luminance of the EFB into a GX_TF_I8 texture.  When reading a texture, GX_TF_A8 and GX_TF_I8 are equivalent.  When color textures are
converted from an GX_PF_RGB8_Z24 pixel format to a lower-resolution color format, like GX_TF_RGB565, the least significant bits (LSBs) of the 8-bit colors are truncated.  When color textures are converted from a lower resolution pixel format, such as
GX_PF_RGB565_Z16, to a higher resolution texture format, such as GX_TF_RGB8, the most significant bits (MSBs) of each pixel are replicated in the LSBs of each texel.  This conversion process distributes the estimation error evenly and allows each texel
to represent the minimum or maximum value.  In general, one should only copy textures containing alpha from an EFB with format GX_PF_RGBA6_Z24.  When copying texture containing alpha from an EFB without alpha, alpha will be set to its maximum value.  The
GX_TF_Z24X8 format can be used to copy the 24-bit Z buffer to a 32-bit texture (equivalent format to GX_TF_RGBA8).  To copy a texture, the application preferably first allocates a buffer in main memory the size of the texture to be copied.  This size can
be determined using, for example, a GXGetTexBufferSize function.  This function preferably takes into account texture padding and texture type in its calculations.
As can be seen from the above description, the copy out process in accordance with the instant invention enables various data formats to be used and various conversions/operations to be performed such that significant flexibility and
functionality is provided thereby.  By supporting YUV formats and enabling copy out as a texture, the copy pipeline line can be used to, for example, assist the main processor in performing motion compensation.  The copy out process as described above
can be used not only to efficiently move and process data from the embedded frame buffer to the external frame buffer for display or as texture, but it also enables, for example, streaming video to be superimposed on a polygon by using the texture copy
feature based on MPEG data which uses the YUV color space.
As briefly explained above, when anti-aliasing is desired and the embedded frame buffer is configured for the 96-bit anti-aliased pixel data (e.g. R5G6B5 and Z16), a second stage of anti-aliasing can be performed during copy out.  Specifically,
the second stage of anti-aliasing is performed by the anti-aliasing/deflicker section 622 during copy-out from the embedded frame buffer (EFB) 702 to the external frame buffer (XFB) 113.
The anti-aliasing/deflickering section 622 of the copy pipeline preferably applies a 7 tap vertical filter 628 (see FIG. 12a) having programmable weightings (W0-W6) for each super-sample.  The support for the vertical filter is preferably a
three-vertical-pixel area.  Thus, when determining color for a current pixel N in anti-aliasing mode, super-samples in the pixel immediately above the current pixel (N-1), and super-samples in the pixel immediately below the current pixel (N+1), as well
as super-samples in the current pixel are preferably used.  Preferably, the farthest sample from the current pixel within each of the two surrounding pixels is not used in the filtering operation.  Thus, while the three pixel support for the filter has
nine samples, only seven of the nine samples are used in the blending operation in the example embodiment.  The resulting vertical filter output provides a single screen pixel color value (N&#39;) for eventual copying into the external frame buffer and
display on display device 56.
In order to avoid the use of full line buffers, the copy operation preferably uses anti-aliasing (AA) buffering, wherein the copy is performed in strips of 32 pixels wide (X axis).  The data-path for the strip-buffers in this exemplary AA
buffering is shown in the block diagram of FIG. 12b.
It is noted that additional details regarding anti-aliasing/de-flickering techniques and arrangements are provided in the commonly owned and co-pending application identified above.  Inasmuch as this invention is directed to the embedded frame
buffer and the overall copy out operation, regardless of the specific anti-aliasing operation used, further details regarding anti-aliasing are not provided herein.
The same vertical filter can be used during copy-out in a non-anti-aliasing mode to achieve a de-flickering function using point sampled pixels.  In this mode, the sample patterns are not programmable.  As shown in FIG. 12c, the hardware uses
only the center of the pixel as the sample locations.  The weighting coefficients (W0-W6) for each point sample are programmable as with the anti-aliasing filter.  Thus, the vertical filter 628a in de-flickering mode uses three inputs (center only) from
the current pixel and two inputs (center only) from each of the two vertically neighboring pixels, thereby obtaining the seven values for the filtering operation.  The programmable weighting coefficients are applied to the seven samples, and then the
results are added to obtain the final pixel color (N&#39;).  Preferably, the de-flickering filter and AA filter are shared.  The four strip buffers used in the AA data path (see FIG. 12b) are also used to store quad strips.  An exemplary block diagram of the
data-path for de-flicker buffering is shown in FIG. 12d.  Further details regarding de-flickering are provided in the co-pending application identified above.
A luma/chroma (YUV) format stores the same visual quality pixel as RGB, but requires only two-thirds of the memory.  Therefore, during the copy operation, the RGB(A) format in the EFB is converted to a YUV format in the XFB, in order to reduce
the amount of main memory used for the external frame buffer (XFB).  This conversion is done by the RGB to YUV section 624.  An illustration of the conversion operation is shown in FIG. 10a, wherein the RGB data is initially converted to YUV444 format
and then down-sampled to YUV 422 format for storage in the XFB as display data.
The Y scale section 626 in the copy pipeline enables arbitrary scaling of a rendered image in the vertical direction.  Horizontal scaling is preferably done during video display.  A Y scale factor is defined in the API and determines the number
of lines that will be copied, and can be used to compute the proper XFB size.  A block diagram for the preferred vertical scaling in accordance with the instant invention is shown in FIG. 10b.  Vertical scaling is performed by using 8-bit lerps between 2
adjacent vertically adjacent strips.  The lerp coefficient starts at 1.0.  After a scan-line is outputted a fixed point (1.8) value is added to the lerp coefficient.  The carry out of the lerp coefficients signals that a new scan-line is to be used.  Two
strip buffers 626a and 626b are used to keep 2 partial scan-lines that are on top of each other.  Buffer A (626a) holds all incoming strips with even y value, while buffer B (626b) holds all the odd y value strips.
The gamma correction section 623 is used to correct for the non-linear response of the eye (and sometimes the monitor) to linear changes in color intensity values.  Three choices of gamma may be provided (such as 1.0, 1.7 and 2.2).  The default
gamma is preferably 1.0 and is set in, for example, a GXInit command in the API.
This conversion is used to reduce the amount of external frame-buffer needed by 1/3.  The following equations are used for the conversion: Y=0.257R+0.504G+0.098B+16 Cb=-0.148R-0.291G+0.439B+128 Cr=0.439R-0.368G-0.071B+128
An illustration of the YUV444 to YUV422 conversion is shown in FIG. 13.  The following equations are used for this conversion: c&#39;(0,0)=1/4*c(0,0)+1/2*c(0,0)+1/4*c(1,0) c&#39;(2,0)=1/4*c(1,0)+1/2*c(2,0)+1/4*c(3,0)
c&#39;(4,0)=1/4*c(3,0)+1/2*c(4,0)+1/4*c(5,0) c&#39;(m,n)=1/4*c(m-1,n)+1/2*c(m,n)+1/4*c(m+1,n)
This conversion is done in two parts, as illustrated in FIGS. 14a and 14b.  The first part, shown in FIG. 14a, converts from YUV420 format to YUV422 format.  This conversion uses the following equations: c&#39;(0,0)=3/4*c(0,0.5)+1/4*c(0,0.5)
c&#39;(2,0)=3/4*c(2,0.5)+1/4*c(2,0.5) c&#39;(4,0)=3/4*c(4,0.5)+1/4*c(4,0.5) c&#39;(0,1)=3/4*c(0,0.5)+1/4*c(0,2.5) c&#39;(2,1)=3/4*c(2,0.5)+1/4*c(2,2.5) c&#39;(4,1)=3/4*c(4,0.5)+1/4*c(4,2.5) c&#39;(0,2)=3/4*c(0,2.5)+1/4*c(0,0.5) c&#39;(2,2)=3/4*c(2,2.5)+1/4*c(2,0.5)
c&#39;(4,2)=3/4*c(4,2.5)+1/4*c(4,0.5) c&#39;(m,n)=3/4*c(m,n-0.5)+1/4*c(m,n+1.5) for n=odd c&#39;(m,n)=3/4*c(m,n+0.5)+1/4*c(m,n-1.5) for n=even
The second part of this YUV420 to YUV444 conversion, as shown in FIG. 14b, up-samples the YUV422 data from part one above to YUV444.  This conversion uses the following equations: c&#39;(0,0)=c(0,0) c&#39;(1,0)=1/2*c(0,0)+1/2*c(2,0) c&#39;(2,0)=c(2,0)
c&#39;(3,0)=1/2*c(2,0)+1/2*c(4,0) c&#39;(m,n)=c(m,n) m is odd c(m,n)=1/2*c(m-1,n)+1/2c(m+1,n) m is even
MPEG2 operates in YCbCr (YUV) color space.  This conversion can be used to convert the YUV data to RGB data during copy out.  The following equations are used for this conversions: R=1.164(Y-16)+1.596(Cr-128)
G=1.164(Y-16)-0.813(Cr-128)-0.391(Cb-128) B=1.164(Y-16)+2.018(Cb-128)
TABLE-US-00004 u16 SrcLeft //Upper-Left coordinate of the source rectangle u16 SrcTop u16 SrcWidth //Width, in pixels, of the source rectangle u16 SrcHeight //Height, in pixels, of the source rectangle Void* DstBase //Address of destination
buffer in memory u16 DstStride //Stride, in multiple of 32B, of destination buffer GXBool Clear //enable clearing color and Z frame buffers
This function copies the contents of the embedded frame buffer (EFB) to the display buffer 113 in main memory.  By the term &quot;copy out&quot; we don&#39;t mean simply a transfer of all the information; rather, we mean that the contents of the embedded frame
buffer are read out, further processed (e.g., filtered, resampled, scaled, etc.) and that the resulting data is then sent elsewhere (e.g., to an external point sample type frame buffer).  The origin of the rectangle is defined by SrcLeft(X) and SrcTop
(Y).  The Clear flag enables clearing of the color and z buffer to the current clear color and z values.  The clearing of the embedded frame buffer preferably occurs simultaneously with the copy operation.
TABLE-US-00005 GXFbClamps ClampFlags; //Clamping flags for framebuffer filtering.  GXTexFormats TexFormat; //Format of texture (i.e. destination) pixels.  GXFbInterlace Interlaced; //Display buffer is interlaced (YUV422).  GXGamma Gamma; //Gamma
correction on display buffer pixels.  u16 VertScale; //vertical 1/scale value (1.8 format).  GXBool MipFilter; // Apply mipmap filter (texture copy only).
This function sets the controls used during copy from the embedded frame buffer to the display buffer.  These controls are set once and then multiple copy commands can be issued.
TABLE-US-00006 u16 SrcLeft //Upper-Left coordinates of the source rectangle.  u16 SrcTop; u16 SrcWidth; //Width, in pixels, of the source.  u16 SrcHeight; //Height, in pixels, of the source rectangle.  void* DstBase; //Address of destination
buffer in memory (32B aligned).  u16 DstStride; //Stride, in multiple of 32 B, of destination buffer.  GXBool Clear; //Enable clearing color and z framebuffers.
TABLE-US-00007 GX_CLAMP_TOP, //Clamp top edge of image for filtering.  GX_CLAMP_BOTTOM, //Clamp bottom edge of image for filtering.
TABLE-US-00008 GX_INTLC_OFF //Interlace is off.  GX_INTLC_EVEN //Interlace even lines.  GX_INTLC_ODD //Interlace odd lines.
TABLE-US-00009 GX_ZC_LINEAR, //Linear 16 bit z. No compression.  GX_ZC_14E2 //14e2 floating point format.  GX_ZC_13E3 //13e3 floating point format.
TABLE-US-00010 GX_GM_1_0 //Gamma 1.0 GX_GM_1_7 //Gamma 1.7 GX_GM_2_2 //Gamma 2.2
TABLE-US-00011 GX_TF_I4 //Intensity 4 bits GX_TF_I8 //Intensity 8 bits GX_TF_IA4 //Intensity-Alpha 8 bit (44) GX_TF_IA8 //Intensity-Alpha 16 bit (88) GX_TF_C4 //Color Index 4 bit GX_TF_C8 //Color Index 8 bit GX_TF_CA4 //Color Index + Alpha 8 bit
(44) GX_TF_C6A2 //Color Index + Alpha 8 bit (62) GX_TF_CA8 //Color Index + Alpha 16 bit (88) GX_TF_R5G6B5 //RGB 16 bit (565) GX_TF_RGB5A1 //RGB 16 bit (5551) GX_TF_RGBA8 //RGB 32 bit (8888) GX_TF_CMPR //Compressed 4 bits/texel.  RGB8A1.
TABLE-US-00012 GX_PF_RGB8_Z24 GX_PF_RGBA6_Z24 GX_PF_RGB565_Z16 GX_PF_Z24 //used for z buffer copy (diagnostics only) GX_PF_Y8 GX_PF_U8 GX_PF_V8 GX_PF_YUV420 //used for YUV copy.
FIGS. 15-17 show exemplary registers used by the pixel engine in connection with the copy out operations.  Specifically, FIG. 15 shows an exemplary control register.  The bit definitions for this exemplary control register are as follows:
TABLE-US-00013 2:0 pixtype 5:3 zcmode 000: linear z compression for 16 bit Z 000: RGB8/Z24 001: 14e2 z compression for 16 bit Z 001:RGBA6/Z24 010: 13e3 z compression for 16 bit Z 010:RGB_AA/Z16 011: 12e4 z compression for 16 bit Z 011:Z (for
copying Z buffer as texture 100: inverted_linear z compression for 16 bit Z 100: Y8 or U8 or V8 101: inverted_14e2 z compression for 16 bit Z 101: YUV 420 (only used for copy operation) 110: inverted_13e3 z compression for 16 bit Z 111: inverted_12e4 z
compression for 16 bit Z 6: ztop 0: z at the end of the pipe 1: z buffering before texture mapping
Bits 0-2 designate the pixel type for the copy operation.  Writing to this control register causes the graphics pipe stages between the edge rasterizer (RAS0) and the pixel engine (PE) to be flushed.  In this example, this will can take a minimum
of 90 cycles.  Writing to this register can also be used to sync up copy texture with rendering a primitive that uses the texture.
FIG. 16 shows an exemplary register for the copy to texture operation.  The bit definitions for this exemplary register are as follows:
TABLE-US-00014 1:0 src_clamp x1: clamp top 1x: clamp bottom 2 color conversion 0: no color conversion 1: convert RGB to YUV 6:3 tex_format pixtype: rgb8, rgba6, rgb_aa yuv8 yuv8 yuv8 yuv420 yuv420 z yuvsel: x x Y U V x x x ccv_mode: OFF ON OFF
OFF OFF OFF ON OFF 0000: R4 Y4 Y4 U4 V4 Y4 R4 z[23:20] 0001: R8 Y8 Y8 U8 V8 Y8 R8 z[23:16] 0010: RA4 YA4 YA4 UA4 VA4 YA4 RA4 0011: RA8 YA8 YA8 UA8 VA8 YA8 RA8 0100: R5G6B5 Y5U6V5 Y5Y6Y5 U5U6U5 V5V6V5 Y5Y6Y5 R5R6B5 0101: RGB5A3 YUV5A3 YYY5A3 UUU5A3 VVV5A3
YUV5A3 RGB5A3 0110: RGBA8 YUVA8 YYYA8 UUUA8 VVVA8 YUVA8 RGVA8 z[23:00], 0xff 0111: A8 A8 0xff 0xff 0xff 0xff 0xff 0xff 1000: R8 Y8 Y8 U8 V8 Y8 R8 z[23:16] 1001: G8 U8 Y8 U8 V8 U8 G8 z[15:08] 1010: B8 V8 Y8 U8 V8 V8 B8 z[07:00] 1011: RG8 YU8 YY8 UU8 VV8
YU8 RG8 z[23:16] (red as intensity and Green as alpha) 1100 GB8 UV8 YY8 UU8 VV8 UV8 GB8 z[15:00] 8:7 gamma (only when arc_format is any of the RGB formats) 00: gamma = 1.0 01: gamma = 1.7 10: gamma = 2.2 11: reserved 9: mip_map_filter 0: no filtering
(1:1) 1: box filtering (2:1) 11: clr (should be set to 0 for rgb_aa) 0: do not clear Z and Color efb 1: clear Z and color efb 13:12 intlc 00: progressive 01: reserved 10: interlaced (even lines) 11: interlaced (odd lines) 16:15 ccv_mode 0X: automatic
color conversion,  based on pixtype and texture format 10: color conversion off (rgb to yuv) 11: color conversion on (rgb to yuv)
The pixel types allowed for this operation are RGB8, RGBA6, RGB_AA (i.e. anti-aliasing (R5G6B5)), YUV8 and YUV420.  Bits 3-6 determine the format of the texture stored by the copy command in texture buffer.  In this example, this texture
formatting is done in the texture format section 640 shown in FIG. 12.  In this example, Clr is not supported for pixel type YUV420 and should be set to 0.  Gamma correction is also not supported for pixel type YUV420 in this example.
FIG. 17 shows an exemplary register for the copy to display operation.  The bit definitions for this exemplary register are as follows:
TABLE-US-00015 1:0 src_clamp 10:scen x1: clamp top 0: no vertical scaling 1x: clamp bottom 1: vertical scaling 8:7 gamma (only when src_format 11:clr (should be set to zero for is any of the RGB formats) rgb_aa) 00: gamma = 1.0 0: do not clear Z
and Color efb 01: gamma = 1.7 1: clear Z and color efb 10: gamma = 2.2 13:12 intlc 11: reserved 01: reserved 00: progressive 10: interlaced (even lines) 11: interlaced (odd lines)
The pixel types allowed for this operation are RGB8, RGBA6, RGB_AA (anti-aliasing) and YUV420.  Clr is not supported for pixel type YUV420 and should be set to 0.  Gamma correction is also not supported for pixel type YUV420 in this example.
Graphics system with embedded frame butter having reconfigurable pixel formats, Van Hook, et al., Timothy J. Van Hook, Farhad Fouladi, Application number 11 398-531, Computer Graphics Processing And Selective Visual Display Systems, graphics system, frame buffer, 3D graphics, audio processor, graphics processor, graphics pipeline, main memory, Google Patent Search, anti-aliasing filter, pixel formats
The present invention relates to computer graphics, and more particularly to interactive graphics systems such as home video game platforms. Still more particularly this invention relates to a graphics system having a reconfigurable embeddedframe buffer which advantageously enables the selection of particular pixel formats on a frame-by-frame basis for data stored therein.BACKGROUND AND SUMMARY OF THE INVENTIONMany 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 howeach 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 requiredto 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 otherfactors.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 sawsome 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 ofrelatively 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 relativelyinexpensive computer graphics systems in your home or office.A problem graphics system desig
Graphics Subsystem in an Embedded World
ECE398 embedded system
A Low-Power Graphics LSI integrating 29Mb Embedded DRAM for Mobile Embedded System 2012-13 Projects