From: "Christian König" <christian.koenig@amd.com>
To: Friedrich Vock <friedrich.vock@gmx.de>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Cc: Pierre-Loup Griffais <pgriffais@valvesoftware.com>,
Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>,
Joshua Ashton <joshua@froggi.es>,
Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [RFC PATCH 10/18] drm/amdgpu: Don't add GTT to initial domains after failing to allocate VRAM
Date: Thu, 25 Apr 2024 09:54:15 +0200 [thread overview]
Message-ID: <a5a3e5c6-b7fe-4f66-ace3-d6f90f8427ef@amd.com> (raw)
In-Reply-To: <716004ab-8893-4ef1-8492-00ea64da3646@gmx.de>
Am 25.04.24 um 09:39 schrieb Friedrich Vock:
> On 25.04.24 08:25, Christian König wrote:
>> Am 24.04.24 um 18:57 schrieb Friedrich Vock:
>>> This adds GTT to the "preferred domains" of this buffer object, which
>>> will also prevent any attempts at moving the buffer back to VRAM if
>>> there is space. If VRAM is full, GTT will already be chosen as a
>>> fallback.
>>
>> Big NAK to that one, this is mandatory for correct operation.
>>
> Hm, how is correctness affected here? We still fall back to GTT if
> allocating in VRAM doesn't work, I don't see a difference except that
> now we'll actually try moving it back into VRAM again.
Well this is the fallback. Only during CS we try to allocate from GTT if
allocating in VRAM doesn't work.
When you remove this here then any failed allocation from VRAM would be
fatal.
What could be is that the handling is buggy and when we update the
initial domain we also add GTT to the preferred domain, but that should
then be fixed.
Regards,
Christian.
>
> Regards,
> Friedrich
>
>> Regards,
>> Christian.
>>
>>>
>>> Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ----
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
>>> 2 files changed, 1 insertion(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index 6bbab141eaaeb..aea3770d3ea2e 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -378,10 +378,6 @@ int amdgpu_gem_create_ioctl(struct drm_device
>>> *dev, void *data,
>>> goto retry;
>>> }
>>>
>>> - if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
>>> - initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
>>> - goto retry;
>>> - }
>>> DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu,
>>> %d)\n",
>>> size, initial_domain, args->in.alignment, r);
>>> }
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> index 85c10d8086188..9978b85ed6f40 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> @@ -619,7 +619,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
>>> AMDGPU_GEM_DOMAIN_GDS))
>>> amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
>>> else
>>> - amdgpu_bo_placement_from_domain(bo, bp->domain);
>>> + amdgpu_bo_placement_from_domain(bo, bo->allowed_domains);
>>> if (bp->type == ttm_bo_type_kernel)
>>> bo->tbo.priority = 2;
>>> else if (!(bp->flags & AMDGPU_GEM_CREATE_DISCARDABLE))
>>> --
>>> 2.44.0
>>>
>>
next prev parent reply other threads:[~2024-04-25 7:54 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 16:56 [RFC PATCH 00/18] TTM interface for managing VRAM oversubscription Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 01/18] drm/ttm: Add tracking for evicted memory Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 02/18] drm/ttm: Add per-BO eviction tracking Friedrich Vock
2024-04-25 6:18 ` Christian König
2024-04-25 19:02 ` Matthew Brost
2024-04-26 6:27 ` Christian König
2024-04-24 16:56 ` [RFC PATCH 03/18] drm/ttm: Implement BO " Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 04/18] drm/ttm: Add driver funcs for uneviction control Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 05/18] drm/ttm: Add option to evict no BOs in operation Friedrich Vock
2024-04-25 6:20 ` Christian König
2024-04-24 16:56 ` [RFC PATCH 06/18] drm/ttm: Add public buffer eviction/uneviction functions Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 07/18] drm/amdgpu: Add TTM uneviction control functions Friedrich Vock
2024-04-24 16:56 ` [RFC PATCH 08/18] drm/amdgpu: Don't try moving BOs to preferred domain before submit Friedrich Vock
2024-04-25 6:36 ` Christian König
2024-04-24 16:56 ` [RFC PATCH 09/18] drm/amdgpu: Don't mark VRAM as a busy placement for VRAM|GTT resources Friedrich Vock
2024-04-25 6:24 ` Christian König
2024-04-24 16:57 ` [RFC PATCH 10/18] drm/amdgpu: Don't add GTT to initial domains after failing to allocate VRAM Friedrich Vock
2024-04-25 6:25 ` Christian König
2024-04-25 7:39 ` Friedrich Vock
2024-04-25 7:54 ` Christian König [this message]
2024-04-24 16:57 ` [RFC PATCH 11/18] drm/ttm: Bump BO priority count Friedrich Vock
2024-04-24 16:57 ` [RFC PATCH 12/18] drm/ttm: Do not evict BOs with higher priority Friedrich Vock
2024-04-25 6:26 ` Christian König
2024-04-24 16:57 ` [RFC PATCH 13/18] drm/ttm: Implement ttm_bo_update_priority Friedrich Vock
2024-04-25 6:29 ` Christian König
2024-04-24 16:57 ` [RFC PATCH 14/18] drm/ttm: Consider BOs placed in non-favorite locations evicted Friedrich Vock
2024-04-24 16:57 ` [RFC PATCH 15/18] drm/amdgpu: Set a default priority for user/kernel BOs Friedrich Vock
2024-04-24 16:57 ` [RFC PATCH 16/18] drm/amdgpu: Implement SET_PRIORITY GEM op Friedrich Vock
2024-04-25 6:32 ` Christian König
2024-04-25 6:46 ` Friedrich Vock
2024-04-25 6:58 ` Christian König
2024-04-25 7:06 ` Friedrich Vock
2024-04-25 7:15 ` Christian König
2024-04-25 7:39 ` Friedrich Vock
2024-04-24 16:57 ` [RFC PATCH 17/18] drm/amdgpu: Implement EVICTED_VRAM query Friedrich Vock
2024-04-24 16:57 ` [RFC PATCH 18/18] drm/amdgpu: Bump minor version Friedrich Vock
2024-04-25 6:54 ` [RFC PATCH 00/18] TTM interface for managing VRAM oversubscription Christian König
2024-04-25 13:22 ` Marek Olšák
2024-04-25 13:33 ` Christian König
2024-05-02 14:23 ` Maarten Lankhorst
2024-05-13 13:44 ` Friedrich Vock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a5a3e5c6-b7fe-4f66-ace3-d6f90f8427ef@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bas@basnieuwenhuizen.nl \
--cc=dri-devel@lists.freedesktop.org \
--cc=friedrich.vock@gmx.de \
--cc=joshua@froggi.es \
--cc=pgriffais@valvesoftware.com \
--cc=tvrtko.ursulin@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.