To reiterate my point of view on the entire matter (not putting words in anyone else's mouth or anything), just so that everyone is aware of it, this "major issue" you keep throwing about, at times in all caps, is only a major nothingburger.
External tooling as well as regular users are free to continue using the frame limiter through: DXVK_CONFIG="dxgi.maxFrameRate = 60; d3d9.maxFrameRate = 60", or only one of the two, as an equivalent option. It is not going to go away, there are games that need such an option, that much has already been stated.
There's also no reason why this option in particular should get preferential treatment as opposed to the various other config options DXVK provides, all of which have a single env variable to rule them all and in the darkness bind them, namely DXVK_CONFIG.
The fact that its use is not encouraged is the opinion of its author, and it is up to you to value it or not. I, for one, think no one can know better about the limitations at play here than the person who wrote the damn thing. But if you think it works better for your particular use case, just keep using it. It's that simple.
Please don't remove this env just because 1 enthusiastic person complained about something very specific, the env made it a lot easier and works well on both DXVK/VKD3D-Proton.
To reiterate my point of view on the entire matter (not putting words in anyone else's mouth or anything), just so that everyone is aware of it, this "major issue" you keep throwing about, at times in all caps, is only a major nothingburger.
External tooling as well as regular users are free to continue using the frame limiter through:
DXVK_CONFIG="dxgi.maxFrameRate = 60; d3d9.maxFrameRate = 60", or only one of the two, as an equivalent option. It is not going to go away, there are games that need such an option, that much has already been stated.There's also no reason why this option in particular should get preferential treatment as opposed to the various other config options DXVK provides, all of which have a single env variable to rule them all and in the darkness bind them, namely
DXVK_CONFIG.The fact that its use is not encouraged is the opinion of its author, and it is up to you to value it or not. I, for one, think no one can know better about the limitations at play here than the person who wrote the damn thing. But if you think it works better for your particular use case, just keep using it. It's that simple.
I don't understand this whole problem of maintaining a simple env if there are other methods of doing the same thing, the problem is that this is affecting projects like VKD3D-Proton that are having to remove the env too. That's why Linux will never be mainstream, devs worry too much about enthusiasts who are not the 1% and create a difficult for the majority.
The real users aren't here at GitHub and don't even know what's going on. And FPS limit will just stop working when a user tries to use a launch argument from a tutorial or ProtonDB because 1 person complained about something useless.
If I cap my frames with MangoHud and FG, I get stuttering because MangoHud somehow interferes. If I cap them with DXVK_FRAME_RATE, I get smooth frames AND frame generation right at the desired cap.
Furthermore i see this breaking standardized settings e.g. in heroic, also i liked having 1 env var that worked for dxvk and vkd3d. Like others said it makes the most sense to keep a frame limiter at the most core library responsible for rendering or at driver level.
Some games don't start with mangohud for me and mangohud's frame limiter causes noticeable input lag. Using DXVK_FRAME_RATE was always the better option for me.
I really don't appreciate this change and removing stuff just doesn't make sense to me.
Resorting to "external solutions" is just silly.
Many people who rely on the env var and don't check github regularly, will just get confused now.
MangoHUD's frame-limiter isn't all that great to use, it microstutters in cases where DXVK_FRAME_RATE would not and I only want to use gamescope for games who doesn't handle alt-tabbing very well (ELDEN RING, Elite Dangerous, anyone?). I don't want third party tools to become a crutch just to limit my framerate.
This gets my +1, please have this reverted!
For me, MangoHud's framelimiter always introduced additional latency and stutter, regardless of fps_limit_method being set to early or late.
With DXVK_FRAME_RATE, in addition to the obvious usefulness both for a frame cap to avoid wasting resources and for setting up a configuration with the VRR, I have always had a smooth experience, even allowing me to have the possibility of being able to set dxvk and vkd3d at the same time.
GameScope isn't a viable alternative at the moment, imho. In competitive, fast-paced games, it doesn't provide a good experience.
I don't really see the VRR use case to be perfectly honest, I'm running a 144Hz VRR setup myself and just enabling V-Sync gets the job done, not sure what you'd need an external frame rate limiter for. As mentioned in the other thread, the DXVK limiter only works properly in the VSync on scenario anyway since present_wait feedback is useless with mailbox/immediate (which also means that scanout is completely decoupled from app waking up), and when it does work, it emulates late scanout in more or less exactly the same way that hitting display refresh would. It's only going to make a meaningful difference when the limited frame rate is significantly lower than display refresh.
Either way, the primary use case for the built-in limiter is to make games work, not to cater to the 700 different use cases that users may have that all need different kinds solutions. It's never going to have good frame pacing, it's not currently possible to achieve that anyway unless it's done at a compositor level (hence gamescope). It may not incur as much additional latency as other solutions, but it's not exactly minimizing latency either since you'd need some sort of latency sleep for that, which only works in a handful of super simple games that don't even have a dedicated render thread and can fuck up frame pacing in games that have inconsistent CPU timelines.
I don't really see DXVK as a good place for user-facing options. There's a couple that can be useful in some cases and are trivial to maintain (like forcing mailbox over immediate to avoid tearing), but people have dozens of different reasons why they'd want a frame rate limiter (smooth frame delivery, power savings, ...) and the one we have isn't great at any of those.
I'll try to keep this short while providing an opinion as a dxvk user for +5 years. MangoHUD is a stuttery mess and it doesn't really do the job, and GameScope is plain trash. Whether you think the frame limiter is useful or not does not equate to it actually not being useful, sure the implementation can be improved and it is not the best but it does the job and is simple to add without having to add more software that'd only increase the latency.
DXVK is already very streamlined so I fail to see why an option has to be removed when it is not even the default behavior for any use case, and I understand only the env var was removed and dxvk.conf will still work but it establishes that the entire frame limiter will be removed as well, seeing as you haven't denied it, and it's also a breaking change that should not be made just because of a single use case and without any consideration or "to motivate users to move on".
It is ultimately your decision but I wish you'd consider reverting the change, or at least with a disclaimer or deprecation warning.
@doitsujin Hello, I have been a Linux user for a year now, and so far I have never used DXVK_FRAME_RATE. Instead, I use mangohud with the goverlay interface to limit my fps. I have a question for you. I have a 240hz OLED monitor, and in Windows I limited my fps to 237 to achieve maximum fluidity according to this guide https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/ when I had Nvidia. Now I have an AMD RX 9070 XT graphics card and in Linux I limit my FPS with goverlay to 237 and in the game I have vsync off, but I don't know if this is good or adds latency. I see a completely straight line in the frame time (I guess this is good). What is the best way? Is it necessary to limit the fps to -3 fps below my monitor or not?
@doitsujin Hello, I have been a Linux user for a year now, and so far I have never used DXVK_FRAME_RATE. Instead, I use mangohud with the goverlay interface to limit my fps. I have a question for you. I have a 240hz OLED monitor, and in Windows I limited my fps to 237 to achieve maximum fluidity according to this guide https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/ when I had Nvidia. Now I have an AMD RX 9070 XT graphics card and in Linux I limit my FPS with goverlay to 237 and in the game I have vsync off, but I don't know if this is good or adds latency. I see a completely straight line in the frame time (I guess this is good). What is the best way? Is it necessary to limit the fps to -3 fps below my monitor or not?
I was about to ask the same, the general advice has always been VRR + Vsync + (Monitor refresh rate - 3)
I did exactly this in Windows with my RTX 3080, but now I'm on Linux and I have an AMD graphics card, and I don't know what to do here. Maybe this isn't necessary and limiting the FPS to 240 or 237 is enough? Can anyone who knows about this help?
@doitsujin Hola, soy usuario de Linux desde hace un año y hasta ahora nunca he utilizado DXVK_FRAME_RATE. En su lugar, uso mangohud con la interfaz goverlay para limitar mis fps. Tengo una pregunta para ti. Tengo un monitor OLED de 240 Hz y en Windows limité mis fps a 237 para lograr la máxima fluidez según esta guía https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/ Cuando tuve Nvidia. Ahora tengo una tarjeta gráfica AMD RX 9070 XT y en Linux limito mis FPS con goverlay a 237 y en el juego tengo vsync desactivado, pero no sé si esto es bueno o agrega latencia. Veo una línea completamente recta en el tiempo del cuadro (supongo que esto es bueno). ¿Cuál es la mejor manera? ¿Es necesario limitar los fps a -3 fps debajo de mi monitor o no?
Estaba a punto de preguntar lo mismo, el consejo general siempre ha sido VRR + Vsync + (frecuencia de actualización del monitor - 3)
the general advice has always been VRR + Vsync + (Monitor refresh rate - 3)
The question is, why. The only time I can see this being useful at all is when your monitor somehow sucks and there's noticeable stutter or something whenever it bounces off maximum refresh.
If you removed it because it was not good in your eyes and caused many other issues that brought up uneccessary bug reports and complaints then so be it. Your decision.
But please understand,
but people have dozens of different reasons why they'd want a frame rate limiter (smooth frame delivery, power savings, ...) and the one we have isn't great at any of those
Even though it is not great with these, it was much better than other available solutions besides built in-game limiter. This is my experience, though.
but it establishes that the entire frame limiter will be removed as well
... it does?
seeing as you haven't denied it
I haven't denied being behind the Louvre heist either, so I guess that makes me guilty.
On a more serious note, there's an entire category of games that break at high framerates, which is actually why the frame limiter was first introduced... and why it will stay around. If you actually read the discussion on the PR in question, without giving in to sensationalism, you'll find it's a lot more nuanced.
and it's also a breaking change that should not be made just because of a single use case and without any consideration or "to motivate users to move on".
An alternative way of using it exists, and it's fairly simple to switch to it. Change is a normal process and a codebase isn't a museum.
El consejo general siempre ha sido VRR + Vsync + (frecuencia de actualización del monitor - 3)
La pregunta es, por qué. La única vez que puedo ver que esto sea útil es cuando tu monitor de alguna manera apesta y hay un tartamudeo notable o algo así cada vez que rebota en la actualización máxima.
So, on Linux with an AMD GPU and Wayland, what do you recommend, since you know about this stuff? Should I just limit my FPS to 240 FPS or whatever I want and disable VSync in X Game? Or what do you suggest? Nobody knows about this, and an answer would be great.
Again, I personally would just not bother with FPS limiters at all and just enable vsync on a VRR setup, maybe set dxgi.maxFrameLatency=1 (or the corresponding d3d9 option).
Whether this works well for you, I don't know.
the general advice has always been VRR + Vsync + (Monitor refresh rate - 3)
The question is, why. The only time I can see this being useful at all is when your monitor somehow sucks and there's noticeable stutter or something whenever it bounces off maximum refresh.
According to what I can find on the internet, it's to prevent at all costs tearing (vsync off) or frames queuing up and thus causing latency (vsync on).
Also, the formula that is actually recommended (it's used by Nvidia Reflex) is another one: https://www.reddit.com/r/nvidia/comments/1lokih2/putting_misconceptions_about_optimal_fps_caps/
Nuevamente, personalmente no me molestaría en absoluto con los limitadores de FPS y simplemente enable vsync en una configuración VRR, tal vez configurado
dxgi.maxFrameLatency=1(o la opción d3d9 correspondiente).No sé si esto te funciona bien.
So, if I have VRR set to ‘automatic’ in the display settings in KDE Plasma, all I need to do is enable vsync in any game and that's it? Because a couple of months ago, if I enabled VRR, my desktop ran very poorly, but automatic works fine. Is that all I need to do? I understand that it's different from Windows, right?
@doitsujin
I don't really see DXVK as a good place for user-facing options.
At the beginning you were creating DXVK only for yourself to play NieR:Automata - Link to your interview.
But now, 7 years later, you are creating it for the huge amount of users from all over the world. And all your decisions affect them.
If you and your co-workers do not recognize usefulness of all its functions - that is your - developer - point of view.
You MUST focus on the user point of view, give users option to choose, because you are creating DXVK for the people now.
I will give an excerpt from YOUR interview 7 years ago:
GamingOnLinux_Interviewer: Any hopes for the future for DXVK? ...
DXVK_Creator_doitsujin: “It should hopefully fulfil its purpose and make users who currently dual-boot or run some crazy VM setup for gaming switch to Linux as their primary gaming platform, and maybe attract a few new users altogether.
If you are still true to this statement, you will listen to the users and leave all existing user-facing options in place and revert PR#5331. Because now you're pushing away existing and new users from both Linux and DXVK.
if I enabled VRR, my desktop ran very poorly, but automatic works fine. Is that all I need to do?
Yes.
As for the rest of the overdramatized discussion, no, the env var is not coming back, it's already removed in vkd3d-proton as well.
I just don't see much of a point in exposing a bad solution so prominently when alternatives exist that just objectively work better for the vast majority of use cases. All it's going to lead to is bad experiences and complaints that it doesn't fit their use case. Our limiter does one thing somewhat well, and that is running 60 FPS games on high-refresh displays without adding silly amounts of latency. That's what it's designed for. It sucks at everything else.
If you absolutely must keep using it for whatever reason then there's the dxvk.conf method, it's not going anywhere given that we have a million games relying on it already, but I'm no making any promises that the implementation (i.e. the way fps limiting is done) is going to remain the same for all eternity.
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.
To reiterate my point of view on the entire matter (not putting words in anyone else's mouth or anything), just so that everyone is aware of it, this "major issue" you keep throwing about, at times in all caps, is only a major nothingburger.
External tooling as well as regular users are free to continue using the frame limiter through:
DXVK_CONFIG="dxgi.maxFrameRate = 60; d3d9.maxFrameRate = 60", or only one of the two, as an equivalent option. It is not going to go away, there are games that need such an option, that much has already been stated.There's also no reason why this option in particular should get preferential treatment as opposed to the various other config options DXVK provides, all of which have a single env variable to rule them all and in the darkness bind them, namely
DXVK_CONFIG.The fact that its use is not encouraged is the opinion of its author, and it is up to you to value it or not. I, for one, think no one can know better about the limitations at play here than the person who wrote the damn thing. But if you think it works better for your particular use case, just keep using it. It's that simple.
Thank you, my graphics card would shake itself apart trying to run old games without a working frame limiter and running external tools is a no go (and imo shouldn't have been suggested as it only serves to create drama). Sad to see an old option just disappear like this, but as long as there is an option that works it's no big deal.
I hope you have a great weekend.
If many people are telling you that they don't work better or are having issues, I don't understand how you consider that they are objectively better. Everything that you've said so far comes off very tone deaf and it's frustrating because I want to like this project, but when devs refuse to listen to many users, explaining with reason, why your frame rate limiter performs better, it's not a good look. As some others have mentioned before inside this project, and even outside of it, frame rate limiters are very important for power saving, vrr stability, and frame times. Your limiter has always performed best for me. In game limiters and mangohud has not been able to compete this far at all. Not everyone wants to run their GPU at 100% for every game they run. Mangohud breaks my freesync, in game limiters constantly trip LFC, it's not a fun experience and the average user will miss out on this because many guides already explain how to use the env var for the limiter because it already works so well.
DXVK_CONFIGx3 2025-11DXVK_CONFIG="dxgi.maxFrameRate = 60; d3d9.maxFrameRate = 60"x3 2025-11DXVK_FRAME_RATEx9 2025-11DXVK_Cx1 2025-11MANGOHUDx1 2025-11VKD3D_FRAME_RATEx1 2025-11
Greetings.
@doitsujin, since he is an author of PR#5331 - Remove useless features
You decided to remove
DXVK_FRAME_RATEenvironment variable and latency tracker, after user reported an Issue#5330 - DXVK_FRAME_RATE produces unstable VRR Hz counter on monitor compared to MangoHud in which you stated, quote:I find it a little bit hasty decision (literally 1 day between Issue#5330 and PR#5331) to cut both
DXVK_FRAME_RATEenvironment variable and latency tracker solution on account of one specfic use-case - very high FPS combined with VRR display and Mailbox VSync on Wayland.There are MANY OTHER REAL-WORLD USE-CASES where the only thing that works is the DXVK FPS Limiter and, quote:
... is only your point of view.
To prove it - here are the quotes from PR#5331 and Issue#5330 about what other DXVK users think about DXVK FPS Limiter,
DXVK_FRAME_RATEenvironment variable convenience and latency tracker usefulness:... and that is only the ones who wrote at either PR#5331 or Issue#5330.
Also, there are people who downvoted PR#5331 and did not leave any other comments.
Removing convenient
DXVK_FRAME_RATEenvironment variable creates maintenance burden for all Proton forks and Lutris-like applications (and their users) that rely on DXVK - this decision is not user-friendly.So there are many people, who would have liked that you, @doitsujin, reverted PR#5331 and did not consider usefulness of features based on ONE SINGLE ISOLATED USE-CASE.
I encourage all DXVK users that are against PR#5331 to leave their feedback on how they use DXVK FPS Limiter,
DXVK_FRAME_RATEenvironment variable and latency tracker, because if you value these features - you have to prove it to @doitsujin.To DXVK Contributors and Collaborators: Please do not answer for @doitsujin.
P.S.:
@doitsujin and @netborg-afps
Since @doitsujin said that DXVK FPS Limiter:
Can @doitsujin use @netborg-afps implementation of DXVK FPS Limiter with required modifications in order to make DXVK better, espescially for use-case where DXVK FPS Limiter is needed?