STRUCT DRM_ASAHI_CMD_HEADER(9)
๐ struct drm_asahi_cmd_header(9) โ Kernel API Manual ๐
okay so bestie, this is the <cyan>kernel API manual</cyan> page for struct drm_asahi_cmd_header, and honestly? it's kind of the main character of the whole command buffer situation. let's get into it โจ
๐ธ NAME ๐ธ
struct drm_asahi_cmd_header โ the top level command structure, fr fr. it's the header that sits on top of your commands like a little crown ๐
โจ SYNOPSIS โจ
struct drm_asahi_cmd_header {
__u16 cmd_type;
__u16 size;
__u16 vdm_barrier;
__u16 cdm_barrier;
};
that's it. four fields. tiny. iconic. ๐ซถ
๐ Members ๐
๐ cmd_type
one of drm_asahi_cmd_type โ like, pick your fighter, bestie ๐
๐ฆ size
the size of this command, not including this header. so don't count the header itself, that's a whole separate vibe.
for hardware commands, this is what lets commands be extensible without needing a million extra command types. and here's the slay part: passing a command that's shorter than expected is explicitly allowed for backwards-compatibility. truncated fields just get zeroed. no drama, no cap ๐
for the synthetic attachment setting commands, this implicitly encodes the number of attachments. those commands take multiple fixed-size drm_asahi_attachment structures as their payload, so:
size equals number of attachments * sizeof(struct drm_asahi_attachment)
math queen behavior, honestly ๐งฎ๐
๐ vdm_barrier
VDM (render) command index to wait on. it's giving "hold up, let them go first" energy.
so how do barriers work? they're indices relative to the beginning of a given submit. let me break it down:
- a barrier of
0waits on commands submitted to the respective subqueue in previous submit ioctls - a barrier of
Nwaits onNprevious commands on the subqueue within the current submit ioctl - and as a special case, passing
DRM_ASAHI_BARRIER_NONEavoids waiting on any commands in the subqueue โญ
โญ Examples โญ
0: this waits on all previous work. all of it. patient queen ๐NONE: this does not wait for anything on this subqueue. zero thoughts, head empty ๐ซง1: this waits on the first render command in the submit. this is valid only if there are multiple render commands in the same submit ๐
barriers are valid only for hardware commands. synthetic software commands to set attachments must pass NONE here. no exceptions, bestie. periodt. ๐ฅ
๐ cdm_barrier
CDM (compute) command index to wait on.
just see vdm_barrier, and replace VDM/render with CDM/compute. same energy, different subqueue, iykyk ๐
๐ Description ๐
this struct is core to the command buffer definition and therefore is not extensible.
like, it's the blueprint. it's not getting new features. it's done. it's retired. we respect it ๐๐ธ
๐ SEE ALSO ๐
- Kernel file
./include/uapi/drm/asahi_drm.h - Introduction to the Asahi UAPI(9)
enum drm_asahi_ioctl_id(9)struct drm_asahi_params_global(9)enum drm_asahi_feature(9)struct drm_asahi_get_params(9)struct drm_asahi_vm_create(9)struct drm_asahi_vm_destroy(9)enum drm_asahi_gem_flags(9)struct drm_asahi_gem_create(9)struct drm_asahi_gem_mmap_offset(9)enum drm_asahi_bind_flags(9)struct drm_asahi_gem_bind_op(9)struct drm_asahi_vm_bind(9)enum drm_asahi_bind_object_op(9)enum drm_asahi_bind_object_flags(9)struct drm_asahi_gem_bind_object(9)enum drm_asahi_cmd_type(9)enum drm_asahi_priority(9)struct drm_asahi_queue_create(9)struct drm_asahi_queue_destroy(9)enum drm_asahi_sync_type(9)struct drm_asahi_sync(9)DRM_ASAHI_BARRIER_NONE(9)struct drm_asahi_submit(9)struct drm_asahi_attachment(9)struct drm_asahi_zls_buffer(9)struct drm_asahi_timestamp(9)struct drm_asahi_timestamps(9)struct drm_asahi_helper_program(9)struct drm_asahi_bg_eot(9)struct drm_asahi_cmd_render(9)struct drm_asahi_cmd_compute(9)struct drm_asahi_get_time(9)DRM_IOCTL_ASAHI(9)
and that's the whole page, bestie! ๐ this one lives in ./include/uapi/drm and it's dated October 2026 โ go read the whole Asahi UAPI saga, it ate and left no crumbs ๐
โจ๐ฆ
๐ฆ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms