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, though can be useful as well.

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.

(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/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...

(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.

 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

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.

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.

 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 consistently (especially for radv), so having even such minimal limiting upstream would already useful.

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.

(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.

-- 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.