Re: [PATCH 1/3] drm/amdgpu: add AMDGPU_GEM_CREATE_DISCARDABLE

["Marek Olšák" <maraeo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

3rd question: Is it worth using this on APUs?

Thanks,
Marek

On Wed, May 11, 2022 at 5:58 PM Marek Olšák <maraeo@gmail.com> wrote:

> Will the kernel keep all discardable buffers in VRAM if VRAM is not
> overcommitted by discardable buffers, or will other buffers also affect the
> placement of discardable buffers?
>
> Do evictions deallocate the buffer, or do they keep an allocation in GTT
> and only the copy is skipped?
>
> Thanks,
> Marek
>
> On Wed, May 11, 2022 at 3:08 AM Marek Olšák <maraeo@gmail.com> wrote:
>
>> OK that sounds good.
>>
>> Marek
>>
>> On Wed, May 11, 2022 at 2:04 AM Christian König <
>> ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>> Hi Marek,
>>>
>>> Am 10.05.22 um 22:43 schrieb Marek Olšák:
>>>
>>> A better flag name would be:
>>> AMDGPU_GEM_CREATE_BEST_PLACEMENT_OR_DISCARD
>>>
>>>
>>> A bit long for my taste and I think the best placement is just a side
>>> effect.
>>>
>>>
>>> Marek
>>>
>>> On Tue, May 10, 2022 at 4:13 PM Marek Olšák <maraeo@gmail.com> wrote:
>>>
>>>> Does this really guarantee VRAM placement? The code doesn't say
>>>> anything about that.
>>>>
>>>
>>> Yes, see the code here:
>>>
>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>>>> index 8b7ee1142d9a..1944ef37a61e 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>>>> @@ -567,6 +567,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
>>>>>                 bp->domain;
>>>>>         bo->allowed_domains = bo->preferred_domains;
>>>>>         if (bp->type != ttm_bo_type_kernel &&
>>>>> +           !(bp->flags & AMDGPU_GEM_CREATE_DISCARDABLE) &&
>>>>>             bo->allowed_domains == AMDGPU_GEM_DOMAIN_VRAM)
>>>>>                 bo->allowed_domains |= AMDGPU_GEM_DOMAIN_GTT;
>>>>>
>>>>
>>> The only case where this could be circumvented is when you try to
>>> allocate more than physically available on an APU.
>>>
>>> E.g. you only have something like 32 MiB VRAM and request 64 MiB, then
>>> the GEM code will catch the error and fallback to GTT (IIRC).
>>>
>>> Regards,
>>> Christian.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 4737 bytes --]