ENUM I915_CACHE_LEVEL(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay bestie, buckle up β€” this is the kernel API manual page for enum i915_cache_level(9), and it’s literally all about the supported GTT caching values for system memory pages. Every enum member is important here, so let’s get into it πŸ’…βœ¨

πŸ’– NAME πŸ’–

enum i915_cache_level β€” the supported GTT caching values for system memory pages.

🌈 SYNOPSIS 🌈

Here’s the enum lineup, exactly as it appears:

enum i915_cache_level {
    I915_CACHE_NONE ,
    I915_CACHE_LLC ,
    I915_CACHE_L3_LLC ,
    I915_CACHE_WT ,
    I915_MAX_CACHE_LEVEL

};

πŸŽ€ Constants πŸŽ€

πŸ’… I915_CACHE_NONE

GPU access is not coherent with the CPU cache. If the cache is dirty and we need the underlying pages to be coherent with some later GPU access, then we need to manually flush the pages. Yes, actual flushing β€” not just hoping the vibes fix it 😭

On shared LLC platforms, reads and writes through the CPU cache are still coherent even with this setting. See also drm_i915_gem_object.cache_coherent for more details. Because of this, we should only ever use uncached for scanout surfaces β€” otherwise we end up over-flushing in some places.

This is the default on non-LLC platforms. Periodt.

πŸ¦‹ I915_CACHE_LLC

GPU access is coherent with the CPU cache. If the cache is dirty, then the GPU will ensure that access remains coherent, when both reading and writing through the CPU cache. GPU writes can dirty the CPU cache.

Not used for scanout surfaces.

Applies to both platforms with shared LLC(HAS_LLC), and snooping based platforms(HAS_SNOOP).

This is the default on shared LLC platforms. The only exception is scanout objects, where the display engine is not coherent with the CPU cache. For such objects I915_CACHE_NONE or I915_CACHE_WT is automatically applied by the kernel in pin_for_display, if userspace has not done so already.

🌸 I915_CACHE_L3_LLC

Explicitly enable the Gfx L3 cache, with coherent LLC.

The Gfx L3 sits between the domain specific caches, e.g sampler/render caches, and the larger LLC. LLC is coherent with the GPU, but L3 is only visible to the GPU, so likely needs to be flushed when the workload completes.

Not used for scanout surfaces.

Only exposed on some gen7 + GGTT. More recent hardware has dropped this explicit setting, where it should now be enabled by default.

πŸŽ€ I915_CACHE_WT

Write-through. Used for scanout surfaces.

The GPU can utilise the caches, while still having the display engine be coherent with GPU writes, as a result we don’t need to flush the CPU caches when moving out of the render domain. This is the default setting chosen by the kernel, if supported by the HW, otherwise we fallback to I915_CACHE_NONE. On the CPU side writes through the CPU cache still need to be flushed, to remain coherent with the display engine.

πŸ‘‘ I915_MAX_CACHE_LEVEL

Mark the last entry in the enum. Used for defining cachelevel_to_pat array for cache_level to pat translation table.

πŸ¦‹ Description πŸ¦‹

These translate to some special GTT PTE bits when binding pages into some address space. It also determines whether an object, or rather its pages are coherent with the GPU, when also reading or writing through the CPU cache with those pages.

Userspace can also control this through struct drm_i915_gem_caching.

πŸ“ SEE ALSO πŸ“

  • Kernel file ./drivers/gpu/drm/i915/gem/i915_gem_object_types.h
  • ./drivers/gpu/drm/i915/gem

mwah πŸ’‹ β€” this cutie lives at source/version ./drivers/gpu/drm/i915/gem, dated October 2026, and it’s the enum i915_cache_level(9) page. iykyk 🫢✨

πŸ“¦ where this page comes from