On Tue, Oct 31, 2023 at 3:14 PM Michel Dänzer <michel.daenzer@xxxxxxxxxxx> 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
