From: "Christian König" <christian.koenig@amd.com>
To: Natalie Vock <natalie.vock@gmx.de>, amd-gfx@lists.freedesktop.org
Cc: Ivan Avdeev <1@provod.gl>
Subject: Re: [PATCH] drm/amdgpu: Allow buffers that don't fit GTT into VRAM
Date: Fri, 7 Mar 2025 09:39:41 +0100 [thread overview]
Message-ID: <43becf25-ad3b-4aae-9919-a74feede06a3@amd.com> (raw)
In-Reply-To: <20250306170118.40238-1-natalie.vock@gmx.de>
Am 06.03.25 um 18:01 schrieb Natalie Vock:
> When userspace requests buffers to be placed into GTT | VRAM, it is
> requesting the buffer to be placed into either of these domains. If the
> buffer fits into VRAM but does not fit into GTT, then let the buffer
> reside in VRAM instead of failing allocation entirely.
That will completely break suspend/resume on laptops.
we essentially need to always check if a BO can fit into GTT.
>
> Reported-by: Ivan Avdeev <1@provod.gl>
> Signed-off-by: Natalie Vock <natalie.vock@gmx.de>
> ---
> This originally came up in https://gitlab.freedesktop.org/mesa/mesa/-/issues/12713:
> The crux of the issue is that some applications expect they can allocate
> buffers up to the size of VRAM - however, some setups have a
> smaller-than-VRAM GTT region. RADV always sets VRAM | GTT for all buffer
> allocations, so this causes amdgpu to reject the allocation entirely
> because it cannot fit into GTT, even though it could fit into VRAM.
>
> In my opinion, this check doesn't make sense: It is completely valid
> behavior for the kernel to always keep a VRAM | GTT buffer in VRAM.
No it isn't. On suspend the power to VRAM is turned off and so we always need to be able to evacuate buffers into GTT.
Regards,
Christian.
> The only case where buffers larger than the GTT size are special is that
> they cannot be evicted to GTT (or swapped out), but the kernel already
> allows VRAM-only buffers to be larger than GTT, and those cannot be
> swapped out either. With the check removed, VRAM | GTT buffers larger
> than GTT behave exactly like VRAM-only buffers larger than GTT.
>
> The patch adding this check seems to have added it in a v2 - however I
> was unable to find any public discussion around the patch with reasoning
> in favor of this check.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 30 ++++++++++------------
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index d09db052e282d..b5e5fea091bf1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -555,27 +555,25 @@ static bool amdgpu_bo_validate_size(struct amdgpu_device *adev,
> {
> struct ttm_resource_manager *man = NULL;
>
> - /*
> - * If GTT is part of requested domains the check must succeed to
> - * allow fall back to GTT.
> - */
> - if (domain & AMDGPU_GEM_DOMAIN_GTT)
> - man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
> - else if (domain & AMDGPU_GEM_DOMAIN_VRAM)
> - man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
> - else
> + /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU, _DOMAIN_DOORBELL */
> + if (!(domain & (AMDGPU_GEM_DOMAIN_GTT | AMDGPU_GEM_DOMAIN_VRAM)))
> return true;
>
> - if (!man) {
> - if (domain & AMDGPU_GEM_DOMAIN_GTT)
> + if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
> + man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
> + if (size < man->size)
> + return true;
> + }
> + if (domain & AMDGPU_GEM_DOMAIN_GTT) {
> + man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
> + if (!man) {
> WARN_ON_ONCE("GTT domain requested but GTT mem manager uninitialized");
> - return false;
> + return false;
> + }
> + if (size < man->size)
> + return true;
> }
>
> - /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU, _DOMAIN_DOORBELL */
> - if (size < man->size)
> - return true;
> -
> DRM_DEBUG("BO size %lu > total memory in domain: %llu\n", size, man->size);
> return false;
> }
> --
> 2.48.1
>
next prev parent reply other threads:[~2025-03-07 8:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 17:01 [PATCH] drm/amdgpu: Allow buffers that don't fit GTT into VRAM Natalie Vock
2025-03-07 8:39 ` Christian König [this message]
2025-03-10 17:29 ` Natalie Vock
2025-03-10 18:04 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43becf25-ad3b-4aae-9919-a74feede06a3@amd.com \
--to=christian.koenig@amd.com \
--cc=1@provod.gl \
--cc=amd-gfx@lists.freedesktop.org \
--cc=natalie.vock@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox