Engine for streaming virtual textures

An engine decompresses texture data belonging to a virtual texture stored in processor readable memory so that decompressed texture data may be used to update a selected sub-image of a large texture image used to render a CGI. The updated sub-image may be at any location in the larger texture image. A processor executes an application to provide control information to the engine. The control information may include commands to decode compressed texture data at source addresses and provide a stream of decompressed virtual texture data to selected sub-image destination addresses in a texture buffer used for rendering a CGI. Similarly, the engine may compress texture sub-image information and store the compressed result at a destination address.

BACKGROUND

Texture mapping is a method for adding detail, surface texture or color to a computer-generated image (CGI). A texture map is applied (mapped) to the surface of a shape or polygon. This process is similar to applying patterned paper to a plain white box.

Virtual texturing refers to a texturing method in which the physical memory pool available for texture storage is less than the total amount of texture that is potentially useable to produce a CGI. When rendering using a virtual texture, typically only portions of the virtual texture or lower-detail versions thereof are made available to an active texture pool for rendering.

SUMMARY

An engine decompresses texture data belonging to a virtual texture stored in processor readable memory so that decompressed texture data may be used to update a selected sub-image of a large texture image used to render a CGI. The updated sub-image may be at any location in the larger texture image. A processor executes an application to provide control information to the engine. The control information may include commands to decode compressed texture data at source addresses and provide a stream of decompressed virtual texture data to selected sub-image destination addresses in a texture buffer used for rendering a CGI. In embodiments, the engine may decompress lossy and lossless compressed texture data. For example, stored compressed texture data may be Joint Photographic Experts Group (JPEG) compressed texture data or Lempel-Ziv 77 (LZ77) compressed texture data.

The engine may include at least an integrated circuit having a controller, read/write buffers and LZ and/or JPEG decoders. In an embodiment, the engine may also have LZ and/or JPEG encoders to compress texture data. The engine may be included in a computing device having at least one processor and volatile memory in a system on a chip (SoC). In an embodiment, the at least one processor may be a graphics processor and/or central processor.

The application may be a video game software application and the computing device may be a video game console. In alternate embodiments, the computing device may be included in at least a cell phone, mobile device, embedded system, media console, laptop computer, desktop computer, server and/or datacenter.

A method embodiment includes operating an engine to decompress encoded texture information stored on processor readable memory. A control signal is received to initiate decompression of the compressed texture information. A start address of the compressed texture information and a destination address of a sub-rectangle image is also received. The compressed texture information is decoded to provide texture information that is output to the sub-rectangle image.

An apparatus embodiment includes at least one rendering processor that executes processor readable instructions to render a CGI using a texture image having a plurality of texture sub-images. At least one processor readable memory store compressed data representing texture of at least a first texture sub-image in the plurality of sub-images. An engine receives at least one command to decompress the compressed data representing a texture sub-image. The engine then stores the decompressed data representing the texture sub-image in the at least one processor readable memory. The at least one processor then uses the decompressed data representing texture in rendering a CGI by using the first texture sub-image in the plurality of sub-images. The engine may also decompress an entire texture image in an embodiment.

In another embodiment, at least one processor readable memory includes instructions which when executed cause the at least one processor to perform a method for decompressing compressed texture data. Memory space for an active texture pool is allocated. A determination of a sub-image area and detail level to be rendered is made. At least one command is transferred to an engine to decompress compressed texture data to texture data for the sub-image.

DETAILED DESCRIPTION

In order to facilitate updating arbitrarily selected portions of a very large image, such as a CGI, an engine decompresses compressed texture data and writes the decompressed texture data to a sub-image address in memory. The texture data may be JPEG and/or LZ compressed texture data, which itself may be either block coded or unencoded, and which may comprise color or depth values, or other types of values stored as a two-dimensional array. The engine accepts control information in the form of a command stream to decompress the compressed texture data. The engine then decompresses the selected compressed texture and writes the decompressed texture data to a texture buffer. Hardware, such as a graphics processor unit (GPU) along with an application, such as a video game, and other rendering software render the decompressed texture data at the selected portion of the CGI. The engine may also compress and store texture data at selected addresses in memory.

FIG. 1is a high-level block diagram of exemplary hardware architecture of a computing device100having an engine for streaming decompressed textures. In an embodiment, computing device100includes a compression/decompression engine (engine)105, memory102, and processor core(s) that may include CPU103and/or GPU104that communicate by way of signal path106. Memory102includes processor readable memory to store application107(such as a video game), compressed textures108and decompressed textures109a/bin texture buffer109(or active texture pool). In an embodiment, GPU104in response to application107, compressed textures108, engine105and texture buffer109renders at least one CGI using a predetermined virtual texture to a display.

