mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Pierre-Eric Pelloux-Prayer <pierre-eric@damsy.net>,
	Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Sumit Semwal <sumit.semwal@linaro.org>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v1 11/20] drm/amdgpu: use multiple entities in amdgpu_fill_buffer
Date: Wed, 5 Nov 2025 14:03:04 +0100	[thread overview]
Message-ID: <29c2e42d-6d94-4462-9302-af71f489a928@amd.com> (raw)
In-Reply-To: <7395bf47-68fd-4af6-8720-e51dc75253bc@damsy.net>

On 11/5/25 11:39, Pierre-Eric Pelloux-Prayer wrote:
> Le 04/11/2025 à 17:40, Christian König a écrit :
>> On 11/4/25 09:35, Pierre-Eric Pelloux-Prayer wrote:
>>> The benefits of using multiple entities is that multiple fill jobs
>>> can run in parallel. Otherwise, even if the entity has access
>>> to multiple engines, a burst of N independent jobs will all
>>> run on the same engine because an entity guarantees the ordering
>>> of execution matches the ordering of the submission.
>>>
>>> Callers can opt-out of this behavior by passing the entity they
>>> want to use (see amdgpu_move_blit).
>>
>> That still sounds like a really bad idea to me.
>>
>> First of all we can't reserve so many fence slots in the release handler, previously we basically just relied on the fact that the BO will most likely be mostly idle.
>>
>> I think we should just use a single SDMA engine for each clear and distribute clearing different BOs over multiple engines.
> 
> So N clear entities, each one having access to a single engine. And all jobs to clear a single BO go to the same entity?
> 
> Is that what you mean?

More or less.

N clear entities, each one has access to all engines. When a BO needs to be cleared it picks the next best entity and submits the jobs.

This way clear entities still load balance with moves and page table updates but we can keep the clearing logic simple.

Christian.

