Jump to content
  • Advertisement
Sign in to follow this  
Alex_hbg

Texture Swizzling

This topic is 3646 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I was wondering if someone could explain texture swizzling to me. I think I kinda understand it but am still not completely sure. I found this post on the internet..
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.
..but am not really understanding it. Could someone please clarify?

Share this post


Link to post
Share on other sites
Advertisement
Sounds interesting, but I'm not aware of texture swizzling. Can you post the link where you found that?

Anyway, the point they are making is that typically texture data is stored as a linear array of rows. But data is rarely accessed in this fashion e.g. bilinear filtering requires access to neighbouring rows as well as neighbouring pixels in the same row. If the data is stored in the original form then the correct pixel in a neighbouring row is quite a long way away. This can cause cache misses.

Share this post


Link to post
Share on other sites
http://www.psp-programming.com/forums/index.php?topic=2506.msg21605

"cache misses"? And I can't seem to get my head around how it helps bilinear filtering?

I understand texture swizzling is used quite commonly in industry game development. Seeing as the texture is "swizzled" anyway once you store it in memory, so game developers decide to just swizzle the texture beforehand offline, saving time in runtime.

Share this post


Link to post
Share on other sites
The way pixels are laid out in texture memory affects how efficiently they can be accessed - especially taking caches into account.

This series of slides on Texturing and texture caching + fixed point math from a course on mobile computer graphics has a good explanation of it. The explanation of texture caching starts at page 28 with the memory layout described from page 33.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!