Rendering is the process of generating a CGI from a 3D model (or models in what collectively could be called a scene file), by means of executing processor readable instructions in a software program. A scene file typically contains objects in a strictly defined language or data structure; a scene file would typically contain geometry, viewpoint, texture, lighting, and shading information as a description of the virtual scene. The data contained in the scene file is then passed to a rendering software program to be processed and output to a digital image or raster graphics image file that is used to display the at least one CGI.

Texture buffer109, in memory102, stores an active texture pool, such as decompressed textures109a/b. In an embodiment, a texture pool is composed of some predetermined number of physical sub-allocation chunks or pages (e.g. 64 K bytes) of texture data. For example, a 256×256 sub-texture with each texel being 4 bytes would consume exactly four 64 KB pages. Hardware, such as a GPU104, marks each virtual page of the full texture to be either a) invalid or b) valid and mapped to an arbitrarily placed physical page within the active texture pool via a page mapping method. A validity map may be stored in memory102and accessible by GPU104in embodiments.

A GPU is typically an integrated circuit able to assist a processor, such as CPU, in performing complex rendering calculations. The rendering software program executed by the GPU solves rendering equations that enable the CGIs to look relatively realistic and predictable under virtual lighting. In an embodiment, at least one rendering program includes processor readable instructions that are stored in memory102and executed by GPU104.

In an embodiment, computing device100is included in a video game and/or media console and application107is a video game software application that includes processor readable instructions when executed by at least one processor provide a video game to a display for a user. In alternate embodiments, computing device100may be included in at least a cell phone, mobile device, embedded system, media console, laptop computer, desktop computer, server and/or datacenter.

In an embodiment, computing device100includes a System on a Chip (SoC a.k.a. SOC)101as illustrated inFIG. 1. An SoC is an integrated circuit IC that integrates components of a computing device or other electronic system into a single chip or semiconductor substrate. In an embodiment, SoC101includes engine105, memory102, and CPU103, GPU104and signal path106. In alternate embodiment, CPU103and GPU104may be replaced with a single processor core. Alternatively, other processor cores may be included in SoC101. In an alternate embodiment, a SoC is not used.

As one of ordinary skill in the art would appreciate, other electronic components may also be included in SoC101. A SoC101may include digital, analog, mixed-signal, and/or radio frequency circuits—on a single semiconductor substrate. A SoC101may include oscillators, phase-locked loops, counter-timers, real-time timers, power-on reset generators, external interfaces (for example, Universal Serial Bus (USB), IEEE 1394 interface (FireWire), Ethernet, Universal Asynchronous Receiver/Transmitter (USART) and Serial Peripheral Bus (SPI)), analog interfaces, voltage regulators and/or power management circuits.

In alternate embodiments, SoC101may be replaced with a system in package (SiP) or package on package (PoP). In a SiP, multiple chips or semiconductor substrates are housed in a single package. In a SiP embodiment, processor core(s) would be on one semiconductor substrate and memory102would be on a second semiconductor substrate, both housed in a single package. In an embodiment, the first semiconductor substrate would be coupled to the second semiconductor substrate by wire bonding.

In a PoP embodiment, processor core(s) would be on one semiconductor substrate housed in a first package and memory102would be on a second semiconductor substrate housed in a second different package. The first and second packages could then be stacked with a standard interface to route signals between the packages, in particular the semiconductor substrates. The stacked packages then may be coupled to a printed circuit board. In an embodiment, memory102is positioned on top of processor core(s).

In embodiments, processor core(s) includes at least one processor that executes (or reads) processor (or machine) readable instructions, such as application107, stored in memory102. Processor core(s) use memory102in response to executing processor readable instructions of application107to provide a CGI incorporating virtual textures. Processor core(s) may also include a controller, central processing unit (CPU), GPU, digital signal processor (DSP) and/or a field programmable gate array (FPGA).

In an embodiment, memory102may represent at least one processor readable memory. In an embodiment, memory102may be a Wide I/O DRAM. Alternatively, memory102may be Low Power Double Data Rate 3 dynamic random access memory (LPDDR3 DRAM) memory (also known as Low Power DDR, mobile DDR (MDDR) or mDDR). In an embodiment, memory102may be a combination of different types of memory. In an embodiment, compressed textures108are stored in a first processor readable volatile or non-volatile memory that may be larger, slower, and less expensive, and decompressed textures109a/bare stored in a different second processor readable memory, preferably volatile, that may be smaller and faster.

In embodiments, memory102includes at least one array of memory cells in an IC disposed on a semiconductor substrate. In an embodiment, memory102is included in an integrated monolithic circuit housed in a separately packaged device than the processor core(s) and engine105. In embodiments, memory102may include volatile and/or non-volatile memory.

Types of volatile memory include at least dynamic random access memory (DRAM), molecular charge-based (ZettaCore) DRAM, floating-body DRAM and static random access memory (“SRAM”). Particular types of DRAM include double data rate SDRAM (“DDR”), or later generation SDRAM (e.g., “DDRn”).

Types of non-volatile memory include at least types of electrically erasable program read-only memory (“EEPROM”), FLASH (including NAND and NOR FLASH), ONO FLASH, magneto resistive or magnetic RAM (“MRAM”), ferroelectric RAM (“FRAM”), holographic media, Ovonic/phase change, Nano crystals, Nanotube RAM (NRAM-Nantero), MEMS scanning probe systems, MEMS cantilever switch, polymer, molecular, nano-floating gate and single electron.

In embodiments, signal path106(as well as other signal paths described herein) are media that transfers a signal, such as an interconnect, conducting element, contact, pin, region in a semiconductor substrate, wire, metal trace/signal line, or photoelectric conductor, singly or in combination. In an embodiment, multiple signal paths may replace a single signal path illustrated in the figures and a single signal path may replace multiple signal paths illustrated in the figures. In embodiments, a signal path may include a bus and/or point-to-point connection. In an embodiment, a signal path includes control and data signal lines to carry control and data information as well as timing information. In an alternate embodiment, a signal path includes data signal lines or control signal lines. In still other embodiments, signal paths are unidirectional (signals that travel in one direction) or bidirectional (signals that travel in two directions) or combinations of both unidirectional signal lines and bidirectional signal lines. When multiple memory arrays are used in the embodiment, multiple signal paths106may be used.

FIG. 2is a high-level block diagram of an exemplary engine105illustrated inFIG. 1. In an embodiment, engine105functions generally as a direct memory access (DMA) controller and at least one type of decoder to provide a stream of decompressed textures to a texture buffer109for rendering or access by GPU104executing a rendering program having processor readable instructions. In an embodiment, engine105may also include at least one type of encoder to compress data to allow efficient storage and transmission of sub-rectangle portions of CGIs or other data generated by the system.

A DMA controller typically allows a particular hardware subsystem within a computing device to access memory independently of a CPU, GPU or other processor. Without a DMA controller, when a CPU is using programmed input/output, the CPU is typically fully occupied for the entire duration of the read or write operation, and is thus unavailable to perform other work. With a DMA controller, the CPU typically initiates the transfer, does other operations while the transfer is in progress, and receives an interrupt from the DMA controller when the operation is done. This function is useful any time the CPU cannot keep up with the rate of data transfer, or where the CPU needs to perform useful work while waiting for a relatively slow I/O data transfer. Computing devices that have a DMA controller can transfer data to and from components with much less CPU overhead than computing devices without a DMA controller. Similarly, a processing core having a DMA controller function inside a multi-core processor can transfer data to and from its local memory without occupying its processor time, allowing computation and data transfer to proceed in parallel.

A DMA controller can also be used for “memory to memory” copying or moving of data within memory. A DMA controller can offload expensive memory operations, such as large copies or scatter-gathering operations, from the CPU to a DMA controller.

In an embodiment, CPU103and/or GPU104execute at least processor readable instructions of application107(as shown inFIG. 1) to generate control information on signal path220(that corresponds to signal path106) to engine105. In an embodiment, the control information directs engine105to retrieve compressed textures108, decode compressed textures108representing portions of at least one decompressed texture109a/band write the decompressed textures to a selected sub-rectangle addresses in texture buffer109. GPU104then uses the decompressed textures stored at a selected sub-rectangle address in texture buffer109to render a CGI using the decompressed texture in the next frame of video in an embodiment.

For example,FIG. 3illustrates mapping compressed textures stored in source memory to differently sized texture sub-images of a larger texture used in rendering a CGI. In particular,FIG. 3illustrates retrieving compressed texture sub-images302and303from a source (linear) memory301and writing the decompressed texture sub-images304and305to different sized regions within two texture images that will be rendered in the next update or frame of video. In an embodiment, compressed texture sub-images302and303correspond to compressed textures108in memory102and decompressed texture sub-images304and305correspond to decompressed textures109a/bin embodiments. Compressed texture sub-image302provides a 256×256 sub-image stored in a tile format for a Mip Level0(1024×1024) while compressed texture sub-image303provides a 128×128 sub-image stored in a tile format for a Mip Level1(512×512).

