[Intel-gfx] [RFC v3 0/9] Waitboost drm syncobj waits
Daniel Vetter
daniel at ffwll.ch
Thu Feb 16 11:19:24 UTC 2023
On Thu, Feb 16, 2023 at 10:59:12AM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>
> In i915 we have this concept of "wait boosting" where we give a priority boost
> for instance to fences which are actively waited upon from userspace. This has
> it's pros and cons and can certainly be discussed at lenght. However fact is
> some workloads really like it.
>
> Problem is that with the arrival of drm syncobj and a new userspace waiting
> entry point it added, the waitboost mechanism was bypassed. AFAIU this mostly
> happens with all Vulkan based userspaces. Hence I cooked up this mini series to
> see if discussion about restoring the waitboost can be had.
>
> The series adds a concept of "wait count" to dma fence which is intended to
> represent explicit userspace waits. It is therefore incremented for every
> explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like
> dma_fence_add_callback but from explicit/userspace wait paths). Individual
> drivers can then inspect this via dma_fence_wait_count() and decide to wait
> boost the waits on such fences.
>
> Patch has been slightly tested for performance impact by Google using some clvk
> workloads and shows a good improvement (frame time improved from 16ms to 13ms).
>
> It is also important to mention that benefits of waitboosting are not only about
> workloads related to frame presentation time, but also for serialized
> computations which constantly move between the CPU and GPU.
I think this should be integrated with https://lore.kernel.org/all/20210903184806.1680887-1-robdclark@gmail.com/
so that we have one overall approach here that works for all drivers.
Obviously should include support for all interested parties.
-Daniel
>
> *)
> https://gitlab.freedesktop.org/drm/intel/-/issues/8014
>
> v2:
> * Small fixups based on CI feedback:
> * Handle decrement correctly for already signalled case while adding callback.
> * Remove i915 assert which was making sure struct i915_request does not grow.
> * Split out the i915 patch into three separate functional changes.
>
> v3:
> * Handle drivers which open-code callback additions.
>
> Tvrtko Ursulin (9):
> dma-fence: Move i915 helpers into common
> dma-fence: Add callback initialization helper
> drm/i915: Use fence callback initialization helper
> drm/vmwgfx: Use fence callback initialization helper
> dma-fence: Track explicit waiters
> drm/syncobj: Mark syncobj waits as external waiters
> drm/i915: Waitboost external waits
> drm/i915: Mark waits as explicit
> drm/i915: Wait boost requests waited upon by others
>
> drivers/dma-buf/dma-fence.c | 137 ++++++++++++++------
> drivers/gpu/drm/drm_syncobj.c | 6 +-
> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 22 ----
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 -
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> drivers/gpu/drm/i915/i915_active.h | 2 +-
> drivers/gpu/drm/i915/i915_request.c | 13 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
> include/linux/dma-fence.h | 26 ++++
> 9 files changed, 141 insertions(+), 70 deletions(-)
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list