From: Natalie Vock <natalie.vock@gmx.de>
To: "Christian König" <christian.koenig@amd.com>,
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: Mon, 10 Mar 2025 18:29:59 +0100 [thread overview]
Message-ID: <ae4084f2-a34e-44db-936f-be4f8204e7ea@gmx.de> (raw)
In-Reply-To: <43becf25-ad3b-4aae-9919-a74feede06a3@amd.com>
On 07.03.25 09:39, Christian König wrote:
> 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.
Good point, I forgot about suspend. But as you say, we always need to do
this, even for VRAM-only BOs. I'll send a v2 for that in a minute.
Thanks, Natalie
>
>>
>> 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-10 18:05 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
2025-03-10 17:29 ` Natalie Vock [this message]
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=ae4084f2-a34e-44db-936f-be4f8204e7ea@gmx.de \
--to=natalie.vock@gmx.de \
--cc=1@provod.gl \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
/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