Mipmaps (a.k.a MIP maps or mip maps) are pre-filtered, optimized collections or sets of images that accompany a main full-resolution texture or image, intended to increase rendering speed and reduce aliasing artifacts in an embodiment. Each image of the mipmap set is a version of the main texture, but at a certain reduced level of detail. A scale difference between images in the mipmap set is known as a MIP level. For example, a main texture would have a MIP level0indicating the image has the most detail, a MIP level1would indicate a mipmap image that has less detail than the main texture at MIP level0, and so on. Although the main texture would still be used when the view is sufficient to render the main texture in full detail, render mechanisms will switch to a suitable mipmap image when the texture is viewed from a distance or at a small size. Rendering speed increases since the number of texture pixels (texels) being processed can be much lower than with simple textures. In an embodiment, compressed textures108include at least one texture mipmap.

If a main texture has a size of 1024×1024 pixels, then the associated mipmap set may contain a series of 10 images, each one-fourth the total area of the previous one: 1024×1024 pixels (Mip Level0), 256×256 (Mip Level1), 128×128 (Mip Level2), 64×64 (Mip Level3), 32×32 (Mip Level4), 16×16 (Mip Level5), 8×8 (Mip Level6), 4×4 (Mip Level7), 2×2 (Mip Level8), 1×1 (Mip Level9) (a single pixel). If, for example, a scene is rendering this texture in a space of 40×40 pixels, then either a scaled up version of the 32×32 (without trilinear interpolation in an embodiment) or an interpolation of the 64×64 and the 32×32 mipmaps (with trilinear interpolation in an embodiment) may be used. A mipmap set may be generated by successive averaging in an embodiment. In alternate embodiments, other methods can also be used to create a mipmap set.

Returning toFIG. 2, read data (such as compressed textures108), write data (such as decompressed textures109a/b) and control information are transferred to and from engine105on signal path220. Signal path220may include multiple signal paths to carry multiple bits of information in parallel and/or serially. Signal path120may also provide timing or clock information to and from engine105. Timing or clock information may synchronize the reception or transfer of data from and to engine105. In an embodiment, signal path120corresponds to signal path106shown inFIG. 1.

The control information may include at least one command and control value to decompress compressed texture data at source addresses and provide a stream of decompressed texture data to destination addresses in a texture buffer used for rendering using selected sub-images. The control information is provided so that engine105may fetch compressed texture data, decompress the compressed texture data, and transfer the decompress texture data to a texture buffer in a selected appropriate format.

In an embodiment, the control information is provided in the form of a command packet that includes a command value or code representing a command for engine105to perform and at least one associated control value (for examples source and destination addresses). In an embodiment, control information is provided in successive fields or multi-bit positions in the command packet. In an embodiment, at least one processor executes application107to output at least one command packet to engine105via signal path106. In an embodiment, engine105initiates such operation when interface201receives a command packet and at least one processor writes to a memory-mapped control register in interface201. In an embodiment, command packets are provided by a processor, such as CPU103, writing and transferring values in the form of digital bit values in contiguous fields of a command packet to engine105. Multiple command packets can be executed in succession by engine105.

Tables I and II illustrate exemplary command packets having specific exemplary control values in parentheses.

In an embodiment, each row of the command packet is a successive 32-byte value that may be partitioned into fields. For example as illustrated in Table I, a first row of a command packet may include the “Command Name”, such as “Decompress Into Sub-Rectangle” value or command. The second row may indicate a “Source Type, such as how the compressed data is stored, or in this example a “LZ77” compressed format. A “Destination Type” value in the second field of the second row indicates how the decompressed values will be stored in memory. A “Tiled” value indicates the values are stored in memory such that incrementing addresses represent incrementing values of x and y in some small repeating pattern (e.g. a 4×4 tile pattern: (0, 0) (1, 0) (2, 0) (3, 0) (0, 1) (1, 1) (2, 1) (3, 1) (0, 2) . . . (3, 3) (4, 0) (5, 0) (6, 0) . . . (7, 7) . . . ) . . . . Alternatively, a “Linear” value at a “Destination Type” field indicates the values are stored in memory such that incrementing addresses represent incrementing values of x for each entire row of the texture.

Returning to Table I, the third row may indicate a “Source Starting Address” or “0x180000” in the source memory for the compressed texture data. The fourth row may indicate a “Source Byte Count Value,” or “1640” that indicates how many bytes of compressed texture data is retrieved starting at the “Source Starting Address” or address 0x180000 in this example. The fifth row indicates a “Destination Starting Address” or “0x30000” address value which indicates where in memory the entire destination texture image starts, used to calculate where engine105starts storing or writing the decompressed texture data. The sixth row indicates a size of a “Destination Rectangle Width” and “Sub-Rectangle Width” fields, “1024” and “256” values respectfully in this example. The seventh row indicates “Sub-Rectangle X Offset” and “Sub-Rectangle Y Offset” fields as “0” and “256” values respectively, further used in combination with the Destination Starting Address and other values to determine the exact starting address of the destination sub-rectangle. The eighth row indicates a “Destination Texel Format” such as “block coded RGBA integer” value.

