[RFC] replacing dma_resv API

[Daniel Vetter]

On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> Quoting Christian König (2019-08-21 13:31:37)
> > Hi everyone,
> >
> > In previous discussion it surfaced that different drivers use the shared and explicit fences in the dma_resv object with different meanings.
> >
> > This is problematic when we share buffers between those drivers and requirements for implicit and explicit synchronization leaded to quite a number of workarounds related to this.
> >
> > So I started an effort to get all drivers back to a common understanding of what the fences in the dma_resv object mean and be able to use the object for different kind of workloads independent of the classic DRM command submission interface.
> >
> > The result is this patch set which modifies the dma_resv API to get away from a single explicit fence and multiple shared fences, towards a notation where we have explicit categories for writers, readers and others.
>
> Fwiw, I would like the distinction here between optional fences
> (writers, readers) and mandatory fences (others). The optional fences
> are where we put the implicit fence tracking that clever userspace would
> rather avoid. The mandatory fences (I would call internal) is where we
> put the fences for tracking migration that userspace can not opt out of.

I think this would make sense, and is kinda what I expected here. If
(and I think that's a huge if) we can agree on what those internal
fences are. There's a huge difference between internal fences for
buffer moves (better not ignore those) and internal fences like
amdkfd's eviction fence (better ignore those). So whatever we do add,
it better come with really clear docs and pretty diagrams about what
it's supposed to do, and how it's supposed to be used. Or we're just
back to the current mess we're in, times two.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch