On 6/24/26 17:52, Christian König wrote: > On 6/24/26 17:30, Harry Wentland wrote: >> On 2026-06-16 03:31, Christian König wrote: >>> On 6/16/26 09:10, Matthew Schwartz wrote: >>>> Native scanout buffers on APUs are pinned with the VRAM|GTT domain, so >>>> under VRAM carveout pressure a swapchain can end up split across VRAM and >>>> GTT. The scanout buffer's memory type then changes from one flip to the >>>> next, and amdgpu_dm_crtc_mem_type_changed() rejects an async page flip >>>> across the change. The result is repeated async page flip failures, >>>> observed as choppy updates under carveout pressure, until the buffers >>>> reconverge to a single domain. >>> >>> That's intentional behavior. >>> >>>> Pin native scanout buffers in VRAM only so the swapchain stays in one >>>> memory domain. Restrict this to APUs whose carveout is larger than >> >> Above you mention that under VRAM pressure a swapchain can end up split >> across VRAM and GTT. Wouldn't restricting the swapchain to VRAM now mean >> that in those cases you fail to allocate the swapchain entirely? > > Yes, exactly that.
This doesn't affect swapchain allocation, does it? It only affects whether or not an atomic commit succeeds or fails. > My educated guess is that the display server then falls back to using a copy > instead of a flip and that helps saving memory somehow (e.g. less scanout > buffers alocated concurrently). If an atomic commit fails (e.g. because the buffer can't be pinned to VRAM), I'd expect a Wayland compositor to first fall back from direct scanout of a client buffer to compositing, or if it's for a composited buffer, from an async commit to a non-async one. Xorg can further fall back to copying from the new buffer to the current scanout buffer, not sure any Wayland compositor does that though. Mutter doesn't, I suspect it would freeze if a non-async commit to a composited buffer fails. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
