[RFC] replacing dma_resv API

[Christian König]

Am 21.08.19 um 22:22 schrieb 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.

Yeah, exactly that's the intention here.

Basic idea is to group the fences into the categories of "you always 
need to wait for when doing implicit synchronization" (writers), "you 
only need to wait for them when you want to write to the object" 
(readers) and "ignore them for implicit synchronization".

> 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).

Yeah, that's exactly why I want to get away from those exclusive/shared 
naming.

For readers/writers I hoped the semantic would be more clear, but that's 
doesn't seems to be the case.

> 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.

Well documenting it in the end is clearly a good idea, but I don't think 
we should start with that before we actually know what we want to 
implement and how we want to implement it.

Otherwise I would write tons of documentation which can be thrown away 
again in the end because we decided to don't do it this way.

Christian.

> -Daniel