Re: Try to address the DMA-buf coherency problem

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7983 bytes --]

On Fri, 9 Dec 2022 17:26:06 +0900
Tomasz Figa <tfiga@chromium.org> wrote:

> On Mon, Dec 5, 2022 at 5:29 PM Christian König <christian.koenig@amd.com> wrote:
> >
> > Hi Tomasz,
> >
> > Am 05.12.22 um 07:41 schrieb Tomasz Figa:  
> > > [SNIP]  
> > >> In other words explicit ownership transfer is not something we would
> > >> want as requirement in the framework, cause otherwise we break tons of
> > >> use cases which require concurrent access to the underlying buffer.
> > >>
> > >> When a device driver needs explicit ownership transfer it's perfectly
> > >> possible to implement this using the dma_fence objects mentioned above.
> > >> E.g. drivers can already look at who is accessing a buffer currently and
> > >> can even grab explicit ownership of it by adding their own dma_fence
> > >> objects.
> > >>
> > >> The only exception is CPU based access, e.g. when something is written
> > >> with the CPU a cache flush might be necessary and when something is read
> > >> with the CPU a cache invalidation might be necessary.
> > >>  
> > > Okay, that's much clearer now, thanks for clarifying this. So we
> > > should be covered for the cache maintenance needs originating from CPU
> > > accesses already, +/- the broken cases which don't call the begin/end
> > > CPU access routines that I mentioned above.
> > >
> > > Similarly, for any ownership transfer between different DMA engines,
> > > we should be covered either by the userspace explicitly flushing the
> > > hardware pipeline or attaching a DMA-buf fence to the buffer.
> > >
> > > But then, what's left to be solved? :) (Besides the cases of missing
> > > begin/end CPU access calls.)  
> >
> > Well there are multiple problems here:
> >
> > 1. A lot of userspace applications/frameworks assume that it can
> > allocate the buffer anywhere and it just works.
> >
> > This isn't true at all, we have tons of cases where device can only
> > access their special memory for certain use cases.
> > Just look at scanout for displaying on dGPU, neither AMD nor NVidia
> > supports system memory here. Similar cases exists for audio/video codecs
> > where intermediate memory is only accessible by certain devices because
> > of content protection.  
> 
> Ack.
> 
> Although I think the most common case on mainstream Linux today is
> properly allocating for device X (e.g. V4L2 video decoder or DRM-based
> GPU) and hoping that other devices would accept the buffers just fine,
> which isn't a given on most platforms (although often it's just about
> pixel format, width/height/stride alignment, tiling, etc. rather than
> the memory itself). That's why ChromiumOS has minigbm and Android has
> gralloc that act as the central point of knowledge on buffer
> allocation.

Hi,

as an anecdote, when I was improving Mutter's cross-DRM-device handling
(for DisplayLink uses) a few years ago, I implemented several different
approaches of where to allocate, to try until going for the slowest but
guaranteed to work case of copying every update into and out of sysram.

It seems there are two different approaches in general for allocation
and sharing:

1. Try different things until it works or you run out of options

pro:
- no need for a single software component to know everything about
  every device in the system

con:
- who bothers with fallbacks, if the first try works on my system for
  my use case I test with? I.e. cost of code in users.
- trial-and-error can be very laborious (allocate, share with all
  devices, populate, test)
- the search space might be huge


2. Have a central component that knows what to do

pro:
- It might work on the first attempt, so no fallbacks in users.
- It might be optimal.

con:
- You need a software component that knows everything about every
  single combination of hardware in existence, multiplied by use cases.


Neither seems good, which brings us back to https://github.com/cubanismo/allocator .


> > 2. We don't properly communicate allocation requirements to userspace.
> >
> > E.g. even if you allocate from DMA-Heaps userspace can currently only
> > guess if normal, CMA or even device specific memory is needed.  
> 
> DMA-buf heaps actually make it even more difficult for the userspace,
> because now it needs to pick the right heap. With allocation built
> into the specific UAPI (like V4L2), it's at least possible to allocate
> for one specific device without having any knowledge about allocation
> constraints in the userspace.
> 
> >
> > 3. We seem to lack some essential parts of those restrictions in the
> > documentation.
> >  
> 
> Ack.
> 
> > >>>> So if a device driver uses cached system memory on an architecture which
> > >>>> devices which can't access it the right approach is clearly to reject
> > >>>> the access.  
> > >>> I'd like to accent the fact that "requires cache maintenance" != "can't access".  
> > >> Well that depends. As said above the exporter exports the buffer as it
> > >> was allocated.
> > >>
> > >> If that means the the exporter provides a piece of memory which requires
> > >> CPU cache snooping to access correctly then the best thing we can do is
> > >> to prevent an importer which can't do this from attaching.  
> > > Could you elaborate more about this case? Does it exist in practice?
> > > Do I assume correctly that it's about sharing a buffer between one DMA
> > > engine that is cache-coherent and another that is non-coherent, where
> > > the first one ends up having its accesses always go through some kind
> > > of a cache (CPU cache, L2/L3/... cache, etc.)?  
> >
> > Yes, exactly that. What happens in this particular use case is that one
> > device driver wrote to it's internal buffer with the CPU (so some cache
> > lines where dirty) and then a device which couldn't deal with that tried
> > to access it.  
> 
> If so, shouldn't that driver surround its CPU accesses with
> begin/end_cpu_access() in the first place?
> 
> The case that I was suggesting was of a hardware block that actually
> sits behind the CPU cache and thus dirties it on writes, not the
> driver doing that. (I haven't personally encountered such a system,
> though.)
> 
> >
> > We could say that all device drivers must always look at the coherency
> > of the devices which want to access their buffers. But that would
> > horrible complicate things for maintaining the drivers because then
> > drivers would need to take into account requirements from other drivers
> > while allocating their internal buffers.  
> 
> I think it's partially why we have the allocation part of the DMA
> mapping API, but currently it's only handling requirements of one
> device. And we don't have any information from the userspace what
> other devices the buffer would be used with...
> 
> Actually, do we even have such information in the userspace today?
> Let's say I do a video call in a web browser on a typical Linux
> system. I have a V4L2 camera, VAAPI video encoder and X11 display. The
> V4L2 camera fills in buffers with video frames and both encoder and
> display consume them. Do we have a central place which would know that
> a buffer needs to be allocated that works with the producer and all
> consumers?

I have a vague belief that many, many years ago, in the early days of
dmabuf development, there was the idea of the sequence:
- create a dmabuf handle
- share the handle with all devices that would need access
- *then* do the allocation with kernel-internal negotiation to fill all
  devices' needs, if at all possible

Obviously that didn't happen. I think today's dmabuf Wayland protocol
would support this though.

Anyway, Wayland can tell the app which DRM devices a buffer
needs to work with as a GPU texture and potentially on same/another
DRM device as a KMS framebuffer, so theoretically the app could know.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]