Texture Swizzling

Quote:

The swizzling juts puts 16*8 sequential bytes of the original texture into a 16x8 byte block in the destination. Hence, say the source where to look as follows, where each number dedicates four bytes: 0000 0000 0000 0000 1111 1111 1111 1111 2222 2222 2222 2222 3333 3333 3333 3333 4444 4444 4444 4444 5555 5555 5555 5555 6666 6666 6666 6666 7777 7777 7777 7777 Then the swizzled texture would look like this: 0000 2222 4444 6666 0000 2222 4444 6666 0000 2222 4444 6666 0000 2222 4444 6666 1111 3333 5555 7777 1111 3333 5555 7777 1111 3333 5555 7777 1111 3333 5555 7777 So why is this faster? Because normally for texturing, you need to read neighboring pixels instead of sequentially, since most of the time the texture is not drawn axis aligned, so you have to step in v direction and possibly even negative u. Plus for bilinear filtering you need to read the texels right and below the current one. With this texture order, it is more likely that those texels end up in the same cache line that was filled before. In the above example, each line would fit into a single cache line, hence you could hold the whole top-left (and the bottom-left) 4x4 block of the original texture in two cache lines with the swizzled data, where you need 4 (8-) with the unswizzled approach.