Table II illustrates a command packet for decompressing compressed texture data that is in 4:2:0 JPEG compressed format that results in separate luma and chroma rectangles (or planes). Similar to Table I, rows in a command packet provide control values for an engine105to provide decompressed texture data to a destination sub-rectangle address. In this embodiment, separate “Luma” and “Chroma” destination address values are used for the separate “Destination . . . Start Address(es)” of the separate planes.

In another embodiment, a command packet is generated to compress texture data from uncompressed data stored in a tile format. For example, a command would initiate the engine to map and compress a tiled uncompressed texture sub-rectangle image to a LZ77 encoded format (stored in linear fashion in an embodiment) at a particular destination address in memory.

Interface201includes registers to receive control information or control signals, data and timing information in embodiments. Interface201may include a phase lock loop (PLL) or delay lock loop (DLL) to time the reception and transfer of data and control information as well as engine105circuits. In an embodiment, interface201is configured to receive control and data from signal path106. In embodiments, interface201includes serial-to-parallel converter circuits as well as parallel-to-serial converter circuits.

Controller204receives command addresses, such as a first command address, from interface201as will as an initiate signal via signal path223. In an embodiment, a host processor outputs the command address and initiate signal to engine105. Controller204then requests command buffer203to fetch at least one command packet from memory via interface201. Command buffer203receives a command packet from interface201via signal path222. Controller204then reads the first command packet from command buffer204. Controller204then orchestrates a continuous sequence of reading compressed texture data from source memory, such as memory102, and writing decompressed texture data to destination memory, such as memory102(texture buffer109) until the source byte count value in the corresponding command packet is reached.

In particular, read data buffer202reads a portion of compressed texture data from source memory via interface201and signal path221. The compressed texture data stored in read data buffer202is then output to read formatter206via signal path224. In embodiments, read formatter206either de-tiles the read data (converts the data from a tile format) or passes the read data to the selected decoder/encoder (LZ decoder207, JPEG decoder208, LZ encoder209, JPEG encoder210) via signal path225. Controller204selects a predetermined decoder/encoder in response to a control signal output from controller204based on a received command packet.

In an embodiment, LZ decoder207receives compressed LZ77 texture data that has been passed through by read formatter206from signal path225and outputs decoded or decompressed texture data to write formatter211via signal path226.

Similarly, JPEG decoder208receives compressed JPEG texture data that has been passed through by read formatter206from signal path225and outputs decoded or decompressed texture data to write formatter211via signal path226.

In an embodiment, read formatter206de-tiles texture data stored in a tile format in memory and transfers the texture data to either LZ encoder209or JPEG encoder210to compress the de-tiled texture data into ether LZ77 compressed texture data or JPEG compressed texture data.

In particular, LZ encoder209receives texture data via signal path225and outputs encoded or LZ77 compressed texture data to write formatter211via signal path226. Similarly, JPEG encoder210receives texture data via signal path225and outputs encoded or compressed JPEG texture data to write formatter211via signal path226.

Write formatter211either passes the data to write data buffer205via signal path227or formats the data into a tile format in response to control signals from controller204. Compressed texture data is passed through write formatter211while decompressed texture data is formatted into a tile format for storage into memory in an embodiment.

Write data buffer205gathers the data received from write formatter211, such as decompressed texture data, and then writes a portion of the gathered or collected data in write data buffer205to a destination sub-rectangle address in memory via signal path228, interface201and signal path220. In an embodiment, the destination sub-rectangle address is located in texture buffer109of memory102as illustrated inFIG. 1. In an embodiment, interface201generates a control signal to GPU to notify that a decompressed texture has been stored in the texture buffer109and may be used for rendering in the next frame of video.

FIGS. 4 and 5A-B are flow charts illustrating exemplary methods of providing a stream of virtual textures from an engine. In embodiments, steps illustrated inFIGS. 4 and 5A-B represent the operation of hardware (e.g., processor, engine, memory, circuits), software (e.g., operating system, applications, drivers, machine/processor executable instructions), or a user, singly or in combination. As one of ordinary skill in the art would understand, embodiments may include less or more steps shown.

FIG. 4is a flow chart of decompressing compressed data representing textures and providing the decompressed data representing textures to a texture buffer accessible by a graphics processor for rendering.

