AMD General > -----Original Message----- > From: SHANMUGAM, SRINIVASAN > Sent: Monday, June 15, 2026 2:37 PM > To: Koenig, Christian <[email protected]>; Thomas Hellström > <[email protected]>; [email protected] > Cc: Matthew Brost <[email protected]>; Maarten Lankhorst > <[email protected]>; Michal Mrozek <[email protected]>; > John Falkowski <[email protected]>; Rodrigo Vivi > <[email protected]>; Lahtinen Joonas <[email protected]>; > David Howells <[email protected]>; Christian Brauner <[email protected]>; > Kees Cook <[email protected]>; Davidlohr Bueso <[email protected]>; Dave > Airlie <[email protected]>; Simona Vetter <[email protected]>; dri- > [email protected]; LMKL <[email protected]> > Subject: RE: [RFC PATCH 0/4] Xe driver asynchronous notification mechanism > > > > > -----Original Message----- > > From: Koenig, Christian <[email protected]> > > Sent: Monday, June 15, 2026 1:42 PM > > To: Thomas Hellström <[email protected]>; intel- > > [email protected]; SHANMUGAM, SRINIVASAN > > <[email protected]> > > Cc: Matthew Brost <[email protected]>; Maarten Lankhorst > > <[email protected]>; Michal Mrozek > > <[email protected]>; John Falkowski <[email protected]>; > > Rodrigo Vivi <[email protected]>; Lahtinen Joonas > > <[email protected]>; > > David Howells <[email protected]>; Christian Brauner > > <[email protected]>; Kees Cook <[email protected]>; Davidlohr Bueso > > <[email protected]>; Dave Airlie <[email protected]>; Simona Vetter > > <[email protected]>; dri- [email protected]; LMKL > > <[email protected]> > > Subject: Re: [RFC PATCH 0/4] Xe driver asynchronous notification > > mechanism > > > > Hi Thomas, Srini, > > > > Srini is already working quite a while on something similar for > > amdgpu. We use eventfd and a device specific IOCTL instead of the > watch_queue proposed here. > > > > Srini please take a look at this, it is basically the equivalent of > > our event notification approach for KFD/KGD unification. Maybe we > > could learn from that and/or have something common for both drivers. > > Hi Christian, Hi Thomas, > > Thank you, Christian, for pointing this out. > > I took a look at the Xe series and found it very interesting to compare it > with the > ongoing AMDGPU EVENTFD work. > > From my understanding, the Xe approach uses watch_queue for both notification > and payload delivery, whereas the current AMDGPU approach uses EVENTFD as > a lightweight wake-up mechanism, with WAIT_EVENT providing the details when > userspace needs them. > > One thing I noticed is that the event characteristics seem somewhat > different. Xe > appears to be dealing with relatively infrequent VM-oriented events (for > example, > OOM or VM restart), while AMDGPU also has queue-oriented events such as > USERQ_EOP that may occur much more frequently. > > I may be missing some of the bigger picture here, so I wanted to ask for your > guidance on the intended direction. > > Do you see watch_queue as a possible long-term common DRM notification > framework that AMDGPU should eventually move towards, or is the intention > mainly > to compare the approaches and allow each driver to choose what best fits its > event > model? > > I was also wondering whether it makes sense to treat these event classes > differently: lightweight queue wake-up events continuing to use EVENTFD + > WAIT_EVENT, while richer, lower-frequency device-level events could > potentially > use structured watch_queue notifications. > > I would really appreciate your thoughts before we proceed further. > > Thank you again for raising this and for sharing the Xe work. > > Thanks, > Srini >
Hi Christian, Sharing the AMDGPU patch series for reference: EVENTFD series: https://patchwork.freedesktop.org/series/164618/ WAIT_EVENT series: https://patchwork.freedesktop.org/series/164813/#rev7 Xe seems to be solving a similar notification problem, so these may be useful for comparison. Thanks, Srini > > > > Thanks, > > Christian.
