From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Matthew Brost" <matthew.brost@intel.com>,
"Christian König" <christian.koenig@amd.com>
Cc: Friedrich Vock <friedrich.vock@gmx.de>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
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 02/18] drm/ttm: Add per-BO eviction tracking
Date: Fri, 26 Apr 2024 08:27:13 +0200 [thread overview]
Message-ID: <8eecba49-52a2-465c-88e4-60722299a724@gmail.com> (raw)
In-Reply-To: <Ziqo10vFfhVGQO6h@DUT025-TGLU.fm.intel.com>
Am 25.04.24 um 21:02 schrieb Matthew Brost:
> On Thu, Apr 25, 2024 at 08:18:38AM +0200, Christian König wrote:
>> Am 24.04.24 um 18:56 schrieb Friedrich Vock:
>>> Make each buffer object aware of whether it has been evicted or not.
>> That reverts some changes we made a couple of years ago.
>>
>> In general the idea is that eviction isn't something we need to reverse in
>> TTM.
>>
>> Rather the driver gives the desired placement.
>>
>> Regards,
>> Christian.
>>
> We have added a concept similar to this in drm_gpuvm [1]. GPUVM
> maintains a list of evicted BOs and when the GPUVM is locked for
> submission it has validate vfunc which is called on each BO. If driver
> is using TTM, this is where the driver would call TTM BO validate which
> unevicts the BO. Well at least this what we do it Xe [2].
>
> The uneviction is a per VM operation not a global one. With this, a
> global eviction list does not seem correct (admittedly not through the
> entire series).
Yeah, that's exactly what I meant when I wrote that this is controlled
by the "driver" :)
The state machine in AMDGPUs VM code is pretty much the same.
Regards,
Christian.
>
> Matt
>
> [1] https://elixir.bootlin.com/linux/v6.8.7/source/drivers/gpu/drm/drm_gpuvm.c#L86
> [2] https://elixir.bootlin.com/linux/v6.8.7/source/drivers/gpu/drm/xe/xe_vm.c#L464
>
>>> Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>>> include/drm/ttm/ttm_bo.h | 11 +++++++++++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index edf10618fe2b2..3968b17453569 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -980,6 +980,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, struct ttm_buffer_object *bo,
>>> bo->pin_count = 0;
>>> bo->sg = sg;
>>> bo->bulk_move = NULL;
>>> + bo->evicted_type = TTM_NUM_MEM_TYPES;
>>> if (resv)
>>> bo->base.resv = resv;
>>> else
>>> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
>>> index 0223a41a64b24..8a1a29c6fbc50 100644
>>> --- a/include/drm/ttm/ttm_bo.h
>>> +++ b/include/drm/ttm/ttm_bo.h
>>> @@ -121,6 +121,17 @@ struct ttm_buffer_object {
>>> unsigned priority;
>>> unsigned pin_count;
>>>
>>> + /**
>>> + * @evicted_type: Memory type this BO was evicted from, if any.
>>> + * TTM_NUM_MEM_TYPES if this BO was not evicted.
>>> + */
>>> + int evicted_type;
>>> + /**
>>> + * @evicted: Entry in the evicted list for the resource manager
>>> + * this BO was evicted from.
>>> + */
>>> + struct list_head evicted;
>>> +
>>> /**
>>> * @delayed_delete: Work item used when we can't delete the BO
>>> * immediately
>>> --
>>> 2.44.0
>>>
next prev parent reply other threads:[~2024-04-26 6:27 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 [this message]
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
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=8eecba49-52a2-465c-88e4-60722299a724@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bas@basnieuwenhuizen.nl \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=friedrich.vock@gmx.de \
--cc=joshua@froggi.es \
--cc=matthew.brost@intel.com \
--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.