On Thu, 28 May 2020 16:45:45 +0200 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote: ... > > Hmm. Maybe Wayland compositors should ignore all EGL import failures > > that happen after the wl_buffer has been created (which implies that > > the dmabuf has been validated to work initially). When import fails at > > a later time, the compositor should just paint some error pattern > > instead of the window. That would let the kernel keep on returning > > errors. > > > > Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how > > that looks then. > > tbh I have no idea what to do with dma-buf shared across drivers. > > For dma-fence it's fairly simple: Force-complete them all, with an error > code of ENODEV. But for dma-buf I have no idea. As long as the dma-buf > sits in system memory it should keep working, plus/minus bugs in the > exporter where it tries to look at device state that might no longer be > there. > > The real fun starts when the buffer is in vram, or when the mmap somehow > goes through the device (but that's more a case for integrated gpu, and > it's a bit hard to hotunplug those and consider that a real use-case). Is forced driver unbind not a real use-case, or would it not invalidate the memory references wrapped in a dmabuf? In the proposal, I listed driver unbind as a use-case. I don't mind if cross-driver shared dmabuf needed ten years of kernel internals development to reach a state where it won't explode anymore, but that's the goal I want to set today. I don't think we can tell userspace to never share dmabufs cross-device if the exporter device is hot-unpluggable, can we? Thanks, pq
Attachment:
pgpNR0cZ4RIlc.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
