GX Default TMEM configuration

Description

The GXInit function defines the default memory map for the TMEM (embedded texture memory) and allocates areas for the texture cache and texture look up table (TLUT). After that, unless the user changes the mapping method, the region for cache used for texture mapping called by the GXLoadTexObj function will be decided according to this default memory map.

This default memory map uses the first half of the 1MB TMEM (the address of which corresponds to 0x00000-0x7FFFF, known as the Low Memory Bank) as sixteen 32KB cache areas. The region that corresponds to the second half of the addresses, 0x80000-0xFFFFF, is divided into two parts: 0x80000-0xBFFFF is used as eight 32-KB cache areas, whereas 0xC0000-0xFFFFF is used as the TLUT area for CI textures.

When a texture is used, one of these cache areas will be allocated. There are three factors that decide how to allocate the areas.

• Texture map ID (GX_TEXMAP0, GX_TEXMAP1, ...)
• Texture Format
• Mipmapped or non-mipmapped

There are three types of texture formats: CI textures, RGBA8 (32-bit) textures, and others (normal). The following indicates how the area would be used in each case:

Normal, Mipmap OFF:

For normal textures (non-CI, non-RGBA8), only one area that corresponds to each map ID in the Low Memory Bank will be used for each texture.

Normal, Mipmap ON:

For a normal mipmapped texture, two cache areas for the even and odd LODs need to be allocated. Each needs to be located in Low and High Memory Banks separately, so they will be allocated like the following:

CI, Mipmap OFF:

Color index textures will be treated in the same way as the normal non-mipmapped textures. TLUT information located in High Memory Bank will also be used.

CI, Mipmap ON:

For color index mipmapped textures, since the High Memory Bank will be used as the look up for TLUT, caches for both even and odd LODs need to be allocated in the Low Memory Bank. Hence, they will be allocated like the following:

RGBA8, Mipmap OFF:

RGBA8(32bit) textures are a special case; even the non-mipmapped textures need cache areas in both the Low and High Memory Banks. So the memory allocation is similar to the mipmapped normal texture case.

RGBA8, Mipmap ON:

RGBA8 (32-bit) format mipmapped textures are even more special. Two consecutive cache areas are necessary in both the Low and High Memory Banks. As a result, it is not possible to allocate independent areas for all texture IDs in the High Memory Bank, therefore the same cache area is shared by GX_TEXMAP0 and GX_TEXMAP4. The user must be careful to avoid cache collision.

Cache Conflicts and Avoidance

As noted above, cache conflicts can occur with RGBA8 (32-bit) mipmapped textures. There is also a possibility that RGBA8 texture affects caches for other types of texture. Here's an example:

If multi-texturing is performed under this environment, cache conflicts may occur in the shared area for GX_TEXMAP0 and GX_TEXMAP4 and also in the shared area for GX_TEXMAP1 and GX_TEXMAP5. (Corresponding to the red areas in the figure below.)

Even though a cache collision occurs, corrupt graphics will not occur. However, performance may be affected. So it is best to avoid the collision if possible. In this example, by switching the use of GX_TEXMAP1 and GX_TEXMAP2, and also switching GX_TEXMAP3 and GX_TEXMAP4, no sections will need to be reused and the possibility of cache collision is avoided. This is shown in the table below.

The use of a multi-texture environment with four or fewer textures (only GX_TEXMAP0 through GX_TEXMAP3) eliminates conflict concerns. Concerns therefore arise when five or more textures are used and there is an RGBA8 mipmapped texture.

TLUT

The addresses 0xC0000-0xFFFFF in the High Memory Bank are allocated as TLUT for color index textures: sixteen 256-entry tables (using eight kilobytes each), and four 1024-entry tables (using 32 KB each), as shown in the following table.

See Also

GXInit, GXLoadTexObj, GXInitTexCacheRegion, GXInitTlutRegion, GXSetTexRegionCallBack, GXSetTlutRegionCallBack

Revision History

2006/03/01 Initial version.

CONFIDENTIAL