Step400illustrates allocating memory space, such as texture buffer109in memory102, for an active texture pool to be used in rendering. In an embodiment, application107executed by at least one processor performs this function. In an embodiment, application107communicates with the appropriate driver to allocate the memory for the active texture pool depending upon the current scene and/or geometry to be rendered.

Step401illustrates determining the next sub-image area of a scene or CGI that will be rendered or updated. For example, a CGI may have just a portion or sub-image that needs to be updated with a texture as opposed to the entire CGI or scene. In an embodiment, application107executed by at least one processor performs this function.

Step402illustrates determining the level of detail of the texture that will be used in the sub-image. For example, an appropriate Mip level of the texture's Mipmap is determined. In an embodiment, application107executed by at least one processor performs this function.

Step403illustrates identifying where the compressed detail levels of texture (mipmaps) are located in source memory. For example, an address to compressed textures108is identified by the application in an embodiment.

Control information is then created as illustrated by step404. Control information, such as command packets including commands, are created by an application so that they may be transferred to an engine to provide a stream of decompressed textures to a texture buffer in an embodiment as illustrated in step406.

Step405illustrates allocating more memory for an active texture pool when further sub-images are updated. In an embodiment, application107executed by at least one processor performs the functions illustrated by steps404-407.

Step407illustrates updating a texture validity map that is accessible by a GPU, such as GPU104.

FIGS. 5A-Bare flow charts of operating a engine, such as engine105, for streaming decompressed virtual textures. Step500illustrates an engine, in particular a controller of the engine, receiving a start address to a command and a start or control signal, from for example a host processor, to initiate decompression of the compressed texture information.

Step501illustrates the controller directing a command buffer to fetch the at least one command at the start address.

Step502illustrates the controller reading the first command from the command buffer; while, step503illustrates the controller providing a continuous stream of decompressed texture data or information to a texture buffer. In an embodiment, step502also illustrates receiving a start address of a compressed texture information and a destination address of a sub-image that may be stored in a control packet. Step503also illustrates decompressing the compressed texture information to provide texture information as well as output the texture information to the destination address of the sub-image.

In an alternate method embodiment, a sub-image of uncompressed texture information that is stored in processor readable memory is compressed. In an embodiment, engine105performs the steps of this compression method. A control signal to initiate compression of the uncompressed texture information and a start address of the uncompressed texture information is received, similar to step500above. A sub-image of the uncompressed texture information is compressed to have a compressed sub-image texture. In an embodiment, LZ encoder209or JPEG encoder210in engine105perform this compression step. A destination address to store the compressed sub-image texture is received and the compressed sub-image texture is output to the destination address. In an embodiment, engine105also performs this receiving and outputting step.

In an embodiment,FIG. 5Billustrates the steps for providing the stream of decompressed textures illustrated by step503inFIG. 5A. In an embodiment, step503or steps510-515are repeated in a looped manner. Step510illustrates a data buffer reading a next portion of compressed data representing texture information at a source address. In an embodiment, read data buffer202performs this function.

Step511illustrates read data passed to a read formatter for de-tile or pass-through the read data.

Step512illustrates decoding or encoding the read data, which may be compressed or decompressed texture data. In an embodiment, decoders207/208and encoders209/210perform this function.

Step513illustrates passing the write data to a write formatter to format the write data in a tile format or pass-through the write data, such as decompressed texture data.

Step514illustrates gathering the read data in a write data buffer and step515illustrates storing the write data, such as decompressed texture data, at destination addresses in a texture buffer, or active texture pool, accessible by a GPU for rendering in an embodiment.

In an embodiment, at least one of the computing devices100may be, but is not limited to, a video game and/or media console.FIG. 6will now be used to describe an exemplary video game and media console, or more generally, will be used to describe an exemplary gaming and media system1000that includes a game and media console. The following discussion ofFIG. 6is intended to provide a brief, general description of a suitable computing device with which concepts presented herein may be implemented. It is understood that the system ofFIG. 6is by way of example only. In further examples, embodiments describe herein may be implemented using a variety of client computing devices, either via a browser application or a software application resident on and executed by the client computing device. As shown inFIG. 6, a gaming and media system1000includes a game and media console (hereinafter “console”)1002. In general, the console1002is one type of client computing device. The console1002is configured to accommodate at least one wireless controller, as represented by controllers10041and10042. The console1002is equipped with an internal hard disk drive and a portable media drive1006that support various forms of portable storage media, as represented by an optical storage disc1008. Examples of suitable portable storage media include DVD, CD-ROM, game discs, and so forth. The console1002also includes two memory unit card receptacles10251and10252, for receiving removable flash-type memory units1040. A command button1035on the console1002enables and disables wireless peripheral support.

