AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Huang <jinhuieric.huang@amd.com>
To: "Kim, Jonathan" <Jonathan.Kim@amd.com>,
	"Kuehling, Felix" <Felix.Kuehling@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdkfd: fix address watch clearing bug for gfx v9.4.2
Date: Thu, 10 Aug 2023 17:52:35 -0400	[thread overview]
Message-ID: <a6f589e3-4023-31eb-6df9-1118f48b39ed@amd.com> (raw)
In-Reply-To: <CY8PR12MB743551930E66E2C84AC089688513A@CY8PR12MB7435.namprd12.prod.outlook.com>

The problem is the queue is suspended before clearing address watch call 
in KFD, there is not queue preemption and queue resume after clearing 
call, and the test ends. So there is not chance to send MAP_PROCESS to 
HWS. At this point FW has nothing to do. We have several test FWs from 
Tej, none of them works, so I recalled the kernel debug log and found 
out the problem.

GFX11 has different scheduler, when calling clear address watch, KFD 
directly sends the MES_MISC_OP_SET_SHADER_DEBUGGER to MES, it doesn't 
consider if the queue is suspended. So GFX11 doesn't have this issue.

Regards,
Eric

On 2023-08-10 17:27, Kim, Jonathan wrote:
> [AMD Official Use Only - General]
>
> This is a strange solution because the MEC should set watch controls as non-valid automatically on queue preemption to avoid this kind of issue in the first place by design.  MAP_PROCESS on resume will take whatever the driver requests.
> GFX11 has no issue with letting the HWS do this.
>
> Are we sure we're not working around some HWS bug?
>
> Thanks,
>
> Jon
>
>> -----Original Message-----
>> From: Kuehling, Felix <Felix.Kuehling@amd.com>
>> Sent: Thursday, August 10, 2023 5:03 PM
>> To: Huang, JinHuiEric <JinHuiEric.Huang@amd.com>; amd-
>> gfx@lists.freedesktop.org
>> Cc: Kim, Jonathan <Jonathan.Kim@amd.com>
>> Subject: Re: [PATCH] drm/amdkfd: fix address watch clearing bug for gfx v9.4.2
>>
>> I think amdgpu_amdkfd_gc_9_4_3.c needs a similar fix. But maybe a bit
>> different because it needs to support multiple XCCs.
>>
>> That said, this patch is
>>
>> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>
>>
>> On 2023-08-10 16:47, Eric Huang wrote:
>>> KFD currently relies on MEC FW to clear tcp watch control
>>> register by sending MAP_PROCESS packet with 0 of field
>>> tcp_watch_cntl to HWS, but if the queue is suspended, the
>>> packet will not be sent and the previous value will be
>>> left on the register, that will affect the following apps.
>>> So the solution is to clear the register as gfx v9 in KFD.
>>>
>>> Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
>>> ---
>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 8 +-------
>>>    1 file changed, 1 insertion(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
>>> index e2fed6edbdd0..aff08321e976 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
>>> @@ -163,12 +163,6 @@ static uint32_t
>> kgd_gfx_aldebaran_set_address_watch(
>>>      return watch_address_cntl;
>>>    }
>>>
>>> -static uint32_t kgd_gfx_aldebaran_clear_address_watch(struct
>> amdgpu_device *adev,
>>> -                                                 uint32_t watch_id)
>>> -{
>>> -   return 0;
>>> -}
>>> -
>>>    const struct kfd2kgd_calls aldebaran_kfd2kgd = {
>>>      .program_sh_mem_settings =
>> kgd_gfx_v9_program_sh_mem_settings,
>>>      .set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
>>> @@ -193,7 +187,7 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
>>>      .set_wave_launch_trap_override =
>> kgd_aldebaran_set_wave_launch_trap_override,
>>>      .set_wave_launch_mode = kgd_aldebaran_set_wave_launch_mode,
>>>      .set_address_watch = kgd_gfx_aldebaran_set_address_watch,
>>> -   .clear_address_watch = kgd_gfx_aldebaran_clear_address_watch,
>>> +   .clear_address_watch = kgd_gfx_v9_clear_address_watch,
>>>      .get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
>>>      .build_grace_period_packet_info =
>> kgd_gfx_v9_build_grace_period_packet_info,
>>>      .program_trap_handler_settings =
>> kgd_gfx_v9_program_trap_handler_settings,


  reply	other threads:[~2023-08-10 21:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 20:47 [PATCH] drm/amdkfd: fix address watch clearing bug for gfx v9.4.2 Eric Huang
2023-08-10 21:02 ` Felix Kuehling
2023-08-10 21:26   ` Eric Huang
2023-08-10 21:27   ` Kim, Jonathan
2023-08-10 21:52     ` Eric Huang [this message]
2023-08-10 21:56       ` Felix Kuehling
2023-08-10 22:25         ` Kim, Jonathan
2023-08-10 22:30           ` Eric Huang
2023-08-10 23:04             ` Kim, Jonathan
2023-08-10 22:27         ` Eric Huang
2023-08-11 13:26           ` Felix Kuehling
2023-08-11 14:07             ` Eric Huang

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=a6f589e3-4023-31eb-6df9-1118f48b39ed@amd.com \
    --to=jinhuieric.huang@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=Jonathan.Kim@amd.com \
    --cc=amd-gfx@lists.freedesktop.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