GLOBAL GTT VIEWS(9)

🌸 Global GTT views 🌸

bestie, welcome to the kernel API manual 💖 this one's about global GTT views, and honestly it's a whole glow-up story, so let's get into it ✨

---

🎀 Background and previous state 🎀

okay so historically, objects could exist (like, be bound) in global GTT space only as singular instances — with a view that represents all of the object's backing pages in a linear fashion. we call that view a normal view. periodt.

to support multiple views of the same object — where the number of mapped pages isn't equal to the backing store, or where the layout of the pages is not linear — the concept of a GGTT view was added. iconic behaviour tbh 👑

one example of an alternative view is a stereo display driven by a single image. in this case we'd have a framebuffer looking like this (2x2 pages):

12 34

above would represent a normal GGTT view, as normally mapped for GPU or CPU rendering. in contrast, fed to the display engine would be an alternative view, which could look something like this:

1212 3434

in this example both the size and layout of pages in the alternative view is different from the normal view. not me being obsessed with this 👀

---

💅 Implementation and usage 💅

GGTT views are implemented using VMAs and are distinguished via enum i915_gtt_view_type and struct i915_gtt_view. slay.

a new flavour of core GEM functions which work with GGTT bound objects were added with the _ggtt_ infix, and sometimes with _view postfix — literally just to avoid renaming in large amounts of code. they take the struct i915_gtt_view parameter, encapsulating all metadata required to implement a view. 🫶

as a helper for callers which are only interested in the normal view, a globally const i915_gtt_view_normal singleton instance exists. all old core GEM API functions — the ones not taking the view parameter — are operating on, or with, the normal GGTT view.

code wanting to add or use a new GGTT view needs to:

1. add a new enum with a suitable name.
2. extend the metadata in the i915_gtt_view structure if required.
3. add support to i915_get_vma_pages.

new views are required to build a scatter-gather table from within the i915_get_vma_pages function. this table is stored in the vma.gtt_view and exists for the lifetime of an VMA. 💀 (yes, life-long commitment, no ghosting)

core API is designed to have copy semantics, which means that the passed-in struct i915_gtt_view does not need to be persistent (left around after calling the core API functions). so you can just let it go, bestie, no need to keep it on read 🙈

---

🌈 SEE ALSO 🌈

• Kernel file ./drivers/gpu/drm/i915/i915_vma_types.h Virtual Memory Address(9)

---

🦋 cute little sign-off: this page lives at ./drivers/gpu/drm/i915, dated October 2026, and it's page Global GTT views(9) of the Kernel API Manual. mwah 💋 💜