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

2024-02-26 Thread 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

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

2024-02-26 Thread Christian König
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

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

2024-02-26 Thread 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

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

2024-02-26 Thread Michel Dänzer
On 2024-02-26 17:34, Christian König wrote: > Am 26.02.24 um 17:27 schrieb Michel Dänzer: >> On 2024-02-26 16:58, Christian König wrote: >>> Am 23.02.24 um 17:43 schrieb Michel Dänzer: On 2024-02-23 11:04, Michel Dänzer wrote: > On 2024-02-23 10:34, Christian König wrote: >> Am

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

2024-02-26 Thread Christian König
Am 26.02.24 um 17:27 schrieb Michel Dänzer: On 2024-02-26 16:58, Christian König wrote: Am 23.02.24 um 17:43 schrieb Michel Dänzer: On 2024-02-23 11:04, Michel Dänzer wrote: On 2024-02-23 10:34, Christian König wrote: Am 23.02.24 um 09:11 schrieb Michel Dänzer: On 2024-02-23 08:06,

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

2024-02-26 Thread Michel Dänzer
On 2024-02-26 16:58, Christian König wrote: > Am 23.02.24 um 17:43 schrieb Michel Dänzer: >> On 2024-02-23 11:04, Michel Dänzer wrote: >>> On 2024-02-23 10:34, Christian König wrote: Am 23.02.24 um 09:11 schrieb Michel Dänzer: > On 2024-02-23 08:06, Christian König wrote: >> Am

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

2024-02-26 Thread Christian König
Am 23.02.24 um 17:43 schrieb Michel Dänzer: On 2024-02-23 11:04, Michel Dänzer wrote: On 2024-02-23 10:34, Christian König wrote: Am 23.02.24 um 09:11 schrieb Michel Dänzer: 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 Pinning

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

2024-02-23 Thread Michel Dänzer
On 2024-02-23 11:04, Michel Dänzer wrote: > On 2024-02-23 10:34, Christian König wrote: >> Am 23.02.24 um 09:11 schrieb Michel Dänzer: >>> 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 > > Pinning the BO storage to

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

2024-02-23 Thread Michel Dänzer
On 2024-02-23 10:34, Christian König wrote: > Am 23.02.24 um 09:11 schrieb Michel Dänzer: >> 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 Pinning the BO storage to VRAM for scanout would make it inaccessible to

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

2024-02-23 Thread Christian König
Am 23.02.24 um 09:11 schrieb Michel Dänzer: 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 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

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

2024-02-23 Thread Michel Dänzer
On 2024-02-23 09:11, Michel Dänzer wrote: > On 2024-02-23 08:06, Christian König wrote: >> >> 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 >

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

2024-02-23 Thread Michel Dänzer
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 >> >> 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

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

2024-02-22 Thread Christian König
Am 22.02.24 um 18:28 schrieb Michel Dänzer: From: Michel Dänzer 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

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

2024-02-22 Thread Michel Dänzer
From: Michel Dänzer Pinning the BO storage to VRAM for scanout would make it inaccessible to non-P2P dma-buf importers. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10635 Signed-off-by: Michel Dänzer --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 38 ++--- 1