https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #26 from Alex Deucher (alexdeucher@xxxxxxxxx) --- (In reply to Rainer Fiebig from comment #25) > (In reply to Alex Deucher from comment #23) > > I'll just revert it. It is more important for kernels with the the > > drm_buddy changes. > > Would the following be equivalent to what you intended with your commit? > Looks a bit awkward but hibernate/resume work with it for 6.0.19 (and a > Ryzen 5600G): > > > uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev, > uint32_t domain) > { > if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) { > domain = AMDGPU_GEM_DOMAIN_VRAM; > if ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type == > CHIP_STONEY)) > { > if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD) > domain = AMDGPU_GEM_DOMAIN_GTT; > } > } > return domain; > } > > > Let me know whether this is worth persuing. I could then test it with > 5.15.88 and 6.1.6. Nope. What my patch does is allow display buffers to be in either system memory (GTT) or carve out (VRAM) depending on what is available. Without the patch, the driver picks either VRAM or GTT depending on how much VRAM is available on the system. This can lead to memory exhaustion in some cases with multiple large resolution monitors depending on memory fragmentation. What your patch does is just always use VRAM unless the chip is Carrizo or Stoney. So it is effectively just reverting the commit (depending on how much VRAM your system has). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
