Re: [PATCH v2 3/3] drm/xe: skip p2p for suspected display buffers

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Tue, 2026-10-13 at 11:10 +0200, Christian König wrote:
> On 10/13/26 10:51, Matthew Auld wrote:
> > On 09/10/2026 14:02, Matthew Auld wrote:
> > > On 09/10/2026 12:38, Christian König wrote:
> > > > On 10/9/26 12:29, Matthew Auld wrote:
> > > > > On 09/10/2026 10:26, Christian König wrote:
> > > > > > On 10/9/26 11:16, Matthew Auld wrote:
> > > > > > > On 08/10/2026 12:17, Matthew Auld wrote:
> > > > > > > > On 08/10/2026 10:55, Christian König wrote:
> > > > > > > > > On 10/8/26 11:46, Matthew Auld wrote:
> > > > > > > > > > On 07/10/2026 19:11, Thomas Hellström wrote:
> > > > > > > > > > > On Wed, 2026-10-07 at 16:36 +0100, Matthew Auld
> > > > > > > > > > > wrote:
> ....
> > > > > > > > > > Perhaps Intel Mesa side should use tt-only for this
> > > > > > > > > > type buffer (?), but since this is a kernel
> > > > > > > > > > regression I was hoping we could fix this on the
> > > > > > > > > > kernel side.
> > > > > > > > > > 
> > > > > > > > > > Some questions:
> > > > > > > > > > 
> > > > > > > > > > 1. Do you know what is the general story with p2p
> > > > > > > > > > between igpu and dgpu? Is this a legit thing? For
> > > > > > > > > > igpus/APUs, advertising p2p can't be dropped? It
> > > > > > > > > > clearly seems to work though.
> > > > > > > > > > 
> > > > > > > > > > 2. If this is legit, do you guys then also prevent
> > > > > > > > > > p2p with display buffers? Are you just doing that
> > > > > > > > > > at the Mesa level, or is there some magic in the
> > > > > > > > > > kernel also?
> > > > > > > > > 
> > > > > > > > > If I understand that correctly that the igpu is the
> > > > > > > > > importer and the dgpu is the exporter then yeah
> > > > > > > > > Thomas is right that definately needs to be fixed on
> > > > > > > > > the importer side.
> > > > > > > > 
> > > > > > > > Ideas on how do that? Could we do something like
> > > > > > > > allow_peer2peer = false in amdgpu_gem_prime_import() if
> > > > > > > > this is an APU device, or further check if the exporter
> > > > > > > > side is not amdgpu, like APU + Xe?
> > > > > > > 
> > > > > > > For example:
> > > > > > > https://gitlab.freedesktop.org/mwa/kernel/-/ commit/7ec86
> > > > > > > c68b42655b4bb85ee90af434a617e7bec8c
> > > > > > > 
> > > > > > > Is that something you would accept?
> > > > > > 
> > > > > > No, you misunderstood me. Enabling P2P is perfectly fine
> > > > > > for APUs and mandatory for a couple of customer projects.
> > > > > > 
> > > > > > The buffer should just be rejected from scanout in the
> > > > > > display code and on the AMDGPU side we already do that if
> > > > > > I'm not completely mistaken.
> > > > > 
> > > > > Reporter confirmed seeing the issue in windowed mode also. So
> > > > > I don't think it's just a case of rejecting from scanout?
> > > > 
> > > > Then I don't understand what the problem is.
> > > > 
> > > > When the dGPU renders and the iGPU displays you have only two
> > > > possibilities, either the dGPU pushes the frames over the bus
> > > > or the iGPU pulls the frames over the bus. Both should be
> > > > equaly slow or fast, so what exactly is the expectation here?
> > > 
> > > I assume the AMD APU/iGPU is sampling/reading from the p2p window
> > > buffer every frame.
> 
> That is not possible. The HW can't do this and because of this we
> should have a check for that in the DAL/DC code.
> 
Couldn't the issue be that the compositor, running on the amd iGPU
blits from the dma-buf rather than scans out from it? And the scanout
is not the shared buffer at all?

/Thomas