On Fri, Dec 09, 2022 at 12:07:49PM -0500, Alex Deucher wrote: > On Fri, Dec 9, 2022 at 4:32 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > On Fri, 9 Dec 2022 17:26:06 +0900 > > Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > > > > On Mon, Dec 5, 2022 at 5:29 PM Christian König <christian.koenig@xxxxxxx> 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 > > > > Even that is fraught with difficulty. We had a ton of bug reports > over the years claiming amdgpu was broken when users tried to use > displaylink devices in combination with AMD dGPUs because the > performance was so slow. The problem was that rather than using > dma-buf, the compositor was just mmaping the the dGPU BAR, which > happens to be uncached write combined and across the PCI bus, and > copying the data to the displaylink device. Read access to a PCI BAR > with the CPU is on the order of 10s of MB per second. Yeah you shouldn't readback dma-buf directly when you get them from a gl/vk driver, but instead use the tools these apis provide for cpu access. But that just puts us even more firmly into the "who even bothers" territory because people just hack up something that happens to work on their igpu (where at least on x86 you nowadays tend to get fully cpu cached buffers). -Daniel > > Alex > > > > > 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 > _______________________________________________ > Linaro-mm-sig mailing list -- linaro-mm-sig@xxxxxxxxxxxxxxxx > To unsubscribe send an email to linaro-mm-sig-leave@xxxxxxxxxxxxxxxx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
