mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: "Christian König" <christian.koenig@amd.com>,
	"Philipp Zabel" <philipp.zabel@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Pelloux-Prayer,
	Pierre-Eric" <Pierre-eric.Pelloux-prayer@amd.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/6] amdgpu: Avoid powering on the dGPU on vkEnumeratePhysicalDevices()
Date: Wed, 06 Aug 2025 12:15:15 +0200	[thread overview]
Message-ID: <41b37595c42e4f492704a31970936d52b96dae97.camel@pengutronix.de> (raw)
In-Reply-To: <601a40fd-e508-4e9d-8dd3-14329f3a637b@amd.com>

On Mi, 2025-08-06 at 10:58 +0200, Christian König wrote:
> On 31.07.25 07:36, Philipp Zabel wrote:
> > This is an attempt at fixing amd#2295 [1]:
> > 
> >   On an AMD Rembrandt laptop with 680M iGPU and 6700S dGPU, calling
> >   vkEnumeratePhysicalDevices() wakes up the sleeping dGPU, even if all
> >   the application wants is to find and use the iGPU. This causes a delay
> >   of about 2 seconds on this system, followed by a few seconds of
> >   increased power draw until runtime PM turns the dGPU back off again.
> > 
> > [1] https://gitlab.freedesktop.org/drm/amd/-/issues/2295
> > 
> > Patch 1 avoids power up on some ioctls that don't need it.
> > Patch 2 avoids power up on open() by postponing fpriv initialization to
> > the first ioctl() that wakes up the dGPU.
> > Patches 3 and 4 add AMDGPU_INFO to the list of non-waking ioctls,
> > returning cached values for some queries.
> > Patch 5 works around an explicit register access from libdrm.
> > Patch 6 shorts out the syncobj ioctls while fpriv is still
> > uninitialized. This avoids waking up the dGPU during Vulkan syncobj
> > feature detection.
> 
> This idea came up multiple times now but was never completed.
> 
> IIRC Pierre-Eric last worked on it, it would probably be a good idea to dig up his patches from the mailing list.

Thank you, I wasn't aware of those patches [1]. Pierre-Eric did mention
them in https://gitlab.freedesktop.org/mesa/mesa/-/issues/13001, but I
didn't pick up on that back then.

[1] https://lore.kernel.org/all/20240618153003.146168-1-pierre-eric.pelloux-prayer@amd.com/

Is that the latest version? It looks to me like the review stalled out
on a disagreement whether the GB_ADDR_CONFIG query should be a separate
ioctl or whether it should be added to drm_amdgpu_info_device. The
discussion was later continued at
https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/368,
seemingly coming to the conclusion that keeping the register read (but
cached) is the way to go? I didn't find a newer series with that
implemented.

> > 
> > regards
> > Philipp
> > 
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > Alex Deucher (1):
> >       drm/amdgpu: don't wake up the GPU for some IOCTLs
> > 
> > Philipp Zabel (5):
> >       drm/amdgpu: don't wake up the GPU when opening the device
> >       drm/amdgpu: don't query xclk in AMDGPU_INFO_DEV_INFO
> >       drm/amdgpu: don't wake up the GPU for some AMDGPU_INFO queries
> >       drm/amdgpu: don't wake up the GPU for mmGB_ADDR_CONFIG register read
> 
> That is both unnecessary an insufficient. Unnecessary because we already have a mechanism to cache register values and insufficient because IIRC you need to add a bunch of more registers to the cached list.

This series was (just barely) sufficient for my purpose, which was only
to make vkEnumeratePhysicalDevices() not wake the dGPU on my Laptop.
I didn't realize there already was a caching mechanism in the lower
layers.

> See Pierre-Erics latest patch set, I think we already solved that but I'm not 100% sure.

If I found the correct version, it seems Sima's suggestion of pushing
runtime pm handling down from amdgpu_drm_ioctl into the amdgpu ioctl
callbacks [2] would be the best first next step?

[2] https://lore.kernel.org/amd-gfx/ZnvJHwnNAvDrRMVG@phenom.ffwll.local/

regards
Philipp

  reply	other threads:[~2025-08-06 10:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31  5:36 Philipp Zabel
2025-07-31  5:36 ` [PATCH RFC 1/6] drm/amdgpu: don't wake up the GPU for some IOCTLs Philipp Zabel
2025-07-31  5:36 ` [PATCH RFC 2/6] drm/amdgpu: don't wake up the GPU when opening the device Philipp Zabel
2025-07-31  5:36 ` [PATCH RFC 3/6] drm/amdgpu: don't query xclk in AMDGPU_INFO_DEV_INFO Philipp Zabel
2025-07-31  5:36 ` [PATCH RFC 4/6] drm/amdgpu: don't wake up the GPU for some AMDGPU_INFO queries Philipp Zabel
2025-07-31  5:36 ` [PATCH RFC 5/6] drm/amdgpu: don't wake up the GPU for mmGB_ADDR_CONFIG register read Philipp Zabel
2025-07-31 19:38   ` Alex Deucher
     [not found]     ` <CA+gwMcc41Hh=or7NLMnG++miHj_dNLZ04iFYdf=U7_LLG1gSZw@mail.gmail.com>
2025-08-01 15:27       ` Alex Deucher
2025-07-31  5:36 ` [PATCH RFC 6/6] drm/amdgpu: don't wake up the GPU for syncobj feature detection Philipp Zabel
2025-08-06  8:58 ` [PATCH RFC 0/6] amdgpu: Avoid powering on the dGPU on vkEnumeratePhysicalDevices() Christian König
2025-08-06 10:15   ` Philipp Zabel [this message]
2025-08-06 13:17     ` Christian König
2025-08-20  7:42       ` Pierre-Eric Pelloux-Prayer

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=41b37595c42e4f492704a31970936d52b96dae97.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=Pierre-eric.Pelloux-prayer@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=philipp.zabel@gmail.com \
    --cc=simona@ffwll.ch \
    /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

all inboxes | Powered by JetHome®