radeon_ib_schedule(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– radeon_ib_schedule(9) πŸ’–

okay bestie, welcome to the Kernel API Manual β€” this one's all about yeeting an IB onto the ring, and honestly it's giving main-character energy. let's get into it 🫢


✨ NAME ✨

radeon_ib_schedule β€” schedule an IB (Indirect Buffer) on the ring. periodt. πŸ’…


🌈 SYNOPSIS 🌈

int radeon_ib_schedule (struct radeon_device *rdev , struct radeon_ib
*ib , struct radeon_ib *const_ib , bool hdp_flush );

πŸŽ€ ARGUMENTS πŸŽ€

  • rdev β€” a radeon_device pointer, aka the whole vibe of the device you're working with πŸ–₯️
  • ib β€” the IB object to schedule, the actual star of the show ⭐
  • const_ib β€” the Const IB to schedule β€” SI only bestie, don't forget 😭
  • hdp_flush β€” whether or not to perform an HDP cache flush β€” a simple lil yes/no vibe check πŸ’…

πŸ¦‹ DESCRIPTION πŸ¦‹

So what does this actually do? It schedules an IB on the associated ring β€” and yes, that's all asics, no cap. It returns 0 on success and an error on failure. iconic behavior honestly. ✨

Now here's where it gets spicy πŸ”₯ β€” on SI, there are two parallel engines fed from the primary ring:

  • the CE (Constant Engine) πŸ‘‘
  • and the DE (Drawing Engine) 🎨

Since resource descriptors have moved to memory, the CE lets you prime the caches while the DE is updating register state β€” so that the resource descriptors will already be in cache when the draw is processed. the way that works is genuinely so smart, iykyk πŸ§ πŸ’–

To accomplish this, the userspace driver submits two IBs β€” one for the CE and one for the DE. If there is a CE IB (called a CONST_IB), it will be put on the ring prior to the DE IB. and prior to SI? there was just a DE IB. simpler times fr fr πŸ•°οΈ


🌸 SEE ALSO 🌸


and that's the whole page bestie πŸŽ€ this lil masterpiece comes from ./drivers/gpu/drm/radeon, dated October 2026, and it's literally called radeon_ib_schedule(9) β€” slay, go schedule some IBs responsibly πŸ’œβœ¨

πŸ“¦ where this page comes from