On Thu, 28 May 2020 16:45:45 +0200 Daniel Vetter daniel@ffwll.ch 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