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.

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.

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.

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

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.

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

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

@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

@flightlessmango
Don't mind the not so professional language, it should give some overview to my experience with mangohud limiter https://github.com/doitsujin/dxvk/pull/5331#issuecomment-3565187239 , 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.

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.

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

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

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.

Just out of the blue removing a widely-used option makes no sense. If it's problematic for people, let them stop using it.
For those that use it, having DXVK_FRAME_RATE just disappear one update is an unnecessary frustration.
Is it a bigger headache for the devs to keep it compared to the headache its removal causes those who rely on it, whatever their use case or reason is?

In my case if anyone need this work for d3d8 (tested with bloodrayne 1, xmen legends 2), d3d9 (tested with red faction guerilla) and d3d11 (tested with mortal kombat xl) for fps limit, in my case 60fps

dxgi.maxFrameRate = 60
d3d9.maxFrameRate = 60
d3d8.maxFrameRate = 60

this lines must stay on dxvk.conf file

d3d8.maxFrameRate = 60

This doesn't exist. d3d8 simply uses the d3d9 config option here, as is the case in many other situations.

And for those who really need an env var to configure things more directly, look no further than DXVK_CONFIG.

@doitsujin

Anyway, I've said my piece multiple times now, it's not a feature that I'm interested in maintaining outside of the required use cases, it's not suited for general use, the env var is not coming back, and I'm not sure what creating a "meta-issue" is supposed to solve compared to the other thread.

The env. var. has been present for a long time now. Not sure for how much time, but I believe more than 2 years. Even though you are not interested in maintaining it outside of specific use-cases, the fact is that it works outside such use-cases too. Even in all those years that you were not maintaining it for general usage, it still worked great for general usage.

Like others said, removing the env. var. while still leaving the option in dxvk.conf just reads like an annoyance for Linux users. You may say the limiter is bad or whatever, but the fact is that it works reasonably well for most people that use it.

That said, I have been using mangohud as a substitute for the fps limiter since the env. var. was removed, but having it natively on DXVK without having to rely on external tools is more ideal.

I don't know if this discussion reignites some vibes of a discussion of the past of "DXVK GPL vs. DXVK AGPL", which was a hacky method. I believe it does not, and well, as an end-user, DXVK_FRAME_RATE is appreciated and I had not had issues with it.

What prompted the removal of the env. var. was a niche use-case of VRR with very high FPS usage. But does that justify the removal of the config. option entirely? Wouldn't it be better to just add a warning saying it may not work for such use-cases and simply not fix it, rather than removing it entirely?

I have used the config. option for more than a year now and I have not had any issues, even with VRR.

I understand your intention to remove the env. var., but I think since it has been working reasonably well for most people then I don't see such a big reason for removing it.

d3d8.maxFrameRate = 60

This doesn't exist. d3d8 simply uses the d3d9 config option here, as is the case in many other situations.

And for those who really need an env var to configure things more directly, look no further than DXVK_CONFIG.

confirmed in my case using advent rising d3d8

thanks

Maybe the recent/upcoming merge of VK_EXT_present_timing fix the problems I outlined in my original issue?

https://github.com/KhronosGroup/Vulkan-Docs/pull/1364
https://www.phoronix.com/news/VK_EXT_present_timing-Merged

Especially when running the games natively on Wayland?

Would DXVK have more access to the display and presentation with this Vulkan extension?

Almost all compositors also support the presentation time protocol on Wayland as well.
https://wayland.app/protocols/presentation-time#compositor-support

Let's say RADV implements this (so it's in the driver), the compositor already supports it (on Wayland, GNOME, KDE and many others already support it) and we're running the games natively on Wayland, would DXVK implement this even if the XWayland side was not implemented yet?

Because to be honest, I myself don't need nor use XWayland in any capacity anymore. Only the Steam client uses it in my case. All my games run natively on Wayland (where DXVK and VKD3D are concerned).

Also it seems the NVIDIA driver already supports this.

The NVIDIA Linux Vulkan driver already supports the VK_EXT_present_timing extension while presumably the prominent Mesa Vulkan drivers will be introducing support for it soon given that it can be a big-ticket item for gaming moving forward.

So it's up to RADV and ANV now.

Edit: I would prefer that XWayland not to be a blocker for a feature like this. I'm sure others would agree.

I remember someone saying on one my issues that DXVK doesn't know or care about Wayland/XWayland at all. Why would it matter with this Vulkan extension then?

DXVK doesn't know anything about wayland or drm syncobjects.

DXVK at least doesn't create any sync objects or use any wayland protocol by itself at all. The only thing DXVK uses is the vulkan and win32 api and win32 vulkan wsi

Like the others have already said: while it's built for Linux, DXVK is essentially a Windows DLL. It doesn't know X11 or Wayland, it puts the image on screen using the Win32 Vulkan APIs. It's Wines job to make that work with X11 or Wayland.

https://github.com/doitsujin/dxvk/issues/4560#issuecomment-2564332393

Were they wrong or is this something that needs to interface with Wayland/XWayland?

I'm just trying to better understand. Hopefully Vulkan and Wayland/XWayland utilizes it properly and the specs/headers are ready for DXVK/VKD3D in the future.

Well it's out now. That was fast.

Change log for November 28, 2025 Vulkan 1.4.335 spec update:

New Extensions

• VK_EXT_present_timing

https://github.com/KhronosGroup/Vulkan-Docs/commit/60a4ad187cf3be4ede658f0fae7dd392192a314b

Is this not it?

https://wayland.app/protocols/presentation-time#compositor-support

Or is it something else? This?

https://wayland.app/protocols/commit-timing-v1#compositor-support

