doitsujin
Restore DXVK_FRAME_RATE
https://github.com/doitsujin/dxvk/pull/5331 https://github.com/doitsujin/dxvk/issues/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.
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?
do it more gradually: via documentation, deprecation warnings
I mean, fair enough, we could have put a log message first or something but we also don't really have great ways to communicate changes outside of release notes (which obviously the next release will mention, but it's still some months off). Most people would have found out the hard way regardless.
Not sure how widely used this was anyway since it's a somewhat niche option that's only ever really used on desktop (as opposed to e.g. Steam Deck), and certainly not by the Windows crowd either since everyone there just throws SpecialK (or RTSS / driver options) at the problem and environment variables are a pain in the arse anyway.
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.
There's value in fps limits beyond fixing game physics or render timing
Yes, but those use cases are precisely the kind that are universally better served by external tools.
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
FWIW, there's a chance that we consolidate configs that are currently duplicated between D3D9 and DXGI. I've wanted to clean that up for a long time.
Some of those need to remain duplicate (e.g. PCI ID overrides, since sometimes the D3D11 version of a game requires an override but the D3D9 path doesn't, and vice versa) , but for things like max FPS and sampler LOD bias there's really no reason why we need two.
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
I'm aware of that extension and I do plan to implement it eventually, but we need driver support and some sort of XWayland support first, so I wouldn't expect this to be viable any time soon.
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.
The number of people that run Windows games natively on wayland is probably around ten, and I'm not too inclined to start shipping something (at least not by default) that basically works nowhere and then probably ends up breaking everything once it does get implemented because we haven't had the chance to test it properly.
Anyway, can we wait for things like an updated spec release and Vulkan headers first? 🐸
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.
DXVK not being aware of X11/Wayland-specifics doesn't mean that any requirements for the platform supporting the features that we're trying to use are going away though?
We create a Vulkan surface to present stuff on, from our PoV this is going to be a Win32 surface. Wine implements that on top of an X11 surface (or Wayland for the five people who actually bother tinkering with it), and if that underlying X11 surface doesn't support display timing then we obviously can't use the thing.
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
Apparently nobody outside of Gnome actually actually implements the needed wayland protocols right now and the NV implementation currently only really seems to work as intended on X11 without any sort of Prime involved.
Way too much of a pain in the arse to do an implementation right now, and even if I did start working on one right now, there's absolutely no guarantee whatsoever that it would even work on different setups once the stack comes along. Did some prep work to upgrade to present_id2 in the meantime but that's about all that can be meaningfully done for now.
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
