4.1.2–4.1.3The L1 Texture Cache & Unified Texture/Data Cache

Book pp. 72–75 · ~2 min read

  • texture mapping / texel
  • texture cache

4.1.2 The L1 Texture Cache

Texture caching earns its place in a GPGPU book for one reason: it is the purest expression of throughput-processor cache design — and recent NVIDIA/AMD parts literally reuse it for compute. First, thirty seconds of graphics: texture mappingtexture mapping / texelApplying an image (texture) to a 3D surface; a texel is one texture sample — neighboring pixels read neighboring texels, giving caches their locality.Glossary → pastes an image onto 3D geometry (wood grain onto a table); the rendering pipeline computes which texels (texture samples) each screen pixel needs — four or eight of them for bilinear/trilinear filtering — and averages them. Adjacent pixels read adjacent texels, so there’s real locality for a cache to catch… but the textures themselves are far too big to fit on-chip, so misses are constant companions.

A CPU cache treats a miss as an exception. The texture cachetexture cacheThroughput-first L1: the tag array runs a memory-round-trip AHEAD of the data array, a fragment FIFO delays hits, a reorder buffer keeps fills in order — hits and misses see similar latency.Glossary → (Igehy et al.’s design, matching industry patents) treats it as the common case and restructures everything around it — watch how a hit and a miss take almost the same journey:

Texture cache: tag array runs ahead (Fig 4.2)cycle 0 / 8
Load/Store Unit ①Tag Array ②Miss Request FIFO ⑧Fragment FIFO ③Memory ⑨Reorder Buffer ⑩Controller ④Data Array ⑤Texture Filter ⑥Register File ⑦texel (hit)

step 0The LSU computes texel addresses — for bilinear/trilinear (mipmap) filtering, each screen pixel needs FOUR or EIGHT texel lookups, later averaged by the filter unit.

One tick = one step through the texture cache (Fig 4.2). A hit and a miss play back to back — notice they take nearly the same journey time.

The three load-bearing ideas:

  1. The tag array runs ahead of the data array. Tags update at lookup time; the data array catches up one memory-round-trip later. Both stay small — no giant miss-handling structures.
  2. The fragment FIFO absorbs the latency. Hit or miss, every access parks in a FIFO sized to the round trip. Hits don’t jump the queue — hits and misses see roughly equal latency, which sounds terrible until you remember the metric is throughput, and warps are covering the latency anyway.
  3. The reorder buffer keeps memory honest. The DRAM scheduler will happily service requests out of order for row locality (§4.3.3); the reorder buffer restores arrival order so the data array remains an exact time-delayed image of the tags.

4.1.3 Unified Texture and Data Cache

Maxwell- and Pascal-era NVIDIA GPUs (and AMD’s GCN) merge the L1 data cache into this structure. The trick that makes it nearly free: only data guaranteed read-only is cached — which, per the coherence discussion, is what the L1 was drifting toward anyway. With writes off the table, the texture hardware needs little more than new addressing logic (the design appears in a 2017 NVIDIA patent). GCN goes all-in: every vector memory operation flows through the texture cache.

The broader lesson the book draws: CPU intuitions (hits fast, misses rare, order preserved by stalling) simply don’t survive contact with a machine whose job is to keep ten thousand threads streaming.

Check yourself

  1. 1. What does it mean that the texture cache's tag array 'runs ahead' of its data array?

  2. 2. Why do texture cache HITS wait in the fragment FIFO instead of returning immediately?

  3. 3. Predict the failure (use the animation): remove the reorder buffer and let DRAM return fills out of order. What breaks?

  4. 4. How do Maxwell/Pascal (and GCN) unify the texture cache with the L1 data cache?

0 / 4 correct · 4 unanswered