Restore DXVK_FRAME_RATE

[Tiagoquix]

#5331
#5330

I'm making this meta-issue to discuss the restoration of DXVK_FRAME_RATE since discussion is being split into a pull request and the original issue. I am in favor of keeping it in DXVK, as others have expressed similar concerns.

Thanks for your attention.

[SkindoDeveloper]

I am joining on bringing it back.

What damage could one small and quick env var do. Removing it because "users get confused" is rather a weird situation in Linux space overall.

Mangohud was never, in any single instance better then DXVK limiter for me. This is in many cases: Mainstream games, AAA games, small games, ultra simple games, niche games... RTX 4070ti, 165hz refresh rate

If the limiter is so "underperforming", whats this change going to help with but sabotage those who find it ok.

[Kiotrw25]

Same.

Like, if it gives you issues for whatever or non problematic reason just don't use it 🤷

I didn't read up on the reason why it was removed but from the title of #5330 i would think it was suggested to remove cause it makes fps counter on monitor not work properly.

[lumingzh]

Games like Fallout 4 require this option to limit fps with V-sync disabled to fix the "boost" bug. But anyone know how to limit fps except DXVK? I tried mangohud but leads to crash, the game can't run anymore.

[lumingzh]

Games like Fallout 4 require this option to limit fps with V-sync disabled to fix the "boost" bug. But anyone know how to limit fps except DXVK? I tried mangohud but leads to crash, the game can't run anymore.

Well, fixed by set option DXVK_CONFIG="dxgi.maxFrameRate = 120" %command%.

[Digger1955]

It seems that this situation went to - "it is easier to make a fork, than to ask for an upstream change".

If someone still needs DXVK_FRAME_RATE environment variable and DXVK Latency Tracker - DXVK-GPLALL has implemented both improved Latency Tracker solution and FPS Limiter developed by netborg-afps along with many other improvements and will always have DXVK_FRAME_RATE environment variable, since I am its lead maintainer.

And DXVK-GPLALL still has the original DXVK Latency Tracker and FPS Limiter solutions.

[flightlessmango]

@SkindoDeveloper

Mangohud was never, in any single instance better then DXVK limiter for me

When you say “better”, what specific behavior are you seeing? Lower latency, tighter frame spacing, fewer spikes, something else?

Have you tried mangohud limiter recently-ish? have you compared late and early limiter modes? Are you using VRR?

On my system I get roughly 1.8 ms variance with the DXVK limiter and around 0.1 ms with the current MangoHud limiter, so I’d like to understand what conditions are worse for you and others.

[netborg-afps]

@flightlessmango

Before implementing frame pacing in dxvk, I also tried that in Mangohud, before realizing you need to put the delay into d3d.present() because the frame actually starts there (start of rendering to be exact). To be specific, I've implemented a pacing version where I tried to make every frame have the same latency, and it even improved native Vulkan games like Doom Eternal. I've never released it, but could for science (after cleaning up the messy code) if there would be interest. Although it did improve the pacing of some specific games, it also added latency, and ultimately it was not production ready.

In my opinion, there is no better way than to implement the limiting/pacing directly into dxvk.

On my system I get roughly 1.8 ms variance with the DXVK limiter and around 0.1 ms with the current MangoHud limiter

I guess you are measuring at the same place where you are putting the limiter. The frame goes from d3d.present() to Vulkan.present() to vkWaitForPresent(). You get the most smooth experience if the frame latencies are smooth (and the frame spacing is too). But as said, when you don't have access to d3d.present() you cannot even know the latency, let alone control the latency.

Or to put it into other words, when you have random d3d.present() starts, it doesn't help much to smooth at vkQueuePresentKHR(), because the simulation time stamp is baked into the frame start, and thus you can get a stuttery experience even if the present time stamps are perfectly aligned.

It has been quite a while when I worked on that Mangohud pacing, so I don't remember everything exactly, but I believe I improved it (for specific use-cases) because I was also working with vkWaitForPresent(), so at least I knew that vkQueuePresentKHR() is actually firing up the present, whereas otherwise even that is random and will lead to issues.

But yes, when I think about it. When you perform the delay of vkQueuePresentKHR() after all rendering has been done, this should definitely improve smoothness of the Mangohud limiter, and should be doable when injecting into vkQueueSubmit to get a fence signal of the last submission.

[flightlessmango]

@netborg-afps
I completely agree that DXVK is a better place to implement a limiter. Whether the DXVK limiter returns, stays as it is or your implementation is adopted, I still think it is valuable to understand and improve the MangoHud limiter, especially since not all titles will use DXVK or VKD3D

[Kiotrw25]

@flightlessmango
Don't mind the not so professional language, it should give some overview to my experience with mangohud limiter #5331 (comment) , guess it can be taken as feedback. Think it even added some inputlag not using smooth motion.

That mangohud should be around 2 months old from today. At this time i can not confirm that if it was an important detail, as i was using rolling and i switched to a non rolling distro which have older version and i didn't update manually.

Thanks so much for Mangohud.

[i1u5]

Seems like DXVK_CONFIG="dxgi.maxFrameRate = X" is the alternative for now even though it's a bit hacky, I'm also in favor of restoring the env var.

[givname]

where is the burden to keep an env var? i mean ofc there is some more code behind this to work but i dont grasp if there is any work for maintaining this, especially if the logic behind is kept anyways and yes it helps saving power especially for games that produce coil whine when loading menus and fps are not capped (ofc we can do this with mangohud but the stable build requires to use MANGOHUD_CONFIG which interferes with my config file, which i dont want to touch and is not game specific ...)

[Tiagoquix]

@givname you can use MANGOHUD_CONFIG=read_cfg,fps_limit=60 (for example). this way it will use your CFG and then apply the fps limit.

[3ventic]

Regardless of the intent behind the change or the value of the env var's existence, a sudden removal doesn't serve anyone. If the project is really set on removing it, do it more gradually: via documentation, deprecation warnings, and whatever else, while encouraging the better(?) alternatives.

It may seem inelegant and against ideal to have a dedicated env var for one option, but I would argue it saves everyone time and headaches to keep it for the tweak that is so widely used and so widely documented across the internet.

Personally, I don't use the env var a lot, but I do frequently limit my FPS well below the screen refresh rate just to save GPU time for other things I have open on the side, without impacting the responsiveness of the rest of the display. There's value in fps limits beyond fixing game physics or render timing, and it has been a useful option to be able to quickly and easily set in a consistent manner across games.