STRUCT DRM_VC4_SUBMIT_CL(9)

💖 NAME 💖

struct drm_vc4_submit_cl — bestie, this is the ioctl argument for submitting commands to the 3D engine. That's the whole glow-up. ✨

And yes, this page lives in the Kernel API Manual — very demure, very kernel. 🎀

---

✨ SYNOPSIS ✨

Okay so here's the struct in all its glory, presented unfiltered, no edits, exactly as it is — keep every field, no cap:

struct drm_vc4_submit_cl {
    __u64 bin_cl;
    __u64 shader_rec;
    __u64 uniforms;
    __u64 bo_handles;
    __u32 bin_cl_size;
    __u32 shader_rec_size;
    __u32 shader_rec_count;
    __u32 uniforms_size;
    __u32 bo_handle_count;
    __u16 width;
    __u16 height;
    __u8 min_x_tile;
    __u8 min_y_tile;
    __u8 max_x_tile;
    __u8 max_y_tile;
    struct drm_vc4_submit_rcl_surface color_read;
    struct drm_vc4_submit_rcl_surface color_write;
    struct drm_vc4_submit_rcl_surface zs_read;
    struct drm_vc4_submit_rcl_surface zs_write;
    struct drm_vc4_submit_rcl_surface msaa_color_write;
    struct drm_vc4_submit_rcl_surface msaa_zs_write;
    __u32 clear_color[2];
    __u32 clear_z;
    __u8 clear_s;
    __u32 pad:24;
  #define VC4_SUBMIT_CL_USE_CLEAR_COLOR                   (1 << 0);
  #define VC4_SUBMIT_CL_FIXED_RCL_ORDER                   (1 << 1);
  #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X            (1 << 2);
  #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y            (1 << 3);
    __u32 flags;
    __u64 seqno;
    __u32 perfmonid;
    __u32 in_sync;
    __u32 out_sync;
    __u32 pad2;
 };

Look at all those fields. bin_cl, shader_rec, uniforms, bo_handles, all the sizes and counts, the tile bounds (min_x_tile, min_y_tile, max_x_tile, max_y_tile), the whole lineup of drm_vc4_submit_rcl_surface members, the clear values, the four VC4_SUBMIT_CL_* flag macros, and the sync fields at the end. Iconic. 🫶

---

🌸 MEMBERS 🌸

This heading is here, and then it just… rolls straight into the description below. The page does not spell out per-member blurbs here, so neither am I — we're matching the energy, not inventing lore. 🙈

---

🦋 DESCRIPTION 🦋

okay so. Here's the situation, and it's giving big brain:

Drivers typically use GPU BOs to store batchbuffers / command lists and their associated state. Normal. Expected. Fine.

But — plot twist 😭 — because the VC4 lacks an MMU, we have to do validation of memory accesses by the GPU commands. It's not optional, it's the whole assignment.

And if we were to store our commands in BOs, we'd need to do uncached readback from them to do the validation process — which is too expensive. Not "meh" expensive. Too expensive. 💀

So instead, the workflow is:

1. userspace accumulates commands and associated state in plain memory 🌱
2. then the kernel copies the data to its own address space 📦
3. and then validates it and stores it in a GPU BO 👑

Three steps, no wasted readback, no drama. Periodt. 👑

ngl this design exists because there's no MMU on the VC4 — that's the reason, that's the vibe, that's the constraint. Don't forget it. 🧚

---

🎀 SEE ALSO 🎀

Kernel file ./include/uapi/drm/vc4_drm.h, plus these absolute main characters of the API:

• struct drm_vc4_wait_seqno(9)
• struct drm_vc4_wait_bo(9)
• struct drm_vc4_create_bo(9)
• struct drm_vc4_mmap_bo(9)
• struct drm_vc4_create_shader_bo(9)
• struct drm_vc4_label_bo(9)

Go read them, they're all linked in the group chat. 💬

---

mwah 💋 that's the page, bestie — brought to you from ./include/uapi/drm, dated October 2026, and stamped struct drm_vc4_submit_cl(9) at the top and bottom like a little bow on a gift. 🎀✨