[PATCH] drm/amdgpu: Allow buffers that don't fit GTT into VRAM

Natalie Vock natalie.vock at gmx.de
Mon Mar 10 17:29:59 UTC 2025


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 at provod.gl>
>> Signed-off-by: Natalie Vock <natalie.vock at 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
>>
>



More information about the amd-gfx mailing list