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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
