<div dir="auto">Would it be better to set the VM_ALWAYS_VALID flag to have a greater guarantee that the best placement will be chosen?<div dir="auto"><br></div><div dir="auto">See, the main feature is getting the best placement, not being discardable. The best placement is a hw design requirement due to using memory for uses that are expected to have performance similar to onchip SRAMs. We need to make sure the best placement is guaranteed if it's VRAM.</div><div dir="auto"><br></div><div dir="auto">Marek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu., May 12, 2022, 03:26 Christian König, <<a href="mailto:ckoenig.leichtzumerken@gmail.com">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">
<div>
Am 12.05.22 um 00:06 schrieb Marek Olšák:<br>
<blockquote type="cite">
<div dir="ltr">
<div>3rd question: Is it worth using this on APUs?</div>
</div>
</blockquote>
<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
kernel says "Hey please free something up or I will start the
OOM-killer" it's something we can easily throw away.<br>
<br>
Not sure how many of those buffers we have, but marking everything
which is temporary with that flag is probably a good idea.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 11, 2022 at 5:58
PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>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?</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
Regarding the eviction pressure the buffers will be handled like any
other buffer, but instead of preserving the content it is just
discarded on eviction.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Do evictions deallocate the buffer, or do they keep an
allocation in GTT and only the copy is skipped?</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
It really deallocates the backing store of the buffer, just keeps 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 bit
more efficient, but even using the dummy page array should only have
a few bytes overhead.<br>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 11, 2022 at
3:08 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>OK that sounds good.</div>
<div><br>
</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 11, 2022
at 2:04 AM Christian König <<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> Hi Marek,<br>
<br>
<div>Am 10.05.22 um 22:43 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>A better flag name would be:</div>
<div>AMDGPU_GEM_CREATE_BEST_PLACEMENT_OR_DISCARD</div>
</div>
</blockquote>
<br>
A bit long for my taste and I think the best
placement is just a side effect.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, May
10, 2022 at 4:13 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Does this really guarantee VRAM
placement? The code doesn't say anything
about that.</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
Yes, see the code here:<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> diff
--git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
index 8b7ee1142d9a..1944ef37a61e 100644<br>
---
a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
+++
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
@@ -567,6 +567,7 @@ int
amdgpu_bo_create(struct amdgpu_device
*adev,<br>
bp->domain;<br>
bo->allowed_domains =
bo->preferred_domains;<br>
if (bp->type !=
ttm_bo_type_kernel &&<br>
+ !(bp->flags &
AMDGPU_GEM_CREATE_DISCARDABLE) &&<br>
bo->allowed_domains ==
AMDGPU_GEM_DOMAIN_VRAM)<br>
bo->allowed_domains |=
AMDGPU_GEM_DOMAIN_GTT;<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
The only case where this could be circumvented is
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
request 64 MiB, then the GEM code will catch the
error and fallback to GTT (IIRC).<br>
<br>
Regards,<br>
Christian.<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>