Am 12.05.22 um 00:06 schrieb Marek Olšák:
3rd question: Is it worth using this on APUs?
It makes memory management somewhat easier when we are
really OOM.
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.
Not sure how many of those buffers we have, but marking
everything which is temporary with that flag is probably a
good idea.
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?
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.
Do evictions deallocate the buffer, or do they
keep an allocation in GTT and only the copy is
skipped?
It really deallocates the backing store of the buffer, just
keeps a dummy page array around where all entries are NULL.
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.
Regards,
Christian.
OK that sounds good.
Marek
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.
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.