On Fri, 2024-02-16 at 10:31 +0100, Thomas Hellström wrote: > Hi, Dave > > On Fri, 2024-02-16 at 12:58 +1000, Dave Airlie wrote: > > On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin > > <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > > > > > Hi Dave, Daniel, > > > > > > First pull request for 6.9 with probably one more coming in one > > > to > > > two > > > weeks. > > > > > > Nothing to interesting in this one, mostly a sprinkle of small > > > fixes in > > > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms > > > and > > > some > > > code cleanups. > > > > > > One new uapi in the form of a GuC submission version query which > > > Mesa > > > wants for implementing Vulkan async compute queues. > > > > > > Regards, > > > > > > Tvrtko > > > > > > drm-intel-gt-next-2024-02-15: > > > UAPI Changes: > > > > > > - Add GuC submission interface version query (Tvrtko Ursulin) > > > > > > Driver Changes: > > > > > > Fixes/improvements/new stuff: > > > > > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt) > > > > I've pulled this, but the above patch is triggering my this seems > > wrong spider sense. > > > > This and probably the preceeding patch that this references seem to > > move i915 to a long term pinning of userptr in memory with what I > > can > > see no accounting, and away from what the desired behaviour for > > drivers should be. > > I can only answer for the first patch there, It was some time ago it > was written, but at that point the pinning was held both by > get_pages() > and by submission. I removed the submission pinning and instead moved > get_pages() to start of submission. So no significant change in > pinning > time there. For some reason I can't clearly remember the submission > pinning got in the way of the vm_bind implementation. That said, the > pinning AFAIR is released in the gem shrinker. And it's different > from > what other drivers are doing. i915 never got to the point where it > completely dropped the pinning after the binding. (And with the first patch I mean "Simplify userptr locking") /Thomas > > /Thomas > > > > > > It also feels like the authorship on this might be lies which also > > worries me. > > > > Dave. >
