I'm browsing some "increase performance" document from Nvidia. It says "If textures are slowing the GPU down, use Mip-Mapping". I know what mip-mapping is but how exactly does the GPU draw textures? As far as I know it looks up the corresponding pixel from the texture based on what part of the triangle it is going to draw. Why does Mip-Mapping increase time? Smaller array of data is my guess.

small array of data fits better into cache, thats one part of it. the other part of it is memory access time because of the texel-distances.. if you imagine a triangle of 16 pixels, and it has a texture of 1024x1024 on it, then each pixel needs a sample 64 texels to the right of the last pixel.. ergo, that sample won't be in cache, it will be like a random nonprefetched memory access => slow.

but the mipmap will be possibly fully in the cache (you will be at the mipmap level 16x16, and each pixel gets the sample 1 to the right of the pixel before => perfect for memory reads, they are not random, but very local..

i'm not that good at explaining this, sorry.

"Smaller array of data is my guess." Basically sounds like I knew the answer. Yea it makes sense. So when I am about to draw a texture, it actually copies the whole texture into a memory cache and then looks up texels for drawing?

Quote:Original post by dpadam450
So when I am about to draw a texture, it actually copies the whole texture into a memory cache and then looks up texels for drawing?

No, not the whole texture. When it has to read from a texture, rather than just loading 1 texel for every pixel it loads several neighboring ones into a small cache on the chip itself. It can then (hopefully) use these cached texels for the next few pixels, because they will likely use a similar part of the texture. It is much faster to read the texture in large lumps rather than small ones, though why that is is a bit technical (in other words I don't fully understand it myself). Looking up the cache is very fast, as it's on the processor itself.

Now, if the object is a long way away with a high detail texture, most texels will be skipped. This means the neighboring texels in the cache will not be used, and it has to do that expensive texture access for every pixel. But if you use mipmapping, it will use a smaller version of the texture, so the cached texels will be used.

Quote:Original post by RAZORUNREAL

Quote:Original post by dpadam450
So when I am about to draw a texture, it actually copies the whole texture into a memory cache and then looks up texels for drawing?

No, not the whole texture. When it has to read from a texture, rather than just loading 1 texel for every pixel it loads several neighboring ones into a small cache on the chip itself. It can then (hopefully) use these cached texels for the next few pixels, because they will likely use a similar part of the texture. It is much faster to read the texture in large lumps rather than small ones, though why that is is a bit technical (in other words I don't fully understand it myself). Looking up the cache is very fast, as it's on the processor itself.

Now, if the object is a long way away with a high detail texture, most texels will be skipped. This means the neighboring texels in the cache will not be used, and it has to do that expensive texture access for every pixel. But if you use mipmapping, it will use a smaller version of the texture, so the cached texels will be used.

Any given memory operation will always have some latency, as the circuitry has to seek the position of the data that is read or written by that operation.

If you do many small reads at random places, the latencies begin to pile up so that the efficiency offered by the memory bandwidth is lost for no gain. In case of large block operations or operations to data blocks near each other, the seek latency is minimized and the system works at full speed. Mipmaps exploit this principle to great advantage.

The same principle applies to many levels of graphics programming - for example, it is advisable to render as much as possible with as few draw calls as possible, as the calls themselves will cause a considerable latency compared to render times of moderately sized datasets.