I wrote a tool for automatically finding out the texture layout for Gallium drivers. You can find it attached to <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=ff13bc9a1001081140y18450c3ejdfac25c9260fd367%40mail.gmail.com&forum_name=mesa3d-dev">http://sourceforge.net/mailarchive/forum.php?thread_name=ff13bc9a1001081140y18450c3ejdfac25c9260fd367%40mail.gmail.com&forum_name=mesa3d-dev</a>. Here are the findings from running it. The result is that our miptree layout code is partially broken, and overly complex. In particular: 1. 3D textures are broken because they are not laid out like cube maps, but first by level and then by face 2. Swizzled 3D texture are all 3 texture coordinates swizzled together 3. Cube maps have their faces 128 byte aligned, not only 64 like in my patch or unaligned like without it (not applied IIRC). 4. Swizzled 2D/3D/cube textures don't have any gaps, except for cube map face alignment. The current code contains a strange dimension check. I'm in the process of rewriting the miptree layout code and all the 2D engine code to account this (and to support all case, including unswizzling and 3D-swizzling). Here are the findings on NV40. Not sure what happens with compressed textures (which may be currently broken since Doom3 misrenders in non-Ultra quality). I'll check that once the 2D code is otherwise finished and working * Swizzled 1D/2D/3D textures Mipmaps are laid sequentially with no gap in between. Each mipmap is laid "swizzled". To get the swizzled address of a texel, take an x bit, then an y bit, then a z bit and so on. If you exceed a dimension, skip taking their bits. This means in particular that 3D textures are "3D swizzled": zyxzyxzyx... The blob loads swizzled 3D textures with the CPU. It seems that there is no GPU hardware that can write to swizzled 3D textures (except of course for mapping it as something else and computing in a fragment shader). * Swizzled cube maps Cube maps are sequences of 2D textures, each aligned to 128 bytes. The hardware seems to have sampling support for non-square cube maps (not supported by any API afaik) but lays them out as if their height were equal to the width. * Linear textures In linear textures all images have the same pitch, which can apparently be any value (even 4), aligned to bytes per pixel. 1D textures and 2D textures are laid out in the obvious way. 3D textures are laid with contiguous mipmaps, each containing a 2D texture for each zslice. Cube maps are laid with contiguous faces, each a 2D texture. No special face alignment is used (they will still be aligned to the pitch of course). # Alignment requirements Render target pitch must be a multiple of 64 and greater than 0. For swizzled targets, the blob sets a width * bpp pitch. However, the hardware seems to ignore pitch for swizzled targets. Furthermore, the hardware can actually render to any swizzled surface size! The offset must however be a multiple of 64, even for swizzled surfaces. # GdiSubRect does not seem to work with SWIZZLED_SURFACE set as surface # SWIZZLED_SURFACE wants a 64-byte aligned destination