STRUCT DRM_ROCKET_JOB(9)

๐Ÿ“ฆ version 7.3.1, in nixpkgs unstable

๐Ÿ’… struct drm_rocket_job(9) โ€” the Kernel API Manual, bestie edition ๐Ÿš€

okay so picture this: you're in the Kernel API Manual, and the star of the show is struct drm_rocket_job โ€” literally a job to be run on the NPU. no cap, that's the whole vibe. it's giving "work order for the neural processing unit" energy and honestly? iconic. ๐ŸŽ€


โœจ NAME โœจ

struct drm_rocket_job โ€” a job to be run on the NPU ๐Ÿงš


๐ŸŒธ SYNOPSIS ๐ŸŒธ

here's the whole glow-up, verbatim, don't touch:

struct drm_rocket_job {
    __u64 tasks;
    __u64 in_bo_handles;
    __u64 out_bo_handles;
    __u32 task_count;
    __u32 task_struct_size;
    __u32 in_bo_handle_count;
    __u32 out_bo_handle_count;
 };

yes bestie, every field, every type, every semicolon. we stan a well-formed struct. ๐Ÿ’œ


๐Ÿฆ‹ Members ๐Ÿฆ‹

every single one is an Input, so you're feeding the kernel, not the other way around. main character energy only.

  • tasks โ€” Input: pointer to an array of struct drm_rocket_task. ๐Ÿ‘‘ this is the actual list of stuff to do.
  • in_bo_handles โ€” Input: pointer to a u32 array of the BOs that are read by the job. these are the things your job is gonna peek at. ๐Ÿ™ˆ
  • out_bo_handles โ€” Input: pointer to a u32 array of the BOs that are written to by the job. the destinations, the glow-up locations. โœจ
  • task_count โ€” Input: number of tasks passed in. count your blessings, count your tasks. ๐Ÿ”ข
  • task_struct_size โ€” Input: size in bytes of the structs in the tasks field. the kernel needs to know how chunky they are. ๐Ÿ“
  • in_bo_handle_count โ€” Input: number of input BO handles passed in (size is that times 4). do the math, it's literally times 4. ๐Ÿงฎ
  • out_bo_handle_count โ€” Input: number of output BO handles passed in (size is that times 4). same deal, also times 4. ๐Ÿ’…

๐Ÿ”ฅ Description ๐Ÿ”ฅ

so here's what actually happens, fr fr: the kernel will schedule the execution of this job taking into account its dependencies with other jobs. yes, it's doing the scheduling homework for you, you're welcome. ๐ŸŒˆ

and the cute part? all tasks in the same job will be executed sequentially on the same core, to benefit from memory residency in SRAM. that's right โ€” one job, one core, in order, so everything stays cozy in SRAM and nobody has to go all the way back to regular memory. it's giving "squad stays together" and honestly the SRAM residency is the whole point. โญ don't break the streak, keep your tasks in one job if you want that sweet, sweet locality. ๐Ÿซถ


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

go read these next, bestie, iykyk:

  • Kernel file ./include/uapi/drm/rocket_accel.h
  • struct drm_rocket_create_bo(9)
  • struct drm_rocket_prep_bo(9)
  • struct drm_rocket_fini_bo(9)
  • struct drm_rocket_task(9)
  • struct drm_rocket_submit(9)

all of these are your besties too, literally the whole friend group. ๐Ÿ’–


๐Ÿ’€ reminder: every field above is marked Input, so don't go expecting the kernel to fill them in for you. you bring the data, it brings the NPU. periodt.

k bye, this page lived in ./include/uapi/drm and it's dated October 2026, signed off with love as struct drm_rocket_job(9) ๐Ÿ’…โœจ go schedule something iconic ๐Ÿš€

๐Ÿ“ฆ where this page comes from