Is using many texture maps bad for caching?

Question

If I have many textures (say 5+ maps) bound to the same texture unit, does it work worse for cache than if I had only 2 or 3 textures?

Answer 1

Just adding to imallett's answer, it is true that increasing the number of accesses to different texture data in a shader will increase pressure on the GPU cache(s), but there are several other factors that can significantly influence the effect. It's also possibly complicated by the fact that, like CPU caches, there may be several layers of cache in a GPU, ie. Texture Unit <= L0 <= L1 <= ..Memory

Avoid aliasing -> Use MIP maps

If you have a scene that has minification of texture data, be it due to perspective or simple scaling and you aren't using MIP mapping, then you will get aliasing. This is not just going to produce visual artefacts; it is very likely to be a performance problem.

As soon as you get aliasing, the address accesses to the texture will become incoherent which will not only end up thrashing the caches but introduce a lot of DRAM "page breaks" (more correctly, row breaks) which can be costly. MIP mapping helps reduce the incoherency.

Texture compression

Perhaps a bit of an obvious option, but if you can use texture compression (e.g. DXTn|ETC*|PVRTC*|etc) targeting from 8bpp down to, say, 2bpp, you can greatly increase the effectiveness of the memory bandwidth/cache by factors of 4x through to 16x. Now I can't speak for all GPUs, but some texture compression schemes (e.g. those listed above) are so simple to decode in hardware, that the data could stay compressed throughout the entire cache hierarchy and only be decompressed in the texture unit, thus effectively multiplying the size of those caches.

Data size

Obviously, some data, e.g. render targets used as texture data in subsequent renders, can't employ texture compression. Whenever you can, use the smallest pixel format that will do the job, i.e, if 32/16bpp (A)RGB will do, don't use 4x32 float formats!

Sparse access

This is somewhat related to the aliasing example above, but we've seen cases where large render targets are created, but then only very sparsely sampled. Cache lines, be it in CPUs or GPUs, are quite long so if you are only using one pixel in each cache line, you will be wasting transfers.

Also, WRT compressed textures, these achieve compression by effectively sharing data between a local region of texels. If you don't have coherent access then, apart from the memory footprint reduction, the compression probably won't help.

Dependent Texture Reads

Not so much of a cache issue (well, unless the computed accesses are quite incoherent), but texture accesses that aren't directly defined by the UV coordinates supplied with vertices might be slower than those that are directly defined.

Tiled/Morton VS Strided textures

Although I suspect most textures these days will be stored in either a tiled or Morton-like (aka Twiddled/Swizzled) order (or even a combination of both), some textures might still be in scan-line order, which means that rotation of the texture is likely to lead to a significant number of cache misses/page breaks. Unfortunately, I don't really know how to spot if a particular format is arranged in such a way.

(For background reading, try Blinn's The Truth About Texture Mapping. FWIW, taking that a few steps further led to the use of Twiddled-order (i.e. Morton order) textures in at least some early PC hardware).

Answer 2

The answer depends on what you mean. Modern hardware (e.g. with bindless textures) really doesn't care too much how many textures are "bound". The real question is how many you use.

Textures generally store data in a cache-friendly way (a Morton curve, I believe). If you use more textures, you'll get more cache misses, since now the textures compete with each other for space.

This really just comes down to the well-known, old shader programming heuristic: texture taps are slow; don't use too many.