From: "Christian König" <christian.koenig@amd.com>
To: Alex Deucher <alexander.deucher@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>,
lin cao <lin.cao@amd.com>, Jingwen Chen <Jingwen.Chen2@amd.com>,
Shaoyun Liu <shaoyun.liu@amd.com>
Subject: Re: [PATCH V3 2/2] drm/amdgpu/mes: Add cleaner shader fence address handling in MES for GFX11
Date: Fri, 7 Feb 2025 15:50:44 +0100 [thread overview]
Message-ID: <2ca96297-db0f-4683-a46f-9621ea4bd60c@amd.com> (raw)
In-Reply-To: <20250207144352.920100-2-alexander.deucher@amd.com>
Am 07.02.25 um 15:43 schrieb Alex Deucher:
> From: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
>
> This commit introduces enhancements to the handling of the cleaner
> shader fence in the AMDGPU MES driver:
>
> - The MES (Microcode Execution Scheduler) now sends a PM4 packet to the
> KIQ (Kernel Interface Queue) to request the cleaner shader, ensuring
> that requests are handled in a controlled manner and avoiding the
> race conditions.
> - The CP (Compute Processor) firmware has been updated to use a private
> bus for accessing specific registers, avoiding unnecessary operations
> that could lead to issues in VF (Virtual Function) mode.
> - The cleaner shader fence memory address is now set correctly in the
> `mes_set_hw_res_pkt` structure, allowing for proper synchronization of
> the cleaner shader execution. This is done by calculating the address
> using the write-back memory base address and the cleaner fence offset.
>
> Cc: lin cao <lin.cao@amd.com>
> Cc: Jingwen Chen <Jingwen.Chen2@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Suggested-by: Shaoyun Liu <shaoyun.liu@amd.com>
> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Yeah that makes much more sense.
I'm really wondering why the MES hasn't allocated that in it's own
memory in the first place?
Does the MES expect the kernel driver to wait for that fence value?
Anyway Reviewed-by: Christian König <christian.koenig@amd.com> for now.
Regards,
Christian.
> ---
> drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> index e862a3febe2b2..e22d0ee6d8a3a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> @@ -754,7 +754,7 @@ static int mes_v11_0_set_hw_resources_1(struct amdgpu_mes *mes)
> mes_set_hw_res_pkt.header.dwsize = API_FRAME_SIZE_IN_DWORDS;
> mes_set_hw_res_pkt.enable_mes_info_ctx = 1;
>
> - ret = amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
> + ret = amdgpu_bo_create_kernel(adev, size + AMDGPU_GPU_PAGE_SIZE, PAGE_SIZE,
> AMDGPU_GEM_DOMAIN_VRAM,
> &mes->resource_1,
> &mes->resource_1_gpu_addr,
> @@ -765,7 +765,10 @@ static int mes_v11_0_set_hw_resources_1(struct amdgpu_mes *mes)
> }
>
> mes_set_hw_res_pkt.mes_info_ctx_mc_addr = mes->resource_1_gpu_addr;
> - mes_set_hw_res_pkt.mes_info_ctx_size = mes->resource_1->tbo.base.size;
> + mes_set_hw_res_pkt.mes_info_ctx_size = size;
> + mes_set_hw_res_pkt.cleaner_shader_fence_mc_addr =
> + mes->resource_1_gpu_addr + size;
> +
> return mes_v11_0_submit_pkt_and_poll_completion(mes,
> &mes_set_hw_res_pkt, sizeof(mes_set_hw_res_pkt),
> offsetof(union MESAPI_SET_HW_RESOURCES_1, api_status));
> @@ -1632,12 +1635,10 @@ static int mes_v11_0_hw_init(struct amdgpu_ip_block *ip_block)
> if (r)
> goto failure;
>
> - if (amdgpu_sriov_is_mes_info_enable(adev)) {
> - r = mes_v11_0_set_hw_resources_1(&adev->mes);
> - if (r) {
> - DRM_ERROR("failed mes_v11_0_set_hw_resources_1, r=%d\n", r);
> - goto failure;
> - }
> + r = mes_v11_0_set_hw_resources_1(&adev->mes);
> + if (r) {
> + DRM_ERROR("failed mes_v11_0_set_hw_resources_1, r=%d\n", r);
> + goto failure;
> }
>
> r = mes_v11_0_query_sched_status(&adev->mes);
> @@ -1665,10 +1666,9 @@ static int mes_v11_0_hw_init(struct amdgpu_ip_block *ip_block)
> static int mes_v11_0_hw_fini(struct amdgpu_ip_block *ip_block)
> {
> struct amdgpu_device *adev = ip_block->adev;
> - if (amdgpu_sriov_is_mes_info_enable(adev)) {
> - amdgpu_bo_free_kernel(&adev->mes.resource_1, &adev->mes.resource_1_gpu_addr,
> - &adev->mes.resource_1_addr);
> - }
> +
> + amdgpu_bo_free_kernel(&adev->mes.resource_1, &adev->mes.resource_1_gpu_addr,
> + &adev->mes.resource_1_addr);
> return 0;
> }
>
next prev parent reply other threads:[~2025-02-07 14:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 14:43 [PATCH 1/2] drm/amdgpu/mes11: fix set_hw_resources_1 calculation Alex Deucher
2025-02-07 14:43 ` [PATCH V3 2/2] drm/amdgpu/mes: Add cleaner shader fence address handling in MES for GFX11 Alex Deucher
2025-02-07 14:50 ` Christian König [this message]
2025-02-07 15:23 ` Liu, Shaoyun
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=2ca96297-db0f-4683-a46f-9621ea4bd60c@amd.com \
--to=christian.koenig@amd.com \
--cc=Jingwen.Chen2@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=lin.cao@amd.com \
--cc=shaoyun.liu@amd.com \
--cc=srinivasan.shanmugam@amd.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.