<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Well the best placement is guaranteed as long as the application
doesn't do any nonsense (e.g. trying to allocate a buffer larger
than available VRAM).<br>
<br>
The VM_ALWAYS_VALID flag doesn't affect any of that handling.<br>
<br>
Regards,<br>
Christian.<br>
<br>
<div class="moz-cite-prefix">Am 13.05.22 um 00:17 schrieb Marek
Olšák:<br>
</div>
<blockquote type="cite"
cite="mid:CAAxE2A5jc0FhpnM2tBskS2puKY-jidC_xdMTZhQ5p9U31O_0KA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
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">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</blockquote>
<br>
</body>
</html>