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:55 +0200, Christian König wrote:
> On 10/13/26 11:18, Thomas Hellström wrote:
> ...
> > > > > > > > > > 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/7
> > > > > > > > > ec86
> > > > > > > > > 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?
> 
> Yeah that is possible, but that should only happen when there is some
> change.
> 
> When the iGPU reads the buffer only once then that isn't really
> problematic, it's actually exactly what should happen.
> 
> It only becomes problematic when the buffer is read multiple times to
> construct multiple frames, either because the compositor does
> something unexpected or we really start to scanout from the buffer.

But in windowed mode (and perhaps even fullscreen?) the compositor
blits repeatedly over PCI each frame from the dma-buf? 

/Thomas



> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> >