I'm surprised GNOME supports something that others don't, usually it's the other way around :D

@nokia8801 I think this would be needed https://wayland.app/protocols/commit-timing-v1

@nokia8801 I think this would be needed https://wayland.app/protocols/commit-timing-v1

Btw for Kwin, creating a feature request issue at bugs.kde.org might help

As for wlroots, there have been quite a lot of iterations recently in the implementation of fifo-v1:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4463

...and commit-timing-v1:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4617

Apparently, it can be landed in wlroots 0.20. I'm not sure what the release schedule for wlroots is, but I'm guessing that wlroots 0.20 will be released in about 6 months to a year.

I literally pinched myself over this. Please restore it ASAP, as it makes Lossless Scaling Frame Generation nearly unusable on SteamOS, and even Linux in general. Unless the feature was moved at a higher level like Proton itself? But even still.

EDIT: Ok I'm reading more things that explain this decision, I'm still a bit thorn on this, it's great to encourage users to go for third party solutions as they will often provide better frame pacing indeed, it just kind of came from nowhere.
Maybe having the feature still inside but updating the description could be a middle ground.

uh oh, didn't try this myself but assuming this is true... welll... it needs to go back ^^
also, mangohud sometimes can have issues, and more input latency.

Some movement with the VK_EXT_present_timing in Mesa.

https://www.phoronix.com/news/Mesa-VK_EXT_present_timing
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38770

Hopefully it all gets sorted out in 2026 and we can see it in DXVK and VKD3D-Proton.

Mangohud is not a good alternative, It completely breaks freesync, in game limiters bounce around too much and cause my LFC to act up on my monitor. Removing DXVK_FRAME_RATE is not ideal.

My honest reaction after 5 minutes, I discovered this in Heroic Games Launcher.

Suddenly I read about this thing in a changelog... mind you I was using the limited until today, which is weird since it worked perfectly (and it was removed in november) so wtf.

Anyway, hi everyone! My use case for the FPS limiter is this:
My gaming laptop died at the end of August 2025, so I finally built my own PC and I love it!
The maximum consumption of that laptop was about 90W at peak.
The current maximum consumption could be something about 300W, at 100% usage on both CPU and GPU.

The CPU is a Ryzen 7 5800X, the GPU is an AMD RX 6650XT.

In my family we have to be careful even when powering on the damn AC/Heater, since the energy bill increases a lot and we're not floating in money.

Since I built my PC and since I'm using Gentoo Linux, I've been using more energy, mostly for updates (CPU wise) but that's not the problem.

Even if I could easily play games at 120FPS, especially the older ones, I prefer to lock most of them at 60FPS, because the GPU energy draw can drop from 120W to 60W, stuff like that, even less.
This may seem a kinda stupid reason, but the limiter helps to control the energy consumption and load of the GPU.

Also, I don't use in-game v-sync, at all. I avoid it like the plague.
Why?
Because Wayland by default has an awesome v-sync that works even if you run your games at 2000FPS, no tearing at all.
That way, DXVK's FPS Limiter is the way to not have added input latency AND control your framerate, since a lot of games has shitty FPS limiters.

What pisses me off is the fact that Heroic doesn't use DXVK_CONFIG since you can use that option there... basically the function got removed but it's still possible with another way.

I wanted to create a PR for Heroic but sadly I'm uncapable of doing the rest, apart restoring the old code.

Some more movement with the VK_EXT_present_timing protocol. Looks it's ready for Mesa 26.1 for both X11 and Wayland.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38770

Wish it was in 26.0. Oh well.

Compositors are ready (at least Mutter), Mesa and drivers are ready (RADV, ANV, NVK). No clue about NVIDIA.
Looks like only Wine is left.

https://gitlab.winehq.org/wine/wine/-/merge_requests/9655

Then finally DXVK and VKD3D-Proton.

And it looks like present timing will only work with FIFO as others have already pointed out here and in my previous issue.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38770/diffs#8b9326d5e797a10c9d7bf33ddb5420c06e700768_1917_1968

Honestly, present timing should also work with other modes like immediate, but FIFO seems to be the only way to get information about the display refresh timing.

massive L on dxvk's part. at least i have libstrangle

libstrangle works for many things yes, even if its unmaintained last update 2022
removing DXVK_FRAME_RATE is a small bump with workarounds and alternatives
i do not use mangohud, never liked it. its a great tool, alternate

gamescope can also limit frame rate
gamescope -r 60 -- %command%

when using DXVK+Proton/wine its just simpler to use the default built in RATE limiter
many games unfortunately do not have vsync, or poor engine design allows the rate to max (1000+ FPS looking at a loading screen) which is bad for the GPU & temps...
i dont have or use VRR or freesync or otherwise want more than 60fps typically

ill be updating my lists to show DXVK_CONFIG="dxgi.maxFrameRate = 60" %command% as the new required method to limit frames
until some other more sane method of simply toggling it on/off exists inside or outside of this api environment (preferably directly via vulkan)

AMD Ryzen 9 7945HX
GPU AMD Radeon RX 7900M navi31
Mesa 25.3.5 - kisak-mesa
Vulkan 1.4.335
Linux 6.18.9-amdr18

KDE's commit-timing support here: https://invent.kde.org/plasma/kwin/-/merge_requests/8955

As an addendum, GE-Proton decided to keep the env. var. themselves, getting the value from DXVK_FRAME_RATE and applying it as DXVK_CONFIG: https://github.com/Open-Wine-Components/umu-protonfixes/pull/514

I still believe the env. var. should be restored.

Found out why my PC temps were going crazy, games are trying to reach 144fps instead of staying on 60 or 40. What a dumb move