Bug 477446

https://gitlab.freedesktop.org/drm/amd/-/issues/1500#note_1487319

Alex Deucher (AMD):

"Adding a framerate limiter creates bubbles in the pipeline which means the GPU sees less sustained load and so it doesn't ramp up as high as it would if there were no limiter in place.  pp_power_profile_mode allows you to adjust the heuristics used to ramp up and down the clocks.  power_dpm_force_performance_level=high forces all of the clocks to high all of the time is probably not what you want.  Keeping them high all the time kills your thermal and power headroom and likely causes throttling because they would never naturally ramp down.  Adjusting pp_power_profile_mode is the right approach if the default heuristics are not working well for you.  That is why they are there.  Changing the default to something more aggressive uses more power, especially for lighter weight desktop workloads so there is always a trade off.

Windows has the concept of a fullscreen 3D game mode so the driver can switch the profile when that mode is requested.  On Linux there is no similar concept.  A fullscreen 3D app is just an app that takes the full screen size.  E.g., it could be a game or it could just be the desktop compositor.  I think ideally for Linux, we'd have some user process, maybe as part of mesa, that knows that the user wants to do and requests the appropriate profile.  You can also take into account the power source (AC vs. battery) and adjust the profile for that as well if you want less aggressive heuristics when on battery power for example."

Wayland has the content type protocol.

The "user process" would be "power-profiles-daemon", but that still needs GPU support: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/3