> 
> Pierre-Eric
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 84 ++++++++++++++++++-------
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 +
>>>   2 files changed, 64 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> index c357a6d9763a..839ea8c7f6be 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> @@ -2224,6 +2224,7 @@ u32 amdgpu_ttm_set_buffer_funcs_status(struct amdgpu_device *adev, bool enable)
>>>           adev->mman.clear_entities = kcalloc(num_clear_entities,
>>>                               sizeof(struct amdgpu_ttm_entity),
>>>                               GFP_KERNEL);
>>> +        atomic_set(&adev->mman.next_clear_entity, 0);
>>>           if (!adev->mman.clear_entities)
>>>               goto error_free_entity;
>>>   @@ -2498,10 +2499,12 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity,
>>>   {
>>>       struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>>       struct amdgpu_ring *ring = adev->mman.buffer_funcs_ring;
>>> +    struct dma_fence *fences[TTM_FENCES_MAX_SLOT_COUNT] = {};
>>>       struct dma_fence *fence = NULL;
>>>       struct dma_resv *resv = NULL;
>>>       struct amdgpu_res_cursor dst;
>>> -    int r;
>>> +    uint64_t cur_size, to;
>>> +    int r, e, n_fences;
>>>         /* The fences will be either added to the resv object or the last fence
>>>        * will be returned to the caller. In the latter case, all fill jobs will
>>> @@ -2515,53 +2518,92 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity,
>>>       }
>>>         if (!entity) {
>>> -        entity = &adev->mman.clear_entities[0];
>>>           resv = &bo->tbo.base._resv;
>>> -        r = dma_resv_reserve_fences(resv, 1);
>>> +
>>> +        /* Determine how much fences we're going to add to the
>>> +         * resv object.
>>> +         */
>>> +        n_fences = 0;
>>> +        amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst);
>>> +        while (dst.remaining) {
>>> +            cur_size = min(dst.size, 256ULL << 20);
>>> +
>>> +            n_fences += 1;
>>> +            amdgpu_res_next(&dst, cur_size);
>>> +        }
>>> +        if (n_fences == 0)
>>> +            return 0;
>>> +
>>> +        /* One slot per entity at most. */
>>> +        n_fences = MIN(n_fences, adev->mman.num_clear_entities);
>>> +
>>> +        r = dma_resv_reserve_fences(resv, n_fences);
>>>           if (r)
>>>               return r;
>>> +    } else {
>>> +        mutex_lock(&entity->gart_window_lock);
>>>       }
>>>         amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst);
>>>   -    mutex_lock(&entity->gart_window_lock);
>>>       while (dst.remaining) {
>>> -        struct dma_fence *next;
>>> -        uint64_t cur_size, to;
>>> -
>>>           /* Never fill more than 256MiB at once to avoid timeouts */
>>>           cur_size = min(dst.size, 256ULL << 20);
>>>   +        if (resv) {
>>> +            /* Pick a new entity for each partial clear so they can
>>> +             * execute in parallel.
>>> +             */
>>> +            e = atomic_inc_return(&adev->mman.next_clear_entity) %
>>> +                adev->mman.num_clear_entities;
>>> +            entity = &adev->mman.clear_entities[e];
>>> +            mutex_lock(&entity->gart_window_lock);
>>> +        }
>>> +
>>>           r = amdgpu_ttm_map_buffer(&entity->base,
>>>                         &bo->tbo, bo->tbo.resource, &dst,
>>>                         entity->gart_window_id1, ring, false,
>>>                         &cur_size, &to,
>>>                         dependency,
>>>                         resv);
>>> -        if (r)
>>> +        if (r) {
>>> +            mutex_unlock(&entity->gart_window_lock);
>>>               goto error;
>>> +        }
>>>             r = amdgpu_ttm_fill_mem(ring, &entity->base,
>>>                       src_data, to, cur_size, resv,
>>> -                    &next, true, k_job_id);
>>> -        if (r)
>>> +                    &fence, true, k_job_id);
>>> +        if (r) {
>>> +            mutex_unlock(&entity->gart_window_lock);
>>>               goto error;
>>> -
>>> -        if (resv) {
>>> -            dma_resv_add_fence(resv, next, DMA_RESV_USAGE_KERNEL);
>>> -            dma_fence_put(next);
>>> -        } else {
>>> -            dma_fence_put(fence);
>>> -            fence = next;
>>>           }
>>>             amdgpu_res_next(&dst, cur_size);
>>> +
>>> +        if (resv) {
>>> +            /* Delay the addition of the fences to resv, otherwise the next partial
>>> +             * clears will depend on this one.
>>> +             */
>>> +            fences[e] = fence;
>>> +            mutex_unlock(&entity->gart_window_lock);
>>> +        } else {
>>> +            dma_fence_put(*f);
>>> +            *f = fence;
>>> +        }
>>>       }
>>>   error:
>>> -    mutex_unlock(&entity->gart_window_lock);
>>> -    if (f)
>>> -        *f = dma_fence_get(fence);
>>> -    dma_fence_put(fence);
>>> +    if (resv) {
>>> +        for (e = 0; e < adev->mman.num_clear_entities; e++) {
>>> +            if (fences[e]) {
>>> +                dma_resv_add_fence(resv, fences[e], DMA_RESV_USAGE_KERNEL);
>>> +                dma_fence_put(fences[e]);
>>> +            }
>>> +        }
>>> +    } else {
>>> +        mutex_unlock(&entity->gart_window_lock);
>>> +    }
>>> +
>>>       return r;
>>>   }
>>>   diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
>>> index 38df2b5b4bc7..3fc31c7c6bfe 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
>>> @@ -73,6 +73,7 @@ struct amdgpu_mman {
>>>         struct amdgpu_ttm_entity default_entity; /* has no gart windows */
>>>       struct amdgpu_ttm_entity *clear_entities;
>>> +    atomic_t next_clear_entity;
>>>       u32 num_clear_entities;
>>>       struct amdgpu_ttm_entity move_entities[TTM_FENCES_MAX_SLOT_COUNT];
>>>       u32 num_move_entities;


  reply	other threads:[~2025-11-05 13:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04  8:35 [PATCH v1 00/20] drm/amdgpu: use all SDMA instances for TTM clears and moves Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 01/20] drm/amdgpu: give each kernel job a unique id Pierre-Eric Pelloux-Prayer
2025-11-04 13:58   ` Christian König
2025-11-04  8:35 ` [PATCH v1 02/20] drm/ttm: rework pipelined eviction fence handling Pierre-Eric Pelloux-Prayer
2025-11-04 14:12   ` Christian König
2025-11-05 10:34     ` Pierre-Eric Pelloux-Prayer
2025-11-05 13:00       ` Christian König
2025-11-04  8:35 ` [PATCH v1 03/20] drm/amdgpu: remove direct_submit arg from amdgpu_copy_buffer Pierre-Eric Pelloux-Prayer
2025-11-04 14:13   ` Christian König
2025-11-04  8:35 ` [PATCH v1 04/20] drm/amdgpu: introduce amdgpu_ttm_entity Pierre-Eric Pelloux-Prayer
2025-11-04 15:13   ` Christian König
2025-11-04  8:35 ` [PATCH v1 05/20] drm/amdgpu: pass the entity to use to ttm functions Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 06/20] drm/amdgpu: statically assign gart windows to ttm entities Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 07/20] drm/amdgpu: allocate multiple clear entities Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 08/20] drm/amdgpu: allocate multiple move entities Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 09/20] drm/amdgpu: pass optional dependency to amdgpu_fill_buffer Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 10/20] drm/amdgpu: prepare amdgpu_fill_buffer to use N entities Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 11/20] drm/amdgpu: use multiple entities in amdgpu_fill_buffer Pierre-Eric Pelloux-Prayer
2025-11-04 16:40   ` Christian König
2025-11-05 10:39     ` Pierre-Eric Pelloux-Prayer
2025-11-05 13:03       ` Christian König [this message]
2025-11-12 10:39         ` Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 12/20] drm/amdgpu: use TTM_FENCES_MAX_SLOT_COUNT Pierre-Eric Pelloux-Prayer
2025-11-05  8:36   ` Christian König
2025-11-04  8:35 ` [PATCH v1 13/20] drm/amdgpu: use multiple entities in amdgpu_move_blit Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 14/20] drm/amdgpu: pass all the sdma rings to amdgpu_mman Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 15/20] drm/amdgpu: introduce amdgpu_sdma_set_vm_pte_scheds Pierre-Eric Pelloux-Prayer
2025-11-05  8:41   ` Christian König
2025-11-04  8:35 ` [PATCH v1 16/20] drm/amdgpu: give ttm entities access to all the sdma scheds Pierre-Eric Pelloux-Prayer
2025-11-05  8:45   ` Christian König
2025-11-05 10:17     ` Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 17/20] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer Pierre-Eric Pelloux-Prayer
2025-11-05  8:46   ` Christian König
2025-11-05  9:30     ` Pierre-Eric Pelloux-Prayer
2025-11-05 10:07       ` Christian König
2025-11-04  8:35 ` [PATCH v1 18/20] drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_clear_buffer Pierre-Eric Pelloux-Prayer
2025-11-05  8:47   ` Christian König
2025-11-04  8:35 ` [PATCH v1 19/20] drm/amdgpu: use larger gart window when possible Pierre-Eric Pelloux-Prayer
2025-11-04  8:35 ` [PATCH v1 20/20] drm/amdgpu: double AMDGPU_GTT_MAX_TRANSFER_SIZE Pierre-Eric Pelloux-Prayer
2025-11-04 13:56   ` Christian König

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=29c2e42d-6d94-4462-9302-af71f489a928@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=pierre-eric.pelloux-prayer@amd.com \
    --cc=pierre-eric@damsy.net \
    --cc=simona@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®