AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Timur Kristóf" <timur.kristof@gmail.com>
To: amd-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: kernel-dev@igalia.com,
	"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 2/3] drm/amdgpu: Save some cycles on the job submission path
Date: Fri, 26 Jun 2026 19:10:29 +0200	[thread overview]
Message-ID: <3694635.dWV9SEqChM@timur-max> (raw)
In-Reply-To: <20260626085558.97923-3-tvrtko.ursulin@igalia.com>

On 2026. június 26., péntek 10:55:57 közép-európai nyári idő Tvrtko Ursulin 
wrote:
> Every job submission on the Steam Deck ends up walking the list of IP
> blocks looking for AMD_IP_BLOCK_TYPE_SMC. Half of the call chain is like
> the below, while the second half is from amdgpu_gfx_profile_ring_end_use:
> 
>  amdgpu_gfx_profile_ring_begin_use
>   amdgpu_dpm_is_overdrive_enabled
>    is_support_sw_smu
>     amdgpu_device_ip_is_valid
> 
> On a game menu screen at 90Hz refresh rate we end up with ~840 calls per
> second which sticks out when the submission worker is profiled with perf:
> 
>   13.78%  [kernel]  [k] __lock_text_start
>   10.86%  [kernel]  [k] __lookup_object
>    8.76%  [kernel]  [k] __mod_timer
>    4.94%  [kernel]  [k] queued_spin_lock_slowpath
>    1.66%  [kernel]  [k] amdgpu_device_ip_is_valid
>    1.54%  [kernel]  [k] preempt_count_add
>    1.42%  [kernel]  [k] amdgpu_sync_peek_fence
>    1.18%  [kernel]  [k] amdgpu_vmid_grab
>    1.17%  [kernel]  [k] amdgpu_ib_schedule
>    1.14%  [kernel]  [k] kthread_worker_fn
> 
> Lets short-circuit this walk by simply caching the result of
> is_support_sw_smu() in the device.
> 
> This is a micro-improvement but it is at least conceptually nicer to avoid
> repeating the same walk so much.

Hi,

I agree with cleaning up this thing.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>

That being said, I think is_support_sw_smu() is horrible and should be removed 
alltogether, because it goes against how the rest of the power management code 
works.

In my opinion, we should instead:

1. Hook up some function pointers and check those instead,
For example in amdgpu_pm_acpi_event_handler() we should just hook up 
smu_set_ac_dc() to the notify_ac_dc() function pointer. There are plenty of 
other similar cases.
Another example, for amdgpu_dpm_mode1_reset() we should introduce a new 
asic_reset_mode_1() pointer in amd_pm_funcs() similar to how it works with 
MODE2 reset for consistency.

2. Eliminate redundant functions where the same thing is already done 
elsewhere.
For example in amdgpu_dpm_is_mode1_reset_supported() it checks 
smu_mode1_reset_is_support() which is redundant because the supported reset 
type is available on the ASIC functions already and we can just use that.

What do you think?

Thanks & best regards,
Timur

> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Timur Kristóf <timur.kristof@gmail.com>
> ---
> v2:
>  * Approach changed to cache sw_smu status only.
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h           |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c    |  3 +++
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c     | 14 +++++---------
>  drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  8 +++++++-
>  4 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 7b09410d6d8f..9803967d15f9
> 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -851,6 +851,7 @@ struct amdgpu_device {
>  	struct dev_pm_domain		vga_pm_domain;
>  	bool				have_disp_power_ref;
>  	bool                            have_atomics_support;
> +	bool				is_sw_smu;
> 
>  	/* BIOS */
>  	bool				is_atom_fw;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index
> 1e6b75ecafe4..7f935a5778b0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -74,6 +74,7 @@
>  #include "amdgpu_ras.h"
>  #include "amdgpu_ras_mgr.h"
>  #include "amdgpu_pmu.h"
> +#include "amdgpu_smu.h"
>  #include "amdgpu_fru_eeprom.h"
>  #include "amdgpu_reset.h"
>  #include "amdgpu_virt.h"
> @@ -2130,6 +2131,8 @@ static int amdgpu_device_ip_early_init(struct
> amdgpu_device *adev) adev->cg_flags &= amdgpu_cg_mask;
>  	adev->pg_flags &= amdgpu_pg_mask;
> 
> +	amdgpu_smu_early_init(adev);
> +
>  	return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c index
> 208a2fba6d40..82c9ae6a5092 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -591,17 +591,13 @@ static int smu_get_power_num_states(void *handle,
>  	return 0;
>  }
> 
> -bool is_support_sw_smu(struct amdgpu_device *adev)
> +void amdgpu_smu_early_init(struct amdgpu_device *adev)
>  {
>  	/* vega20 is 11.0.2, but it's supported via the powerplay code */
> -	if (adev->asic_type == CHIP_VEGA20)
> -		return false;
> -
> -	if ((amdgpu_ip_version(adev, MP1_HWIP, 0) >= IP_VERSION(11, 0, 0)) 
&&
> -	    amdgpu_device_ip_is_valid(adev, AMD_IP_BLOCK_TYPE_SMC))
> -		return true;
> -
> -	return false;
> +	adev->is_sw_smu = adev->asic_type != CHIP_VEGA20 &&
> +			  (amdgpu_ip_version(adev, MP1_HWIP, 0) >=
> +			   IP_VERSION(11, 0, 0) &&
> +			   amdgpu_device_ip_is_valid(adev, 
AMD_IP_BLOCK_TYPE_SMC));
>  }
> 
>  bool is_support_cclk_dpm(struct amdgpu_device *adev)
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h index
> d76e0b005308..efc52d97058b 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> @@ -1952,7 +1952,13 @@ int smu_link_reset(struct smu_context *smu);
> 
>  extern const struct amd_ip_funcs smu_ip_funcs;
> 
> -bool is_support_sw_smu(struct amdgpu_device *adev);
> +void amdgpu_smu_early_init(struct amdgpu_device *adev);
> +
> +static inline bool is_support_sw_smu(struct amdgpu_device *adev)
> +{
> +	return adev->is_sw_smu;
> +}
> +
>  bool is_support_cclk_dpm(struct amdgpu_device *adev);
>  int smu_write_watermarks_table(struct smu_context *smu);





  reply	other threads:[~2026-06-26 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  8:55 [PATCH 0/3] Job submission optimisation Tvrtko Ursulin
2026-06-26  8:55 ` [PATCH 1/3] drm/amdgpu: Remove unused amdgpu_device_ip_is_hw Tvrtko Ursulin
2026-06-26 16:59   ` Timur Kristóf
2026-06-26 19:06     ` Tvrtko Ursulin
2026-06-26  8:55 ` [PATCH 2/3] drm/amdgpu: Save some cycles on the job submission path Tvrtko Ursulin
2026-06-26 17:10   ` Timur Kristóf [this message]
2026-06-29 15:28     ` Alex Deucher
2026-06-29 22:31       ` Timur Kristóf
2026-06-30 13:30         ` Alex Deucher
2026-06-26  8:55 ` [PATCH 3/3] drm/amdgpu: Do not fiddle with the idle workers too much Tvrtko Ursulin
2026-06-26 17:15   ` Timur Kristóf
2026-06-26 18:59     ` Tvrtko Ursulin
2026-06-30  8:44       ` Tvrtko Ursulin

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=3694635.dWV9SEqChM@timur-max \
    --to=timur.kristof@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=kernel-dev@igalia.com \
    --cc=tvrtko.ursulin@igalia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox