On Tue, Oct 31, 2023 at 3:14 PM Michel Dänzer <michel.daen...@mailbox.org> wrote:
> On 10/31/23 14:40, Tatsuyuki Ishi wrote: > > In Vulkan, it is the application's responsibility to perform adequate > > synchronization before a sparse unmap, replace or BO destroy operation. > > Until now, the kernel applied the same rule as implicitly-synchronized > > APIs like OpenGL, which with per-VM BOs made page table updates stall the > > queue completely. The newly added AMDGPU_VM_EXPLICIT_SYNC flag allows > > drivers to opt-out of this behavior, while still ensuring adequate > implicit > > sync happens for kernel-initiated updates (e.g. BO moves). > > > > We record whether to use implicit sync or not for each freed mapping. To > > avoid increasing the mapping struct's size, this is union-ized with the > > interval tree field which is unused after the unmap. > > > > The reason this is done with a GEM ioctl flag, instead of being a VM / > > context global setting, is that the current libdrm implementation shares > > the DRM handle even between different kind of drivers (radeonsi vs radv). > > Different drivers always use separate contexts though, even with the same > DRM file description, don't they? > > FWIW, RADV will also want explicit sync in the CS ioctl. > > I think a crucial problem is that VA ioctls don't take a context so a per-context flag doesn't solve this (the previous attempt used it because all the sync changes were on the CS submit side and not the VA ioctl side) . So I'd still like to solve that side for RADV, but I think the VA ioctl flag makes sense here if we need to do anything different VA ioctl wise. > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and Xwayland developer > >