As depicted inFIG. 6, the console1002also includes an optical port1030for communicating wirelessly with at least one device and two USB ports10101and10102to support a wired connection for additional controllers, or other peripherals. In some implementations, the number and arrangement of additional ports may be modified. A power button1012and an eject button1014are also positioned on the front face of the console1002. The power button1012is selected to apply power to the game console, and can also provide access to other features and controls, and the eject button1014alternately opens and closes the tray of a portable media drive1006to enable insertion and extraction of an optical storage disc1008.

The console1002connects to a television or other display (such as display1050) via A/V interfacing cables1020. In one implementation, the console1002is equipped with a dedicated A/V port configured for content-secured digital communication using A/V cables1020(e.g., A/V cables suitable for coupling to a High Definition Multimedia Interface “HDMI” port on a high definition display1050or other display device). A power cable1022provides power to the game console. The console1002may be further configured with broadband capabilities, as represented by a cable or modem connector1024to facilitate access to a network, such as the Internet. The broadband capabilities can also be provided wirelessly, through a broadband network such as a wireless fidelity (Wi-Fi) network.

Each controller1004is coupled to the console1002via a wired or wireless interface. In the illustrated implementation, the controllers1004are USB-compatible and are coupled to the console1002via a wireless or USB port1010. The console1002may be equipped with any of a wide variety of user interaction mechanisms. In an example illustrated inFIG. 6, each controller1004is equipped with two thumb sticks10321and10322, a D-pad1034, buttons1036, and two triggers1038. These controllers are merely representative, and other known gaming controllers may be substituted for, or added to, those shown inFIG. 6. In an embodiment, a user may enter input to console1002by way of gesture, touch or voice. In an embodiment, optical I/O interface1135receives and translates gestures of a user. In another embodiment, console1002includes a natural user interface (NUI) to receive and translate voice and gesture inputs from a user. In an alternate embodiment, front panel subassembly1142includes a touch surface and a microphone for receiving and translating a touch or voice, such as a voice command, of a user.

In one implementation, a memory unit (MU)1040may also be inserted into the controller1004to provide additional and portable storage. Portable MUs enable users to store game parameters for use when playing on other consoles. In this implementation, each controller is configured to accommodate two MUs1040, although more or less than two MUs may also be employed.

The gaming and media system1000is generally configured for playing games (such as video games) stored on a memory medium, as well as for downloading and playing games, and reproducing pre-recorded music and videos, from both electronic and hard media sources. With the different storage offerings, titles can be played from the hard disk drive, from an optical disk media (e.g., an optical storage disc1008), from an online source, or from MU1040. Samples of the types of media that gaming and media system1000is capable of playing include:

Game titles played from CD and DVD discs, from the hard disk drive, or from an online source.

Digital music played from a CD in portable media drive1006, from a file on the hard disk drive (e.g., music in a media format), or from online streaming sources.

Digital audio/video played from a DVD disc in portable media drive1006, from a file on the hard disk drive (e.g., Active Streaming Format), or from online streaming sources.

During operation, the console1002is configured to receive input from controllers1004and display information on the display1050. For example, the console1002can display a user interface on the display1050to allow a user to select a game using the controller1004and display state solvability information as discussed below.

FIG. 7is a functional block diagram of the gaming and media system1000and shows functional components of the gaming and media system1000in more detail. The console1002has a CPU1100, and a memory controller1102that facilitates processor access to various types of memory, including a flash ROM1104, a RAM1106, a hard disk drive1108, and the portable media drive1006. In one implementation, the CPU1100includes a level 1 cache1110and a level 2 cache1112, to temporarily store data and hence reduce the number of memory access cycles made to the hard drive1108, thereby improving processing speed and throughput. In an embodiment, CPU1100and memory controller1102correspond to CPU103and engine105while RAM1106corresponds to memory102in embodiments.

The CPU1100, the memory controller1102, and various memory devices are interconnected via at least one bus. The details of the bus that is used in this implementation are not particularly relevant to understanding the subject matter of interest being discussed herein. However, it will be understood that such a bus might include at least one of a serial bus, parallel bus, memory bus, peripheral bus, and processor or local bus, using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.

In one implementation, the CPU1100, the memory controller1102, the ROM1104, and the RAM1106are integrated onto a common module1114. In this implementation, the ROM1104is configured as a flash ROM that is connected to the memory controller1102via a PCI bus and a ROM bus (neither of which are shown). The RAM1106is configured as multiple Double Data Rate Synchronous Dynamic RAM (DDR SDRAM) modules that are independently controlled by the memory controller1102via separate buses. The hard disk drive1108and the portable media drive1006are shown connected to the memory controller1102via the PCI bus and an AT Attachment (ATA) bus1116. However, in other implementations, dedicated data bus structures of different types can also be applied in the alternative.

