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

[Matthew Auld <matthew.auld@intel.com>]

On 13/10/2026 12:45, Christian König wrote:
> On 10/13/26 12:16, Thomas Hellström wrote:
>> 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?
> 
> It usually doesn't.
> 
> In fullscreen mode using the buffer directly for scanout in an atomic commit should be rejected by the kernel because the HW can't do this.
> 
> The fallback path then copies the buffer content to a locally allocated buffer exactly once and then display that new buffer.
> 
> I'm not 100% sure what happens in windowed mode for the specific compositor the end user is using. What could be is that when the compositor gets buffers from multiple applications that it composes multiple times over PCIe, but it is unlikely that this will cause problems. You would need something like game/test running on dGPU and glxgears without vblank sync on the iGPU.
> 
> AMD uses basically exactly that setup in the Tesla infotainment system for example and it works perfectly fine there.
> 
> I have not the slightest idea what's going wrong here.

My rough mental model here (could be waaaay wrong), is that dgpu is 
constantly rendering into a private VRAM buffer, and then copying that 
to a linear buffer which is the window buffer exported to the 
compositor. Display is plugged into the igpu. DRI_PRIME=1 is used for 
the game (like GravityMark) to the do rendering on the dgpu.

In windowed mode, every frame the compositor needs to somehow sample the 
exported window/texture from a shader, like in mutter. In this flow the 
igpu is still using native buffer for the actual scanout.

That exported window buffer is using a flexible placement, so it could 
technically go in VRAM or system memory. But I don't think p2p was on 
the bingo cards here for Intel. So if you suddenly negotiate p2p instead 
of moving it, it now stays in VRAM. So igpu is now constantly reading 
over pcie every frame, which is extremely slow it seems, for the user.

Other thing is that when I tried to repro this locally, I used xe igpu + 
xe dgpu, and manually forcing p2p in the kernel. When I traced it with 
bpf I just see the private VRAM buffer sitting there, and the exported 
window buffer as system memory. So no p2p. There was also no ping-pong, 
so it must mean that the exported window buffer is NOT flexible 
placement in this multi-GPU setup.

So it could potentially be specific to some cross-driver flow with 
OpenGL, like with amd + intel, where you can end up with the flexible 
placement for the exported window buffer on some multi-GPU setups. Not 
100% sure though.

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