Source: http://www.google.com/patents/US20100073394?ie=ISO-8859-1
Timestamp: 2014-11-26 06:29:56
Document Index: 670086393

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

Patent US20100073394 - Graphics system with embedded frame buffer having reconfigurable pixel formats - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA graphics system including a custom graphics and audio processor produces exciting 2D and 3D graphics and surround sound. The system includes a graphics and audio processor including a 3D graphics pipeline and an audio digital signal processor. The graphics system has a graphics processor includes an...http://www.google.com/patents/US20100073394?utm_source=gb-gplus-sharePatent US20100073394 - Graphics system with embedded frame buffer having reconfigurable pixel formatsAdvanced Patent SearchPublication numberUS20100073394 A1Publication typeApplicationApplication numberUS 12/461,238Publication dateMar 25, 2010Filing dateAug 5, 2009Priority dateAug 23, 2000Also published asUS7576748, US7995069, US20060197768Publication number12461238, 461238, US 2010/0073394 A1, US 2010/073394 A1, US 20100073394 A1, US 20100073394A1, US 2010073394 A1, US 2010073394A1, US-A1-20100073394, US-A1-2010073394, US2010/0073394A1, US2010/073394A1, US20100073394 A1, US20100073394A1, US2010073394 A1, US2010073394A1InventorsTimothy J. Van Hook, Farhad FouladiOriginal AssigneeNintendo Co., Ltd.Export CitationBiBTeX, EndNote, RefManReferenced by (1), Classifications (6) External Links: USPTO, USPTO Assignment, EspacenetGraphics system with embedded frame buffer having reconfigurable pixel formatsUS 20100073394 A1Abstract A graphics system including a custom graphics and audio processor produces exciting 2D and 3D graphics and surround sound. The system includes a graphics and audio processor including a 3D graphics pipeline and an 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.
29. 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:
30. The graphics processor of claim 29, wherein the YUV format is a YUV 4:2:0 format.
31. The graphics processor of claim 29, wherein the point sampled format is a 48-bit format and the super-sampled format is a 96-bit format
32. The graphics processor of claim 31, wherein the 48-bit format includes 24 color bits and 24 depth bits.
33. A graphics system, comprising:
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. 33. The graphics system of claim 33, wherein the YUV format is a YUV 4:2:0 format.
34. The graphics system of claim 33, wherein the point sampled format is a 48-bit format and the super-sampled format is a 96-bit format
35. The graphics system of claim 34, wherein the 48-bit format includes 24 color bits and 24 depth bits.
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 �Vertex Cache For 3D Computer Graphics�, 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�, provisional Application No. 60/226,889, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,419, filed Nov. 28, 2000 (atty. dkt. no. 723-958), both entitled �Graphics Pipeline Token Synchronization�, provisional Application No. 60/226,891, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,382, filed Nov. 28, 2000 (atty. dkt. no. 723-961), both entitled �Method And Apparatus For Direct to and Indirect Texture Processing In A Graphics System�, provisional Application No. 60/226,888, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,367, filed Nov. 28, 2000 (atty. dkt. no. 723-968), both entitled �Recirculating Shade Tree Blender For A Graphics System�, provisional Application No. 60/226,892, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,218, filed Nov. 28, 2000 (atty. dkt. no. 723-960), both entitled �Method And Apparatus For Efficient Generation Of Texture Coordinate Displacements For Implementing Emboss-Style Bump Mapping In A Graphics Rendering System�, provisional Application No. 60/226,893, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,381 filed Nov. 28, 2000 (atty. dkt. no. 723-962), both entitled �Method And Apparatus For Environment-Mapped Bump-Mapping In A Graphics System�, provisional Application No. 60/227,007, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,216, filed Nov. 28, 2000 (atty. dkt. no. 723-967), both entitled �Achromatic Lighting in a Graphics System and Method�, provisional Application No. 60/226,900, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,226, filed Nov. 28, 2000 (atty. dkt. no. 723-964), both entitled �Method And Apparatus For Anti-Aliasing In A Graphics System�, utility application Ser. No. 09/585,329, filed Jun. 2, 2000, entitled �Variable Bit Field Color Encoding� (atty. dkt. no. 723-749), provisional Application No. 60/226,890, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,227, filed Nov. 28, 2000 (atty. dkt. no. 723-956), both entitled �Method And Apparatus For Dynamically Reconfiguring The Order Of Hidden Surface Processing Based On Rendering Mode�, provisional Application No. 60/226,915, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,212 filed Nov. 28, 2000 (atty. dkt. no. 723-973), both entitled �Method And Apparatus For Providing Non-Photorealistic Cartoon Outlining Within A Graphics System�, provisional Application No. 60/227,032, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,225, filed Nov. 28, 2000, (atty. dkt. no. 723-954), both entitled �Method And Apparatus For Providing Improved Fog Effects In A Graphics System�, provisional Application No. 60/226,885, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,664, filed Nov. 28, 2000, (atty. dkt. no. 723-969), both entitled �Controller Interface For A Graphics System�, provisional Application No. 60/227,033, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,221, filed Nov. 28, 2000 (atty. dkt. no. 723-955), both entitled �Method And Apparatus For Texture Tiling In A Graphics System�, provisional Application No. 60/226,899, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,667, filed Nov. 28, 2000 (atty. dkt. no. 723-971), both entitled �Method And Apparatus For Pre-Caching Data In Audio Memory�, provisional Application No. 60/226,913, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,378, filed Nov. 28, 2000 (atty. dkt. no. 723-965), both entitled �Z-Texturing�, provisional Application No. 60/227,031, filed Aug. 23, 2000 entitled �Application Program Interface for a Graphics System� (atty. dkt. no. 723-880), provisional Application No. 60/227,030, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,663, filed Nov. 28, 2000 (atty. dkt. no. 723-963), both entitled �Graphics System With Copy Out Conversions Between Embedded Frame Buffer And Main Memory�, provisional Application No. 60/226,886, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,665, filed Nov. 28, 2000 (atty. dkt. no. 723-970), both entitled �Method and Apparatus for Accessing Shared Resources�, provisional Application No. 60/226,894, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/726,220, filed Nov. 28, 2000 (atty. dkt. no. 723-974), both entitled �Graphics Processing System With Enhanced Memory Controller�, provisional Application No. 60/226,914, filed Aug. 23, 2000 and its corresponding utility application Ser. No. 09/722,390, filed Nov. 28, 2000, (atty. dkt. no. 723-966), both entitled �Low Cost Graphics System With Stitching Hardware Support For Skeletal Animation�, 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 (atty. dkt. no. 723-953), both entitled �Shadow Mapping In A Low Cost Graphics System�. FIELD OF THE INVENTION 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.
Example Configurations for the Embedded Frame Buffer 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.
Example RGB(A) Formats for the Embedded Frame Buffer 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:
96-Bit Pixel Size Configuration The 96-bit super-sampling pixel format is preferably used for anti-aliasing and has the following features:
Anti-Aliasing Using the 96-Bit Configuration 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 �Method and Apparatus For Anti-Aliasing In A Graphics System�, 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.
YUV Embedded Frame Buffer Configuration 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�576), U (360�288) and V (360�288) image planes for a YUV 4:2:0 frame. The partitioning of the color buffer preferably allocates as follows:
Example Pixel Format Command 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:
Interface Between the Pixel Engine and the Embedded Frame Buffer 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 (702 a, 702 b, 702 c and 702 d)�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 703 a, and the color channels A and B preferably share a separate write port 703 b. 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�528�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:
PE - EFB Interface
za_addr (16:0)
Z channel A quad address. There are 3 subfields:
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. 4x24 bit Z for a quad.
zdout (95:0)
Z channels A and B quad Z write bus. 4x24 bit Z
zb_addr (16:0)
Z channel B quad address (refer to za_addr for
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
ca_addr (16:0)
C channel A quad address. There are 3 subfields:
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. 4x24 bit color for
Cdout (95:0)
Color channels A and B quad color write bus.
4x24 bit color for the quad
cb_addr (16:0)
Color channel B quad address (refer to ca_addr
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
Example Copy Out Operations and Pipeline 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 ⅓.
RGB −> (Y)UV, AA and non-AA pixel
A (6 bits) −> A (8-bits, 2 MSBs replicated in
RGBA −> (Y)UV(A), if pixel format is not
RGB −> RGB, bits truncated for non-AA
RGBA −> RGBA, if pixel format is not
Z (24 bits) −> Z (32 bits), only when pixel
Exemplary Anti-Aliasing During Copy Out 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.
Exemplary De-Flicker Filtering During Copy Out 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,
Example RGB to YUV Conversion During Copy Out 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. 10 a, 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.
Vertical (Y) Scaling During Copy Out 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. 10 b. 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 626 a and 626 b are used to keep 2 partial scan-lines that are on top of each other. Buffer A (626 a) holds all incoming strips with even y value, while buffer B (626 b) holds all the odd y value strips.
Gamma Correction During Copy Out 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.
Example Conversion Operations Usable During Copy Out RGB to YCrCb(4:4:4) Conversion
c′(0,0)=�*c(0,0)+�*c(0,0)+�*c(1,0)
c′(m,n)=�*c(m,n−0.5)+�*c(m,n+1.5) for n=odd
c′(m,n)=�*c(m,n+0.5)+�*c(m,n−1.5) for n=even
c(m,n)=�*c(m−1,n)+�c(m+1,n) m is even
Example Copy Out Commands The EFB source and destination of the display copy operation is specified using an exemplary API function as follows:
GX_CLAMP_TOP,
//Clamp top edge of image for filtering.
GX_CLAMP_BOTTOM,
//Clamp bottom edge of image for filtering.
GX_INTLC_OFF
//Interlace is off.
GX_INTLC_EVEN
//Interlace even lines.
GX_INTLC_ODD
//Interlace odd lines.
GX_ZC_LINEAR,
//Linear 16 bit z. No compression.
GX_ZC_14E2
//14e2 floating point format.
GX_ZC_13E3
//13e3 floating point format.
GX_GM_1_0
//Gamma 1.0
GX_GM_1_7
//Gamma 1.7
GX_GM_2_2
//Gamma 2.2
//Intensity 4 bits
//Intensity 8 bits
//Intensity-Alpha 8 bit (44)
//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)
//RGB 32 bit (8888)
GX_TF_CMPR
//Compressed 4 bits/texel. RGB8A1.
GX_PF_Z24
//used for z buffer copy (diagnostics only)
GX_PF_YUV420
//used for YUV copy.
Example Pixel Engine Registers 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:
Referenced byCiting PatentFiling datePublication dateApplicantTitleWO2011123509A1 *Mar 30, 2011Oct 6, 2011Design & Test Technology, Inc.3d video processing unit* Cited by examinerClassifications U.S. Classification345/589International ClassificationG09G5/02Cooperative ClassificationG09G5/363, G06T15/005European ClassificationG09G5/36C, G06T15/00ARotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google