<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
That would be redundant. GDS handling has always worked in the way
that the storage is thrown away after an IB.<br>
<br>
My LRU patch set should have helped with GDS out of memory errors,
but I'm not sure how far along we are with rebasing
amd-staging-drm-next.<br>
<br>
Christian.<br>
<br>
<div class="moz-cite-prefix">Am 08.07.22 um 16:58 schrieb Marek
Olšák:<br>
</div>
<blockquote type="cite"
cite="mid:CAAxE2A6CV+t9k4VG_zc5uf8qYK07Db0kqChYH0C9MB-TK7MU8g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Christian, should we set this flag for GDS too?
Will it help with GDS OOM failures?
<div dir="auto"><br>
</div>
<div dir="auto">Marek</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri., May 13, 2022, 07:26
Christian König, <<a
href="mailto:ckoenig.leichtzumerken@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Exactly
that's what we can't do.<br>
<br>
See the kernel must always be able to move things to GTT or
discard. So <br>
when you want to guarantee that something is in VRAM you must
at the <br>
same time say you can discard it if it can't.<br>
<br>
Christian.<br>
<br>
Am 13.05.22 um 10:43 schrieb Pierre-Eric Pelloux-Prayer:<br>
> Hi Marek, Christian,<br>
><br>
> If the main feature for Mesa of
AMDGPU_GEM_CREATE_DISCARDABLE is <br>
> getting the best placement, maybe we should have 2
separate flags:<br>
> * AMDGPU_GEM_CREATE_DISCARDABLE: indicates to the
kernel that it can <br>
> discards the content on eviction instead of preserving it<br>
> * AMDGPU_GEM_CREATE_FORCE_BEST_PLACEMENT (or <br>
> AMDGPU_GEM_CREATE_NO_GTT_FALLBACK ? or
AMDGPU_CREATE_GEM_AVOID_GTT?): <br>
> tells the kernel that this bo really needs to be in VRAM<br>
><br>
><br>
> Pierre-Eric<br>
><br>
> On 13/05/2022 00:17, Marek Olšák wrote:<br>
>> Would it be better to set the VM_ALWAYS_VALID flag to
have a greater <br>
>> guarantee that the best placement will be chosen?<br>
>><br>
>> See, the main feature is getting the best placement,
not being <br>
>> discardable. The best placement is a hw design
requirement due to <br>
>> using memory for uses that are expected to have
performance similar <br>
>> to onchip SRAMs. We need to make sure the best
placement is <br>
>> guaranteed if it's VRAM.<br>
>><br>
>> Marek<br>
>><br>
>> On Thu., May 12, 2022, 03:26 Christian König, <br>
>> <<a href="mailto:ckoenig.leichtzumerken@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>
<br>
>> <mailto:<a
href="mailto:ckoenig.leichtzumerken@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>>
wrote:<br>
>><br>
>> Am 12.05.22 um 00:06 schrieb Marek Olšák:<br>
>>> 3rd question: Is it worth using this on APUs?<br>
>><br>
>> It makes memory management somewhat easier when
we are really OOM.<br>
>><br>
>> E.g. it should also work for GTT allocations and
when the core <br>
>> kernel says "Hey please free something up or I will
start the <br>
>> OOM-killer" it's something we can easily throw away.<br>
>><br>
>> Not sure how many of those buffers we have, but
marking <br>
>> everything which is temporary with that flag is
probably a good idea.<br>
>><br>
>>><br>
>>> Thanks,<br>
>>> Marek<br>
>>><br>
>>> On Wed, May 11, 2022 at 5:58 PM Marek Olšák
<<a href="mailto:maraeo@gmail.com" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a> <br>
>>> <mailto:<a href="mailto:maraeo@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
wrote:<br>
>>><br>
>>> Will the kernel keep all discardable
buffers in VRAM if VRAM <br>
>>> is not overcommitted by discardable buffers, or
will other buffers <br>
>>> also affect the placement of discardable buffers?<br>
>>><br>
>><br>
>> Regarding the eviction pressure the buffers will
be handled like <br>
>> any other buffer, but instead of preserving the
content it is just <br>
>> discarded on eviction.<br>
>><br>
>>><br>
>>> Do evictions deallocate the buffer, or do
they keep an <br>
>>> allocation in GTT and only the copy is skipped?<br>
>>><br>
>><br>
>> It really deallocates the backing store of the
buffer, just keeps <br>
>> a dummy page array around where all entries are NULL.<br>
>><br>
>> There is a patch set on the mailing list to make
this a little <br>
>> bit more efficient, but even using the dummy page
array should only <br>
>> have a few bytes overhead.<br>
>><br>
>> Regards,<br>
>> Christian.<br>
>><br>
>>><br>
>>> Thanks,<br>
>>> Marek<br>
>>><br>
>>> On Wed, May 11, 2022 at 3:08 AM Marek
Olšák <br>
>>> <<a href="mailto:maraeo@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a>
<mailto:<a href="mailto:maraeo@gmail.com" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
wrote:<br>
>>><br>
>>> OK that sounds good.<br>
>>><br>
>>> Marek<br>
>>><br>
>>> On Wed, May 11, 2022 at 2:04 AM
Christian König <br>
>>> <<a
href="mailto:ckoenig.leichtzumerken@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>
<br>
>>> <mailto:<a
href="mailto:ckoenig.leichtzumerken@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>>
wrote:<br>
>>><br>
>>> Hi Marek,<br>
>>><br>
>>> Am 10.05.22 um 22:43 schrieb
Marek Olšák:<br>
>>>> A better flag name would be:<br>
>>>>
AMDGPU_GEM_CREATE_BEST_PLACEMENT_OR_DISCARD<br>
>>><br>
>>> A bit long for my taste and I
think the best <br>
>>> placement is just a side effect.<br>
>>><br>
>>>><br>
>>>> Marek<br>
>>>><br>
>>>> On Tue, May 10, 2022 at 4:13
PM Marek Olšák <br>
>>>> <<a href="mailto:maraeo@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a>
<mailto:<a href="mailto:maraeo@gmail.com" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
wrote:<br>
>>>><br>
>>>> Does this really
guarantee VRAM placement? The <br>
>>>> code doesn't say anything about that.<br>
>>>><br>
>>><br>
>>> Yes, see the code here:<br>
>>><br>
>>>><br>
>>>> diff --git <br>
>>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
<br>
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
>>>> index
8b7ee1142d9a..1944ef37a61e 100644<br>
>>>> --- <br>
>>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
>>>> +++ <br>
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
>>>> @@ -567,6 +567,7 @@
int <br>
>>>> amdgpu_bo_create(struct amdgpu_device *adev,<br>
>>>>
bp->domain;<br>
>>>>
bo->allowed_domains = <br>
>>>> bo->preferred_domains;<br>
>>>> if
(bp->type != ttm_bo_type_kernel &&<br>
>>>> +
!(bp->flags & <br>
>>>> AMDGPU_GEM_CREATE_DISCARDABLE) &&<br>
>>>>
bo->allowed_domains == <br>
>>>> AMDGPU_GEM_DOMAIN_VRAM)<br>
>>>> bo->allowed_domains |=
AMDGPU_GEM_DOMAIN_GTT;<br>
>>>><br>
>>><br>
>>> The only case where this could be
circumvented is <br>
>>> when you try to allocate more than physically
available on an APU.<br>
>>><br>
>>> E.g. you only have something like
32 MiB VRAM and <br>
>>> request 64 MiB, then the GEM code will catch the
error and fallback <br>
>>> to GTT (IIRC).<br>
>>><br>
>>> Regards,<br>
>>> Christian.<br>
>>><br>
>><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>