Bug 109763

Summary: [radeonsi] Enable framerate capping
Product: Mesa Reporter: Shmerl <shtetldik>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: brisse, fdsfgs, john.ettedgui
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: a simple python app for the amdgpu sysfs API

Description Shmerl 2019-02-24 22:49:18 UTC
It can be beneficial to enable framerate capping, to reduce power consumption and hardware wear out in case when user can be satisfied with certain max framerate.

There is a similar DRI bug: https://bugs.freedesktop.org/show_bug.cgi?id=100389
But not sure what the right place is for such capping to occur, so opening one for radeonsi.
Comment 1 fin4478 2019-03-03 10:20:40 UTC
Created attachment 143515 [details]
a simple python app for the amdgpu sysfs API
Comment 2 fin4478 2019-03-03 10:22:06 UTC
You can use a selected engine clock range to lower performance. You can use my python app for that.
Comment 3 Shmerl 2019-03-03 10:22:46 UTC
That's not really the same as hard limiting the framerate, though can be useful as well.
Comment 4 fin4478 2019-03-03 10:28:09 UTC
Many games have a built in frame rate limiter. Your GPU will not wear if temperatures are OK. Increase cooling in your computer case. There is no sense to duplicate features that are in games or can be solved otherwise. The amgpu driver code is complex already.
Comment 5 Shmerl 2019-03-03 10:37:34 UTC
(In reply to fin4478 from comment #4)
> Many games have a built in frame rate limiter.

This is obviously intended for those which don't have it (which are many as well).
Comment 6 smoki 2019-03-03 20:40:48 UTC
 Shmerl i guess wants something in driver like AMD FRTC:

 https://www.amd.com/en/technologies/frtc

 So not to use something external like libstrangle:

 https://gitlab.com/torkel104/libstrangle

 That could limit framerate for most of GL or VK apps.

 For Nine and D3D9 games under WINE one could use this d3d9-wrapper:
 
 https://github.com/ThirteenAG/d3d9-wrapper

 Both could be used by (if possible) just dropping wrapper in game dir and set what you want via variables, config file, etc...
Comment 7 Shmerl 2019-03-03 20:54:02 UTC
(In reply to smoki from comment #6)
>  Shmerl i guess wants something in driver like AMD FRTC:
> 
>  https://www.amd.com/en/technologies/frtc
> 
>  So not to use something external like libstrangle:
> 


Yes, something built into radeonsi (and radv) would be nice. Limiting it by GPU clocks isn't really the same, as in "limit it with not exceeding 80 fps" for example.
Comment 8 smoki 2019-03-03 21:41:24 UTC
 Just say, i wanna something like AMD FRTC for non FreeSync users and something like AMD Chill for FreeSync users :D

 Both these could caps framerate just in a different enviroments and this is where this become complicated as it depends what kind of screen you have these days. If you are VRR capable you wanna something like Chill, otherwise FRTC :D
Comment 9 Shmerl 2019-03-03 21:59:52 UTC
I suppose both use cases are important, since there are monitors with and without FreeSync support.

I haven't used AMD on Windows (or their closed driver or Linux), so I was not familiar with Chill and FRTC. But yes, that's exactly what this is about.
Comment 10 Shmerl 2019-03-03 22:03:38 UTC
If I understand correctly, Chills is doing some dynamic implicit framerate management, which can be useful too, but it would be good to have a hard limit option as well.
Comment 11 smoki 2019-03-04 02:00:51 UTC
 I guess that Chill is what people wants actually, as FRTC-like one can do already via mentioned wrappers anyway.
Comment 12 Shmerl 2019-03-04 02:03:20 UTC
From what gathered, wrappers like libstrangle aren't working consistently (especially for radv), so having even such minimal limiting upstream would already useful.
Comment 13 Kristoffer 2019-03-18 19:49:03 UTC
I believe Chill might be encumbered by patents so I'm not sure an open source implementation is legally possible.

https://patents.google.com/patent/US20080055318A1/

It's also quite a bit more complicated than a static framerate limiter, requiring monitoring of on-screen movement and input events to constantly evaluate what framerate is appropriate in each moment.

A static framerate limiter would be nice though, but we already have libstrangle for that which works well most of the time.
Comment 14 Shmerl 2019-03-18 20:09:30 UTC
(In reply to Kristoffer from comment #13)
> I believe Chill might be encumbered by patents so I'm not sure an open
> source implementation is legally possible.
> 
> https://patents.google.com/patent/US20080055318A1/
> 
> It's also quite a bit more complicated than a static framerate limiter,
> requiring monitoring of on-screen movement and input events to constantly
> evaluate what framerate is appropriate in each moment.
> 
> A static framerate limiter would be nice though, but we already have
> libstrangle for that which works well most of the time.

I'd day better to have it upstream than separate, besides it's not always working, especially for Vulkan.

In regards to patents, that's something that always can happen - you can never be sure. If you are worried about that specific one from AMD, AMD can be contacted about it. After all it's in their interest not to cause troubles to Linux graphics stack.
Comment 15 GitLab Migration User 2019-09-25 18:48:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1374.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.