FENCE REGISTER HANDLING(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

fence register handling(9) πŸ’…

okay bestie, this is from the Kernel API Manual, section 9, and we need to clear up a name thing first: in the i915 driver, "fences" are not execution fences used to track command completion. Nope. They're literally hardware detiler objects that wrap a given range of the global GTT. And every platform only has a fairly limited set of these objects, so they're a whole scarce vibe. πŸŽ€

Fences are used to detile GTT memory mappings. They're also connected to hardware frontbuffer render tracking, which means they interact with frontbuffer compression. On older platforms, fences are required for tiled objects used by the display engine. The render engine can use them too: they're required for blitter commands and are optional for render commands. But on gen4+ both display (with the exception of fbc) and rendering have their own tiling state bits and don't need fences. πŸ’…

Also note: fences only support X and Y tiling, so they can't be used for the fancier new tiling formats like W, Ys and Yf. No cap. πŸ¦‹

Finally note that because fences are such a restricted resource, they're dynamically associated with objects. Also, fence state is committed to the hardware lazily to avoid unnecessary stalls on gen2/3. So code must explicitly call i915_gem_object_get_fence to synchronize fencing status for cpu access. And some code wants an unfenced view β€” for those cases the fence can be removed forcefully with i915_gem_object_put_fence. πŸ”₯

Internally these functions will synchronize with userspace access by removing CPU ptes into GTT mmaps (not the GTT ptes themselves) as needed. 🫢

SEE ALSO 🌈

kiss kiss, this page came from ./drivers/gpu/drm/i915/gt and is dated October 2026; the whole thing is fence register handling(9) πŸ’–

πŸ“¦ where this page comes from