On 2024-02-23 08:06, Christian König wrote: > Am 22.02.24 um 18:28 schrieb Michel Dänzer: >> From: Michel Dänzer <mdaen...@redhat.com> >> >> Pinning the BO storage to VRAM for scanout would make it inaccessible >> to non-P2P dma-buf importers. > > Thinking more about it I don't think we can do this. > > Using the BO in a ping/pong fashion for scanout and DMA-buf is actually > valid, you just can't do both at the same time. > > And if I'm not completely mistaken we actually have use cases for this at the > moment,
Those use cases don't have P2P & CONFIG_DMABUF_MOVE_NOTIFY? (As discussed on the GitLab issue, AFAICT P2P could be made to work even without CONFIG_DMABUF_MOVE_NOTIFY, by pinning to VRAM instead of GTT for dma-buf sharing) > only as fallback but it would still break existing userspace and that is a > no-go. I'm obviously aware of this general rule. There are exceptions though, and this might be one. > So rejecting things during CS and atomic commit is the best thing we can do. It's problematic for a Wayland compositor: The CS ioctl failing is awkward. With GL, I'm pretty sure it means the compositor would have to destroy the context and create a new one. Not sure about Vulkan, but I suspect it's painful there as well. Similarly for the KMS atomic commit ioctl. The compositor can't know why exactly it failed, all it gets is an error code. And there's no other way for the compositor to detect when both things can actually work concurrently. Together, this means the compositor always has to assume the worst case, and do workarounds such as using the scanout GPU to copy from the scanout buffer to another buffer for access from another GPU. Even when direct access from the other GPU would actually work fine. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
