[Intel-gfx] [RFC 2/2] drm/i915/gem: Introduce VM_WAIT, a futex-lite operation

[Chris Wilson]

Quoting Chris Wilson (2020-01-18 21:29:03)
> Currently, we only allow waiting on the forward progress of an individual
> GEM object, or of a GEM execbuf fence. The primary purpose of the fence
> is to provide a scheduling primitive to order the execution flow of
> batches (cf VkSempahore).
> 
> Userspace instead uses values in memory to implement client fences, and
> has to mix busywaiting on the value coupled with a dma_fence in case it
> needs to sleep. It has no intermediate step where it can wait on the
> memory value itself to change, which is required for scenarios where the
> dma_fence may incur too much execution latency.
> 
> The CPU equivalent is a futex-syscall used to setup a waiter/waker based
> on a memory location. This is used to implement an efficient sleep for
> pthread_mutex_t, where the fast uncontended path can be handled entirely
> in userspace.
> 
> This patch implements a similar idea, where we take a virtual address in
> the client's ppGTT and install an interrupt handler to wake up the
> current task when the memory location passes the user supplied filter.
> It also allows the user to emit their own MI_USER_INTERRUPT within their
> batches after updating the value on the GPU to have sub-batch precision
> on the wakeup.
> 
> Opens:
> 
> - on attaching the waiter, we enable interrupts on all engines,
> irrespective of which are active to a VM.
>  * we can optimise when to enable interrupts while the VM is active
>  * we can extend the interface for the user to select which engines may
>    wake us
> 
> - we could return an fd wrapping the comparison operation on the memory
> address if we want to pass the waiter around different processes or
> reuse the waiter (with poll() + read() like timerfd).

The other thing we could do is wrap up the comparator into a dma_fence
so we can use it for scheduling as well.
-Chris