Browse Prior Art Database

Level 2 Mapping Cache Allocation for Multiple Operand Types

IP.com Disclosure Number: IPCOM000009385D
Publication Date: 2002-Aug-20
Document File: 5 page(s) / 138K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method that uses level 2 caching to extend the scope of the work set of the level 1 mapping cache. It can also be used for blit engine read-only operands. Benefits include better hit ratio mapping and stream operand caching.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Level 2 Mapping Cache Allocation for Multiple Operand Types

Disclosed is a method that uses level 2 caching to extend the scope of the work set of the level 1 mapping cache. It can also be used for blit engine read-only operands. Benefits include better hit ratio mapping and stream operand caching.

Background

Currently, the mapping engine in a graphics hardware accelerator deals with operands that are mostly surfaces mapped and blended with rendered pixels, and therefore are primarily read-only types.

General Description

The disclosed method  improves upon the current state of the art in the following ways:

 

  • Supports operands in different ways for 3D and 2D rendering.  Level2 mapping cache is designed to be used for texture, motion-comp references, and stretch blit source while the 3D renderer is active. The same cache and controller are used to store the blit-engine's mono-chrome source and color pattern while the 2D renderer is active. Immediate blit-data and DIB data are also stored by configuring the cache RAM as FIFO. Since the 3D and 2D renderers are mutually exclusive in time, 8KB of cache is configured (see Figure 1). While the 3D renderer is active it is unified as a 4-way set-associative (Mode 0). This mode is optimized for bi-linear

mip-mapping. 

When the blit engine (2D renderer) is active, the 8KB cache is divided into 6KB + 2KB blocks. Both these blocks can be used as a cache or as FIFO, depending upon operands. Six KB of block if used for a DMA operand, and is configured as a 3-way set-associative cache; if it is used for an immediate operand, it is configured as FIFO. Similarly, the 2KB block is used as a fully associative cache for a DMA operand and as a FIFO for immediate pattern. This partition is optimized for the number of immediate operand surfaces that can be fitted for monochrome source and color pattern.

§         Allocation optimized for memory and engine interface. In Mode 0, cache is organized as 4-way set-associative, where each has 64 or 32 bytes. In Mode 1 and Mode 2, for DMA operands, a cache-line is always 32 bytes contiguous in the virtual address space. For immediate operands, they are contiguous within a block. For DMA operands, the cache-line (32 bytes) is allocated in the virtual address space. All read requests to the memory are a pair of Ows, either 128B, 256B or 1B apart in the physical memory. Cache RAM is designed to sustain OW per core clock write bandwidth. Further, all engine interfaces are 128-bit wide (i.e. 3D and 2D renderer requires 128-bit data to be delivered for every core clock). Therefore, the cache RAM's read port is designed to sustain OW per clock transfer to engines. This innovative allocation policy optimizes the interfaces at the same time (see Figure 2.)

For 3D DMA operands, all mapping engine requests are for 2 QWs that are surface pitch apart except for two cases:

1.      Compressed texture request from mapping engines requires 2 QW contiguous from the virtual surface

2.      Motion-comp reference...