A three-dimensional graphics processing unit1120and a video encoder1122form a video processing pipeline for high speed and high resolution (e.g., High Definition) graphics processing. Data are carried from the graphics processing unit1120to the video encoder1122via a digital video bus. An audio processing unit1124and an audio codec (coder/decoder)1126form a corresponding audio processing pipeline for multi-channel audio processing of various digital audio formats. Audio data are carried between the audio processing unit1124and the audio codec1126via a communication link. The video and audio processing pipelines output data to an A/V (audio/video) port1128for transmission to a television or other display. In the illustrated implementation, the video and audio processing components1120-1128are mounted on the module1114.

In another embodiment, at least CPU1100, level 1 cache1110, level 2 cache1112, memory controller1102and RAM memory1106along with a engine105are included in a SoC, such as SoC101as described herein and shown inFIG. 1. In an embodiment, RAM memory1106is replaced with memory102and CPU103performs the function of memory controller1102. In an embodiment, application107(such as a video game or gaming application), compressed textures108and decompressed textures109a/bin texture buffer109are included in memory102that replaces RAM memory1106.

FIG. 7shows the module1114including a USB host controller1130and a network interface1132. The USB host controller1130is shown in communication with the CPU1100and the memory controller1102via a bus (e.g., PCI bus) and serves as host for the peripheral controllers10041-10044. The network interface1132provides access to a network (e.g., Internet, home network, etc.) and may be any of a wide variety of various wire or wireless interface components including an Ethernet card, a modem, a wireless access card, a Bluetooth module, a cable modem, and the like.

In the implementation depicted inFIG. 7, the console1002includes a controller support subassembly1140for supporting the four controllers10041-10044. The controller support subassembly1140includes any hardware and software components to support wired and wireless operation with an external control device, such as for example, a media and game controller. A front panel I/O subassembly1142supports the multiple functionalities of power button1012, the eject button1014, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of console1002. Subassemblies1140and1142are in communication with the module1114via at least one cable assembly1144. In other implementations, the console1002can include additional controller subassemblies. The illustrated implementation also shows an optical I/O interface1135that is configured to send and receive signals that can be communicated to the module1114.

The MUs10401and10402are illustrated as being connectable to MU ports “A”10301and “B”10302respectively. Additional MUs (e.g., MUs10403-10406) are illustrated as being connectable to the controllers10041and10043, i.e., two MUs for each controller. The controllers10042and10044can also be configured to receive MUs. Each MU1040offers additional storage on which games, game parameters, and other data may be stored. In some implementations, the other data can include any of a digital game component, an executable gaming application, an instruction set for expanding a gaming application, and a media file. When inserted into the console1002or a controller, the memory controller1102can access the MU1040.

A system power supply module1150provides power to the components of the gaming system1000. A fan1152cools the circuitry within the console1002.

An application1160comprising processor readable instructions is stored on the hard disk drive1108. When the console1002is powered on, various portions of the application1160are loaded into RAM1106, and/or caches1110and1112, for execution on the CPU1100, wherein the application1160is one such example. Various applications can be stored on the hard disk drive1108for execution on CPU1100. In an embodiment, application1160is replace with application107as described herein.

The console1002is also shown as including a communication subsystem1170configured to communicatively couple the console1002with at least one other computing device (e.g., other console). The communication subsystem1170may include wired and/or wireless communication devices compatible with at least one different communication protocol. As non-limiting examples, the communication subsystem1170may be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network. In some embodiments, the communication subsystem1170may allow the console1002to send and/or receive messages to and/or from other devices via a network such as the Internet. In specific embodiments, the communication subsystem1170can be used to communicate with a coordinator and/or other computing devices, for sending download requests, and for effecting downloading and uploading of digital content. More generally, the communication subsystem1170can enable the console1002to participate on peer-to-peer communications.

The gaming and media system1000may be operated as a standalone system by simply connecting the system to display1050(FIG. 6), a television, a video projector, or other display device. In this standalone mode, the gaming and media system1000enables at least one player to play games, or enjoy digital media, e.g., by watching movies, or listening to music. However, with the integration of broadband connectivity made available through network interface1132, or more generally the communication subsystem1170, the gaming and media system1000may further be operated as a participant in a larger network gaming community, such as a peer-to-peer network.

The above described console1002is just one example of the computing devices100discussed above with reference toFIG. 1and various other Figures. As was explained above, there are various other types of computing devices with which embodiments described herein can be used.

The foregoing detailed description of the inventive system has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the inventive system to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the inventive system and its practical application to thereby enable others skilled in the art to best utilize the inventive system in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the inventive system be defined by the claims appended hereto.