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

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

Hi,

On 08/10/2026 15:40, Simon Richter wrote:
> Hi,
> 
> On 10/8/26 18:46, Matthew Auld wrote:
> 
>> From the user bug report it sounds like the dgpu linear window buffer 
>> exported to the compositor (igpu) is dual placement VRAM + TT, and so 
>> this now attempts to keep that memory in VRAM instead of moving it. 
>> Compositor then uses p2p to access it. It works but performance falls 
>> off a massive cliff here.
> 
> Is that because it is using external memory as a texture source, or 
> because copy operations are slow for some reason?

Not sure tbh.

> 
> If it is for a texture, the client should say so explicitly during the 
> import, e.g. a Vulkan[1] client would give a 
> VkExternalMemoryImageCreateInfo pointer in pNext, and fill out usage as 
> VK_IMAGE_USAGE_SAMPLED_BIT.
> 
> I think this would be the ideal point to either make sure the image ends 
> up in host memory, or reject it so the compositor can detect that this 
> is not a good texture source, and insert an extra transfer.

I think user reported that Vulkan was unaffected, it's just OpenGL. From 
kernel pov, we don't really know if we are actually meant to use p2p, or 
move to system memory, since we are lacking any kind of hint. This is 
maybe a miss. We just end up with a valid looking buffer with a dual 
placement that gets exported to amdgpu. On amd CPUs they allow p2p, even 
for igpu. So when user updated their kernel version, where the 
MOVE_NOTIFY config got removed and enabled by default this suddenly gave 
them the p2p path with buffer staying in VRAM, whereas before the buffer 
would have been correctly moved to system memory by the kernel.

> 
>     Simon
> 
> [1] Presumably, other graphics APIs have something similar.