Am 21.08.19 um 22:22 schrieb Daniel Vetter:
On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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
