[PATCH 1/3] drm/amdgpu: Refuse to create a KMS FB for non-P2P exported dma-bufs

[Michel Dänzer]

On 2024-02-26 17:53, Christian König wrote:
> Am 26.02.24 um 17:50 schrieb Michel Dänzer:
>> On 2024-02-26 17:46, Michel Dänzer wrote:
>>> On 2024-02-26 17:34, Christian König wrote:
>>>
>>>> My question is why has it worked so far? I mean we are not doing this since yesterday and the problem only shows up now?
>>> Yes, Wayland compositors are only starting to try and make use of this now.
>> To expand on this, mutter will want to do something like this as well sooner or later. I suspect it's the same for others like kwin, sway etc.
> 
> Yeah, but we have done similar things with X decades before. E.g. basically the client sends a BO to the server for displaying it.

The scenario in https://gitlab.freedesktop.org/mesa/mesa/-/issues/10635 is direct scanout of a client buffer on a secondary dGPU, while the compositor uses the APU as the primary compositing GPU.

AFAIR Xorg has never supported direct scanout of client buffers in this scenario. Secondary GPU scanout is always done from a separate local buffer allocated by Xorg / the driver.

This is Wayland compositors pushing the envelope.


> Why we suddenly have to juggle with the fact that it is DMA-buf shared with another device?

The problematic case is if the Wayland compositor has to produce a composited frame (e.g. due to a notification or other window popping up over the fullscreen window), but the client hasn't attached a new buffer to the fullscreen surface, so the compositor has to use the contents of the same client buffer which is still being scanned out by the dGPU for compositing with the APU.


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer