STRUCT TTM_BUFFER_OBJECT(9)

💅 struct ttm_buffer_object(9)

okay bestie, welcome to the Kernel API Manual ✨ — this one's about struct ttm_buffer_object, which is genuinely one of those lowkey iconic kernel structs. no cap. 🫶

✨ NAME ✨

struct ttm_buffer_object — literally the base class for TTM buffer objects 🎀

🌸 SYNOPSIS 🌸

struct ttm_buffer_object {
    struct drm_gem_object base;
    struct ttm_device *bdev;
    enum ttm_bo_type type;
    uint32_t page_alignment;
    void (*destroy) (struct ttm_buffer_object *);
    struct kref kref;
    struct ttm_resource *resource;
    struct ttm_tt *ttm;
    bool deleted;
    struct ttm_lru_bulk_move *bulk_move;
    unsigned priority;
    unsigned pin_count;
    struct work_struct delayed_delete;
    struct sg_table *sg;
 };

👑 Members 👑

• base — the drm_gem_object superclass data. like, the main character it inherits from 💖
• bdev — pointer to the buffer object device structure.
• type — the bo type, iykyk.
• page_alignment — page alignment. that's it, that's the whole vibe ✨
• destroy — the destruction function. if it's NULL, kfree gets used instead. (so, no destroy function? kfree steps in. slay.)
• kref — reference count of this buffer object. the moment this refcount hits zero, the object gets destroyed or yeeted onto the delayed delete list 🫠
• resource — structure describing the current placement.
• ttm — the TTM structure holding system pages.
• deleted — True if the object is only a zombie and is already deleted 🧟‍♀️💀
• bulk_move — the bulk move object.
• priority — priority for LRU. BOs with lower priority get evicted first 🥇
• pin_count — pin count.
• delayed_delete — the work item used when we can't delete the BO immediately. it's giving "i'll deal with this later" 🙈
• sg — external source of pages and DMA addresses, and it's protected by the reservation lock 🔒

---

🦋 Description 🦋

so this is the base class for TTM buffer objects — it's the one that deals with data placement and CPU mappings 💫

GPU mappings are really up to the driver, but for simpler GPUs the driver can usually just use the placement offset offset directly as the GPU virtual address. (yes, "offset offset" — that's exactly how it's written, no touchy 🔥)

for drivers implementing multiple GPU memory manager contexts, the driver should manage the address space in these contexts separately, and use these objects to get the correct placement and caching for these GPU maps. the way this makes it possible to use these objects for even quite elaborate memory management schemes is honestly so iconic 👑

and the destroy member plus the API visibility of this object? that's what makes it possible to derive driver specific types. periodt. 💅

---

🌈 SEE ALSO 🌈

kernel file ./include/drm/ttm/ttm_bo.h — and also these besties:

• enum ttm_bo_type(9)
• struct ttm_bo_kmap_obj(9)
• struct ttm_operation_ctx(9)
• struct ttm_lru_walk_arg(9)
• struct ttm_lru_walk(9)
• struct ttm_bo_shrink_flags(9)
• ttm_bo_reserve(9)
• ttm_bo_reserve_slowpath(9)
• ttm_bo_move_null(9)
• ttm_bo_unreserve(9)
• ttm_kmap_obj_virtual(9)
• struct ttm_bo_lru_cursor(9)
• ttm_bo_lru_for_each_reserved_guarded(9)

---

💖 sign-off time: this page came from ./include/drm/ttm, dated October 2026, and the header still calls it struct ttm_buffer_object(9). go read the source bestie, ily 🫶✨