drm_gpuvm_prepare_objects(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay bestie, meet drm_gpuvm_prepare_objects(9) β€” it's from the Kernel API Manual, and its whole job is prepare all associated BOs. no cap. πŸ’…

✨ SYNOPSIS ✨

int drm_gpuvm_prepare_objects (struct drm_gpuvm *gpuvm , struct drm_exec
       *exec , unsigned int num_fences );

🫢 ARGUMENTS 🫢

  • gpuvm β€” the drm_gpuvm. that's the main character here.
  • exec β€” the drm_exec locking context. the locking situation.
  • num_fences β€” the amount of dma_fences to reserve. yes, reserve.

🧚 DESCRIPTION 🧚

So this one calls drm_exec_prepare_obj for all the drm_gem_objects that the given drm_gpuvm contains mappings of. literally all of them. πŸ”₯

If num_fences is zero, then drm_exec_lock_obj is called instead. plot twist, but make it locking. 😭

Using this function directly means the drivers have the responsibility to call drm_exec_init and drm_exec_fini accordingly. like, you gotta handle your own setup and cleanup, bestie. 🫢

⚠️ NOTE ⚠️

This function is safe against concurrent insertion and removal of external objects. yay for that. πŸŽ€

But it is not safe against concurrent usage itself. nope. πŸ™ˆ

Drivers need to make sure to protect this case with either an outer VM lock, or by calling drm_gpuvm_prepare_vm before this function within the drm_exec_until_all_locked loop, such that the GPUVM's dma-resv lock ensures mutual exclusion. that's the whole mutual-exclusion moment. periodt. πŸ’…

πŸŽ€ RETURN πŸŽ€

0 on success, negative error code on failure. slay when zero, sad little negative when not. 😭

🌈 SEE ALSO 🌈

mwah πŸ’‹ this little page comes from ./drivers/gpu/drm, dated October 2026, and signs off as drm_gpuvm_prepare_objects(9). bye bestie, go prepare those BOs πŸ’–βœ¨

πŸ“¦ where this page comes from