https://bugs.freedesktop.org/show_bug.cgi?id=109763
Bug ID: 109763 Summary: [radeonsi] Enable framerate capping Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: shtetldik@gmail.com QA Contact: dri-devel@lists.freedesktop.org
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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #1 from fin4478@hotmail.com --- Created attachment 143515 --> https://bugs.freedesktop.org/attachment.cgi?id=143515&action=edit a simple python app for the amdgpu sysfs API
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #2 from fin4478@hotmail.com --- You can use a selected engine clock range to lower performance. You can use my python app for that.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #3 from Shmerl shtetldik@gmail.com --- That's not really the same as hard limiting the framerate, though can be useful as well.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #4 from fin4478@hotmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #5 from Shmerl shtetldik@gmail.com --- (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).
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #6 from smoki smoki00790@gmail.com ---
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...
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #7 from Shmerl shtetldik@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #8 from smoki smoki00790@gmail.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #9 from Shmerl shtetldik@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #10 from Shmerl shtetldik@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #11 from smoki smoki00790@gmail.com ---
I guess that Chill is what people wants actually, as FRTC-like one can do already via mentioned wrappers anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #12 from Shmerl shtetldik@gmail.com ---
From what gathered, wrappers like libstrangle aren't working consistently
(especially for radv), so having even such minimal limiting upstream would already useful.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
Kristoffer brisse@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brisse@outlook.com
--- Comment #13 from Kristoffer brisse@outlook.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #14 from Shmerl shtetldik@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=109763
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #15 from GitLab Migration User gitlab-migration@fdo.invalid --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org