On 6/24/26 19:55, Harry Wentland wrote: > On 2026-06-24 11: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. >> >> 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). >> >> Would it somehow be possible to get DC to dynamically switch between VRAM >> and GTT? > > DCN can't switch between mapped and unmapped memory. I'm not a memory > management expert but wouldn't GTT be in GART (mapped) and VRAM in > the (unmapped) FB aperture? > > From DCHUB HW doc: > "No change from mapped to unmapped or unmapped to mapped is > allowed for immediate f lip" > > If so, we can't async flip between them.
A possible alternative solution then might be explicitly pinning the BO to either VRAM or GTT for an async commit, wherever the current scanout BO is located. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
