[RFC] drm/amdgpu: More efficient ring padding
Christian König
ckoenig.leichtzumerken at gmail.com
Fri Jul 12 07:33:07 UTC 2024
Am 11.07.24 um 20:17 schrieb Tvrtko Ursulin:
> From: Tvrtko Ursulin <tvrtko.ursulin at igalia.com>
>
> From the department of questionable optimisations today we have a minor
> improvement to how padding / filling the rings with nops is done.
>
> Having noticed that typically 200+ nops per submission are filled into the
> ring, using a rather verbose one-nop-at-a-time-plus-ring-buffer-arithmetic
> as done in amdgpu_ring_write(), while right next to it there is
> amdgpu_ring_write_multiple(), I thought why not pre-cache a block of nops
> and write them out more efficiently.
>
> The patch is rather quick and dirty, does not deal with all insert_nops
> vfuncs, and the cache should probably go one level up so it is not
> replicated per amdgpu_ring instance.
Why should that be more effective? We essentially use more cache lines
than before.
> And performance gains are not that amazing for normal workloads. For
> instance a game which results in two submissions per frame, each pads
> with 222 nops, submission worker thread profile changes from:
Mhm, why the heck are we using so many nops in the first place?
Regards,
Christian.
>
> + 90.78% 0.67% kworker/u32:3-e [kernel.kallsyms] [k] process_one_work
> + 48.92% 0.12% kworker/u32:3-e [kernel.kallsyms] [k] commit_tail
> + 41.18% 1.73% kworker/u32:3-e [kernel.kallsyms] [k] amdgpu_dm_atomic_commit_tail
> - 30.31% 0.67% kworker/u32:3-e [kernel.kallsyms] [k] drm_sched_run_job_work
> - 29.63% drm_sched_run_job_work
> + 8.55% dma_fence_add_callback
> - 7.50% amdgpu_job_run
> - 7.43% amdgpu_ib_schedule
> - 2.46% amdgpu_ring_commit
> 1.44% amdgpu_ring_insert_nop
>
> To:
>
> + 89.83% 0.51% kworker/u32:6-g [kernel.kallsyms] [k] process_one_work
> + 47.65% 0.30% kworker/u32:6-g [kernel.kallsyms] [k] commit_tail
> + 39.42% 1.97% kworker/u32:6-g [kernel.kallsyms] [k] amdgpu_dm_atomic_commit_tail
> - 29.57% 1.10% kworker/u32:6-g [kernel.kallsyms] [k] drm_sched_run_job_work
> - 28.47% drm_sched_run_job_work
> + 8.52% dma_fence_add_callback
> - 6.33% amdgpu_job_run
> - 6.19% amdgpu_ib_schedule
> - 1.85% amdgpu_ring_commit
> 0.53% amdgpu_ring_insert_nop
>
> Or if we run a more "spammy" workload, which does several orders of
> magnitude more submissions second we go from:
>
> + 79.38% 1.66% kworker/u32:1+e [kernel.kallsyms] [k] process_one_work
> - 63.13% 6.66% kworker/u32:1+e [kernel.kallsyms] [k] drm_sched_run_job_work
> - 56.47% drm_sched_run_job_work
> - 25.67% amdgpu_job_run
> - 24.40% amdgpu_ib_schedule
> - 15.29% amdgpu_ring_commit
> 12.06% amdgpu_ring_insert_nop
>
> To:
>
> + 77.76% 1.97% kworker/u32:6-f [kernel.kallsyms] [k] process_one_work
> - 60.15% 7.04% kworker/u32:6-f [kernel.kallsyms] [k] drm_sched_run_job_work
> - 53.11% drm_sched_run_job_work
> - 19.35% amdgpu_job_run
> - 17.85% amdgpu_ib_schedule
> - 7.75% amdgpu_ring_commit
> 3.27% amdgpu_ring_insert_nop
>
> Not bad and "every little helps", or flame-throwers at ready?
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at igalia.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 20 +++++++++++++++-----
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> index ad49cecb20b8..22ec9de62b06 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> @@ -108,10 +108,14 @@ int amdgpu_ring_alloc(struct amdgpu_ring *ring, unsigned int ndw)
> */
> void amdgpu_ring_insert_nop(struct amdgpu_ring *ring, uint32_t count)
> {
> - int i;
> + if (count > 1 && count <= ARRAY_SIZE(ring->nop_cache)) {
> + amdgpu_ring_write_multiple(ring, ring->nop_cache, count);
> + } else {
> + int i;
>
> - for (i = 0; i < count; i++)
> - amdgpu_ring_write(ring, ring->funcs->nop);
> + for (i = 0; i < count; i++)
> + amdgpu_ring_write(ring, ring->funcs->nop);
> + }
> }
>
> /**
> @@ -124,8 +128,11 @@ void amdgpu_ring_insert_nop(struct amdgpu_ring *ring, uint32_t count)
> */
> void amdgpu_ring_generic_pad_ib(struct amdgpu_ring *ring, struct amdgpu_ib *ib)
> {
> - while (ib->length_dw & ring->funcs->align_mask)
> - ib->ptr[ib->length_dw++] = ring->funcs->nop;
> + u32 count = ib->length_dw & ring->funcs->align_mask;
> +
> + memcpy(&ib->ptr[ib->length_dw], ring->nop_cache, count * sizeof(u32));
> +
> + ib->length_dw += count;
> }
>
> /**
> @@ -359,6 +366,9 @@ int amdgpu_ring_init(struct amdgpu_device *adev, struct amdgpu_ring *ring,
> &ring->sched;
> }
>
> + for (r = 0; r < ARRAY_SIZE(ring->nop_cache); r++)
> + ring->nop_cache[r] = ring->funcs->nop;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 582053f1cd56..74ce95b4666a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -246,6 +246,7 @@ struct amdgpu_ring {
> struct amdgpu_bo *ring_obj;
> volatile uint32_t *ring;
> unsigned rptr_offs;
> + u32 nop_cache[256];
> u64 rptr_gpu_addr;
> volatile u32 *rptr_cpu_addr;
> u64 wptr;
More information about the amd-gfx
mailing list