From: Jay Cornwall <jay.cornwall@amd.com>
To: Lancelot SIX <Lancelot.Six@amd.com>, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amdkfd: gfx12 context save/restore trap handler fixes
Date: Thu, 23 May 2024 14:31:31 -0500 [thread overview]
Message-ID: <4f0a5ff8-ba6b-4db0-8e61-4e8a3b74fcc7@amd.com> (raw)
In-Reply-To: <6572dc07-fa47-412c-9ad3-ace0c3914cc5@amd.com>
On 5/23/2024 13:37, Lancelot SIX wrote:
>> @@ -622,8 +638,15 @@ L_SAVE_HWREG:
>> #if ASIC_FAMILY >= CHIP_GFX12
>> // Ensure no further changes to barrier or LDS state.
>> + // STATE_PRIV.BARRIER_COMPLETE may change up to this point.
>> s_barrier_signal -2
>> s_barrier_wait -2
>> +
>> + // Re-read final state of BARRIER_COMPLETE field for save.
>> + s_getreg_b32 s_save_tmp, hwreg(S_STATUS_HWREG)
>> + s_and_b32 s_save_tmp, s_save_tmp,
>> SQ_WAVE_STATE_PRIV_BARRIER_COMPLETE_MASK
>> + s_andn2_b32 s_save_status, s_save_status,
>> SQ_WAVE_STATE_PRIV_BARRIER_COMPLETE_MASK
>
> Even if BARRIER_COMPLETE can be asserted while we are in the trap
> hadler, I do not think it can be cleared. That being said, it might be
> easier to just replace the bit, making it clearer.
Yes, I chose to structure it this way to make the intent clearer. We
don't gain much from dropping the s_andn2. Most of the time spent in the
save handler is stalled on memory instructions.
>> @@ -1351,7 +1369,17 @@ L_SKIP_BARRIER_RESTORE:
>> s_setreg_b32 hwreg(HW_REG_SHADER_XNACK_MASK),
>> s_restore_xnack_mask
>> #endif
>> +#if ASIC_FAMILY < CHIP_GFX12
>> s_setreg_b32 hwreg(S_TRAPSTS_HWREG), s_restore_trapsts
>
> Wouldn't other gfx1x architectures have a similar issue when writing
> TRAPSTS here? That is if TRAPSTS.SAVECTX is set while we are restoring,
> wouldn't we loose it?
>
> And for gfx11, there is TRAPSTS.HOST_TRAP that could have the same issue
> to some degree (not sure if we would loose the host trap completly, or
> re-enter with trap ID + HT bit set in ttmp1).
Prior to gfx12 context save and host trap exceptions are not delivered
to a wave until STATUS.PRIV=0, i.e. it leaves the trap handler.
The changes needed for gfx12 are due to a design change in this area.
Exceptions are now flagged immediately and cause re-entry to the trap if
any are non-zero.
next prev parent reply other threads:[~2024-05-23 19:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 14:08 [PATCH 1/3] drm/amdkfd: Sync trap handler binary with source Jay Cornwall
2024-05-23 14:08 ` [PATCH 2/3] drm/amdkfd: Replace deprecated gfx12 trap handler instructions Jay Cornwall
2024-05-23 18:43 ` Lancelot SIX
2024-05-23 14:08 ` [PATCH 3/3] drm/amdkfd: gfx12 context save/restore trap handler fixes Jay Cornwall
2024-05-23 18:37 ` Lancelot SIX
2024-05-23 19:31 ` Jay Cornwall [this message]
2024-05-23 20:41 ` Lancelot SIX
2024-05-23 18:27 ` [PATCH 1/3] drm/amdkfd: Sync trap handler binary with source Alex Deucher
2024-05-23 18:41 ` Lancelot SIX
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=4f0a5ff8-ba6b-4db0-8e61-4e8a3b74fcc7@amd.com \
--to=jay.cornwall@amd.com \
--cc=Lancelot.Six@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