<p>Whether it's a tile based GPU or not doesn't really affect the texture cache architecture. The memory layout of texture will look like some flavor of <a href="https://en.wikipedia.org/wiki/Z-order_curve">Morton order</a> or <a href="https://en.wikipedia.org/wiki/Hilbert_curve">Hilbert curve</a> in all GPUs.</p>

<p>As a result, it's more efficient to render triangles that are close to equilateral triangles because GPU memory system fetches cache lines of texels.</p>

<p>So obviously on tile borders, it may happen that you have to fetch texels twice. This has a small cost as tile borders are only "few" pixels.</p>

<p>Arguably desktop GPUs behave identically to tile based GPUs as experiments such as the following demonstrate:
<a href="http://www.g-truc.net/post-0597.html">http://www.g-truc.net/post-0597.html</a></p>

<p>The size of the tiles differ but both architecture actually process fragments into a hierarchy of tiles of different sizes.</p>

<p>When coding for tile based GPUs my recommendation is to always have in mind:</p>

<ol>
<li>Don't switch framebuffer objects unless you <em>really</em> need to.</li>
<li>When binding a new framebuffer object, if you don't need to save the content of the current framebuffer, discard it. If don't want to load content of the new framebuffer, then you should clear the framebuffer.</li>
</ol>

CC BY-SA 3.0
2015-09-01T23:15:18.120Z
I updated the second item as the edit wasn't what I meant. Otherwise, it looks great!
Christophe
CC BY-SA 3.0
2015-09-02T11:04:42.923Z
Hi Christophe, did you mean "equilateral" triangles rather than "isosceles"?

Rather than "Hilbert" I'd have said "Morton" order as the addressing is *much* easier in hardware.
Simon F
CC BY-SA 3.0
2015-09-02T12:57:25.303Z
@Christophe thanks! This is really helpfull. So, for the border pixels, doesn't texture cache matter? That's was kind of what I was wondering. So, If I have a triangle that intersects tiles (x, y) and (x+1, y) and GPU just rasterized tile (x, y). Assuming tile (x+1, y) will be next, even if a different Execution Units processes it,  won't I benefit from texture cache when sampling texels for this triangle?
Felipe Lira
CC BY-SA 3.0
2015-09-02T13:00:59.193Z
Also, I got curious about the Hilbert pattern. I always assumed this was true for block compressed textures. Is this true for all textures? 

PS: I also didn't follow the last paragraph.
Felipe Lira
CC BY-SA 3.0
2015-09-07T19:09:25.310Z
PVRTC encodes texture blocks in a [morton order](https://en.wikipedia.org/wiki/PVRTC#Data_structure)
ashleysmithgpu
CC BY-SA 3.0
2015-09-08T12:23:01.563Z
@yuumei No. Although early MBX PVRTC files *were* in morton(ish) order, for later systems (e.g. SGX and Rogue), the data is in raster(ish) order and the driver/GPU loads and rearranges them into whatever is the preferred order for that particular GPU.
Simon F
CC BY-SA 3.0
2015-08-31T22:03:38.707Z
2015-09-09T21:13:03.580Z
2015-09-09T21:13:03.580Z
Christophe
<p>How does cache work with tile based rendering? </p>

<p>Are there any tips on how to improve cache hit ratio for it? (for instance, if tiles are processed horizontally and I have vertical segments of triangles with the same texture, does it work worse for cache than if I had triangles layout out horizontally?)</p>

CC BY-SA 3.0
2015-08-28T04:04:39.290Z
What do you mean by vertical vs horizontal layout of triangles?
Mokosha
CC BY-SA 3.0
2015-09-02T13:06:14.887Z
@Mokosha sorry, this somehow got unnoticed to me. I just saw it now. This is more a theoretical than pratical question and I don't even know if this makes sense now. Anyway, what I meant was, say a triangle intersect tiles (x, y) and (x+1, y) and that the these two tiles get processed one after another. Would that be a better for texture cache than If I had a triangle intersecting (x, y) and (x, y+1)? (Because of the border pixels and the layout of triangles not being in the same direction the tiles processing is)
Felipe Lira
<texture><gpu><shader><optimisation>
How does Texture Cache work in Tile Based Rendering GPU
Felipe Lira
# How does Texture Cache work in Tile Based Rendering GPU

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

How does cache work with tile based rendering?

Are there any tips on how to improve cache hit ratio for it? (for instance, if tiles are processed horizontally and I have vertical segments of triangles with the same texture, does it work worse for cache than if I had triangles layout out horizontally?)

**Tags:** texture, gpu, shader, optimisation

> **Comments:**
> **username_1**: What do you mean by vertical vs horizontal layout of triangles?  
> **username_0**: @username_1 sorry, this somehow got unnoticed to me. I just saw it now. This is more a theoretical than pratical question and I don't even know if this makes sense now. Anyway, what I meant was, say a triangle intersect tiles (x, y) and (x+1, y) and that the these two tiles get processed one after another. Would that be a better for texture cache than If I had a triangle intersecting (x, y) and (x, y+1)? (Because of the border pixels and the layout of triangles not being in the same direction the tiles processing is)  

---

## 1 answers

### Answer by username_2 on 2015-08-31. Score: 19 | Accepted answer

Whether it's a tile based GPU or not doesn't really affect the texture cache architecture. The memory layout of texture will look like some flavor of [Morton order](https://en.wikipedia.org/wiki/Z-order_curve) or [Hilbert curve](https://en.wikipedia.org/wiki/Hilbert_curve) in all GPUs.

As a result, it's more efficient to render triangles that are close to equilateral triangles because GPU memory system fetches cache lines of texels.

So obviously on tile borders, it may happen that you have to fetch texels twice. This has a small cost as tile borders are only "few" pixels.

Arguably desktop GPUs behave identically to tile based GPUs as experiments such as the following demonstrate:
<http://www.g-truc.net/post-0597.html>

The size of the tiles differ but both architecture actually process fragments into a hierarchy of tiles of different sizes.

When coding for tile based GPUs my recommendation is to always have in mind:

1. Don't switch framebuffer objects unless you *really* need to.
2. When binding a new framebuffer object, if you don't need to save the content of the current framebuffer, discard it. If don't want to load content of the new framebuffer, then you should clear the framebuffer.

> **Comments:**
> **username_2**: I updated the second item as the edit wasn't what I meant. Otherwise, it looks great!  
> **username_3**: Hi username_2, did you mean "equilateral" triangles rather than "isosceles"?  Rather than "Hilbert" I'd have said "Morton" order as the addressing is *much* easier in hardware.  
> **username_0**: @username_2 thanks! This is really helpfull. So, for the border pixels, doesn't texture cache matter? That's was kind of what I was wondering. So, If I have a triangle that intersects tiles (x, y) and (x+1, y) and GPU just rasterized tile (x, y). Assuming tile (x+1, y) will be next, even if a different Execution Units processes it,  won't I benefit from texture cache when sampling texels for this triangle?  
> **username_0**: Also, I got curious about the Hilbert pattern. I always assumed this was true for block compressed textures. Is this true for all textures?   PS: I also didn't follow the last paragraph.  
> **username_4**: PVRTC encodes texture blocks in a [morton order](https://en.wikipedia.org/wiki/PVRTC#Data_structure)  
> **username_3**: @yuumei No. Although early MBX PVRTC files *were* in morton(ish) order, for later systems (e.g. SGX and Rogue), the data is in raster(ish) order and the driver/GPU loads and rearranges them into whatever is the preferred order for that particular GPU.  

---

