Tile-Based GPUs: Choose Attachment Load and Store Operations Deliberately

Treat an attachment as data with a lifetime

A tile-based GPU processes small framebuffer regions using local storage. Restoring old attachment contents or exporting intermediate results can create external memory traffic. Attachment load and store choices tell the implementation which contents matter at the boundaries of rendering. Arm's developer explanation shows why these choices can materially affect bandwidth on mobile GPUs. [1]

For each color, depth and stencil attachment, identify who produces its initial contents and who needs the final result. A depth buffer used only during one rendering interval has different requirements from depth sampled by later effects.

Choose the initial state from actual reads

Use LOAD when previous contents must be preserved. Use CLEAR when a defined uniform initial value is required. Use DONT_CARE only when the previous contents are unnecessary and every value later read is initialized appropriately. Vulkan defines the discarded initial contents as undefined within the render area. [2]

A fullscreen-looking draw is not sufficient evidence that everything was overwritten: depth rejection, scissors, write masks or blending can retain dependencies on earlier contents. On suitable tile hardware, clearing through the attachment operation can initialize local tile storage without restoring the previous image. [1]

Worked example: estimate transfer scale

An illustrative 1920 by 1080 attachment with 4 bytes per pixel contains 1920 * 1080 * 4 = 8294400 bytes. One complete load plus one complete store transfers 16588800 bytes in an uncompressed accounting model.

At 60 frames per second, that is 16588800 * 60 = 995328000 bytes per second, approximately 0.995 GB/s. This is neither measured bandwidth nor a promised saving: compression, caches, partial render areas and implementation choices change actual traffic. The calculation shows why an otherwise unnecessary attachment round trip deserves investigation.

Preserve final contents only where required

Store results needed by presentation, later rendering or readback. If an attachment's contents are no longer needed, a discard store operation can avoid preserving them. Vulkan's DONT_CARE store makes those contents undefined. Its NONE operation has distinct semantics and must not be treated as a way to preserve newly written data for a later pass. [3]

For suitable temporary attachments, investigate transient usage and supported lazy allocation. Keep compatible work together when this permits local reuse, but verify actual execution rather than assuming every logical pass merges. Neighboring-pixel reads can require a different memory path. [1]

Verify correctness before interpreting counters

Test partial coverage, overlays, depth consumers and alternate output sizes after changing attachment operations. Inspect the final image and any intermediate data that later passes consume. Then compare external reads and writes alongside GPU time on the target device. Lower traffic is valuable evidence, but geometry, shading or synchronization may still dominate the frame. Keep the lifetime decisions documented so a newly added consumer cannot silently rely on discarded contents.

Sources

• [1] Picking the Most Efficient Load/Store Operations — Attilio Provenzano, Arm.
• [2] VkAttachmentLoadOp — Khronos Group, Vulkan specification.
• [3] VkAttachmentStoreOp — Khronos Group, Vulkan specification.