<p>Just adding to <a href="https://computergraphics.stackexchange.com/questions/357/is-using-many-texture-maps-bad-for-caching/404#404">imallett's answer</a>, 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 &lt;= L0 &lt;= L1 &lt;= ..Memory</p>

<h2><strong>Avoid aliasing -> Use MIP maps</strong></h2>

<p>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.</p>

<p>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.</p>

<h2><strong>Texture compression</strong></h2>

<p>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 <em>some</em> texture compression schemes (e.g. those listed above) are so simple to decode in hardware, that the data <em>could</em> stay compressed throughout the entire cache hierarchy and only be decompressed in the texture unit, thus effectively multiplying the size of those caches. </p>

<h2><strong>Data size</strong></h2>

<p>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!</p>

<h2><strong>Sparse access</strong></h2>

<p>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.</p>

<p>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.</p>

<h2><strong>Dependent Texture Reads</strong></h2>

<p>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 <em>might</em> be slower than those that are directly defined.</p>

<h2><strong>Tiled/Morton VS Strided textures</strong></h2>

<p>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 <em>might</em> 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.</p>

<p>(For background reading, try Blinn's <a href="http://ieeexplore.ieee.org/document/50676/" rel="nofollow noreferrer">The Truth About Texture Mapping</a>. FWIW, taking that a few steps further led to the use of Twiddled-order (i.e. Morton order) textures in <a href="http://worldwide.espacenet.com/publicationDetails/originalDocument?FT=D&amp;date=19960814&amp;DB=EPODOC&amp;locale=en_ep&amp;CC=GB&amp;NR=2297886A&amp;KC=A&amp;ND=4" rel="nofollow noreferrer">at least some early PC hardware</a>). </p>

CC BY-SA 3.0
2015-09-03T09:20:31.290Z
2017-10-02T11:05:33.717Z
2017-10-02T11:05:33.717Z
Simon F
<p>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 <em>how many you use</em>.</p>

<p>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.</p>

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

CC BY-SA 3.0
2015-09-02T01:59:37.613Z
2015-09-02T01:59:37.613Z
geometrian
<p>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?</p>

<texture><shader><optimisation>
Is using many texture maps bad for caching?
Felipe Lira
# Is using many texture maps bad for caching?

(Asked by: username_0 on 2015-08-26)

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?

**Tags:** texture, shader, optimisation


---

## 2 answers

### Answer by username_1 on 2015-09-03. Score: 16 | Accepted answer

Just adding to [imallett's answer](https://computergraphics.stackexchange.com/questions/357/is-using-many-texture-maps-bad-for-caching/404#404), 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](http://ieeexplore.ieee.org/document/50676/). 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](http://worldwide.espacenet.com/publicationDetails/originalDocument?FT=D&date=19960814&DB=EPODOC&locale=en_ep&CC=GB&NR=2297886A&KC=A&ND=4)).


---

### Answer by username_2 on 2015-09-02. Score: 8

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.


---

