| 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 po= wer 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=3D100389 But not sure what the right place is for such capping to occur, so opening = one for radeonsi.
Created attachment 143515 [details]
a simple python app for the amdgpu sysfs API
You can use a selected engine clock range to lower performance= . You can use my python app for that.
That's not really the same as hard limiting the framerate, tho= ugh can be useful as well.
Many games have a built in frame rate limiter. Your GPU will n= ot wear if temperatures are OK. Increase cooling in your computer case. There is no se= nse to duplicate features that are in games or can be solved otherwise. The amg= pu driver code is complex already.
(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).
Shmerl i guess wants something in driver like AMD FRTC: https://www.amd.com/e= n/technologies/frtc So not to use something external like libstrangle: https://gitlab.com/to= rkel104/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...
(In reply to smoki from comment #6) > Shmerl i guess wants something in driver like A= MD FRTC: >=20 > https://www.amd.= com/en/technologies/frtc >=20 > 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 fp= s" for example.
Just say, i wanna something like AMD FRTC for non FreeSync users and somet= hing 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 th= ese days. If you are VRR capable you wanna something like Chill, otherwise FRTC= :D
I suppose both use cases are important, since there are monito=
rs with and
without FreeSync support.
I haven't used AMD on Windows (or their closed driver or Linux), so I was n=
ot
familiar with Chill and FRTC. But yes, that's exactly what this is about.
If I understand correctly, Chills is doing some dynamic implic= it framerate management, which can be useful too, but it would be good to have a hard li= mit option as well.
I guess that Chill is what people wants actually, as FRTC-like one can do already via mentioned wrappers anyway.
From what gathered, wrappers like libstrangle aren't working c= onsistently (especially for radv), so having even such minimal limiting upstream would already useful.
| What | Removed | Added |
|---|---|---|
| CC | brisse@outlook.com |
I believe Chill might be encumbered by patents so I'm not sure= an open source implementation is legally possible. https://pate= nts.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.
(In reply to Kristoffer from comment #13) > I believe Chill might be encumbered by patents s= o I'm not sure an open > source implementation is legally possible. >=20 > https:/= /patents.google.com/patent/US20080055318A1/ >=20 > It's also quite a bit more complicated than a static framerate limiter, > requiring monitoring of on-screen movement and input events to constan= tly > evaluate what framerate is appropriate in each moment. >=20 > 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 ne= ver 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.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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.