If you create a file called dxvk.conf next to the exe or where the dxvk files are placed and then in that file write dxvk.hud = full a hud should appear ingame. Post a screenshot with that on when it happens.

If you create a file called dxvk.conf next to the exe or where the dxvk files are placed and then in that file write dxvk.hud = full a hud should appear ingame. Post a screenshot with that on when it happens.

I did this. This is how 90% of the time the game looks, meaning it has microstutters constantly but I didn't realize until now because it's almost unnoticeable:

And this is how it looks like when the problem I mentioned above:

Those are some shitty frametimes. My smell here is that the nvidia overlay might be doing something sketchy (especially with the number of overlays mentioned, I have chills).
Is anything better if you try to play with a clean boot?

Those are some shitty frametimes. My smell here is that the nvidia overlay might be doing something sketchy (especially with the number of overlays mentioned, I have chills). Is anything better if you try to play with a clean boot?

Already tried both time ago, but no luck.

@Stickend

Might be relevant to your problem: https://github.com/doitsujin/dxvk/issues/5171

Already tried both time ago, but no luck.

Is it possible for you to try with integrated graphics?

Also does this happen with all the available vertical sync settings?

@Stickend

Might be relevant to your problem: [#5171](https://github.com/doitsujin/dxvk/issues/5171)

Already tried that time ago as well, but no luck either. That option worked for Tomb Raider Remastered, because it used OpenGL, but not for dxvk games. That's why I tried it here too, but no luck.

Already tried both time ago, but no luck.

Is it possible for you to try with integrated graphics?

Also does this happen with all the available vertical sync settings?

My CPU doesn't have integrated graphics. And yes, this happens with all available VSync settings and with VSync off as well. It happens no matter what graphic setting I choose. Except if I play with DirectX API, is the only thing that solves it, but it's not obviously the solution. Dxvk should work as intented as it was working fine for me one year ago.

Does this also happen in other vulkan games?
You could try both something like the Quake RTX demo, and I think L4D2 itself with the -vulkan parameter

Does this also happen in other vulkan games? You could try both something like the Quake RTX demo, and I think L4D2 itself with the -vulkan parameter

L4D2 needs dxvk to be used with vulkan, I already have that parameter written. And no, this behaviour doesn't happen with other vulkan games, I already checked time ago. It only happens when dxvk is active.

@Stickend

Edit: Saw the answer.

Seems like DXVK's threading/sync management system creates problems for Windows Scheduler in your case. I observed similar behaviour during DXVK-GPLALL development. The best workaround is to find FPS Limit at which erratic frame pace is not noticeable. And you can try DXVK-GPLALL's low-latency-vrr-x mode - it helps with this particular problem, because it performs the (predictive) limiting at the end of the frame, instead of the start - link with info

On your screenshots of L4D2 you have almost fully saturated 4 GB VRAM and since L4D2 is a 32-bit game, DXVK's VRAM defrag/resource management may play a certain role here too.

Can you provide screenshots with DXVK's HUD of any other game that is 64-bit and behaves the same?

@Stickend

Edit: Saw the answer.

Seems like DXVK's threading/sync management system creates problems for Windows Scheduler in your case. I observed similar behaviour during DXVK-GPLALL development. The best workaround is to find FPS Limit at which erratic frame pace is not noticeable. And you can try DXVK-GPLALL's low-latency-vrr-x mode - it helps with this particular problem, because it performs the (predictive) limiting at the end of the frame, instead of the start - link with info

On your screenshots of L4D2 you have almost fully saturated 4 GB VRAM and since L4D2 is a 32-bit game, DXVK's VRAM defrag/resource management may play a certain role here too.

Can you provide screenshots with DXVK's HUD of any other game that is 64-bit and behaves the same?

There's something peculiar I'm noticing actually. My monitor is 60hz:

When not using dxvk, and when the VSync is off, if the game goes above 60fps, I see screen tearing, which is the expected behavior. But this doesn't happen at all when using dxvk.

It doesn't matter if the VSync is on or off, but there's no screen tearing at all. Yes, the game can go above 60fps because I can see it in the overlay, but there's no visual tearing.

I'm suspecting VSync has a lot to do with this, but I'm not sure how or why, because it doesn't matter of it's on or off, the problem still happens. But it's not normal not to experience visual tearing if the VSync is off and the game is above 60fps.

*sigh*
Can you try dxvk.allowFse = True in dxvk.conf?

sigh Can you try dxvk.allowFse = True in dxvk.conf?

Yes, this produces visual tearing now.

@Stickend

Do you observe issue with dxvk.allowFse = True?

@Stickend

Do you observe issue with dxvk.allowFse = True?

I'm testing. The most interesting thing is that, when a stutter occurs, it finally SHOWS UP how many frames goes it down, instead of staying at 60 fps. It usually goes at 45 or so, although it seems to disappear after 1 or 2 seconds, instead of permanently being there. What I'm gonna do now is try this in conjuction with dxvk.enableGraphicsPipelineLibrary = False and see If I can finally get rid of these random stutters.

It doesn't matter if the VSync is on or off, but there's no screen tearing at all. Yes, the game can go above 60fps because I can see it in the overlay, but there's no visual tearing

This is the reason. When DWM is compositing with GDI Copy, no matter what fps you get, there is no tearing as DWM only takes a complete frame for composition and it forced VSYNC on output. And of course, composition adds latency, and makes you feel laggy.

If you are not sure game is running with DWM composition, use https://github.com/gametechdev/presentmon and put the console on another monitor to see how game is presented to display.

dxvk.allowFse = True will bypass DWM when possible. There is also some Nvidia driver hack to force DXVK using DXGI swapchain, but be careful as it does break some applications if you apply in global profile.

No that cannot be the reason. Millions of people are regularly sticking to it, and that's without frametimes looking like an ECG graph.
Latency and stuttering are two different things.

I assume triple buffering, low latency mode and v-sync are on their default value then in the nvidia control panel yes?

No that cannot be the reason. Millions of people are regularly sticking to it, and that's without frametimes looking like an ECG graph. Latency and stuttering are two different things.

I assume triple buffering, low latency mode and v-sync are on their default value then in the nvidia control panel yes?

Yes, they are. Stutters still occur, but at least they are now properly registered.

Yes, I could have guessed that. Even though it still doesn't make much sense.
DWM might be doing its own v-sync, but it's buffered. If the game is still actually doing 60fps, then there should be no skips. And conversely if there is stuttering, game-wise that should come up as a dip in framerate if it's so prevalent.

Does the problem still occur even if you stay still in-game for a good minute (meaning no inputs, and even no chance of some new shader having to be compiled)?

Yes, I could have guessed that. Even though it still doesn't make much sense. DWM might be doing its own v-sync, but it's buffered. If the game is still actually doing 60fps, then there should be no skips. And conversely if there is stuttering, game-wise that should come up as a dip in framerate if it's so prevalent.

Does the problem still occur even if you stay still in-game for a good minute (meaning no inputs, and even no chance of some new shader having to be compiled)?

That's right. Even if I'm standing still looking to a damn wall, the frame drop occurs.

Of course I'm just spitballing here.. Does it change anything if you play at some stupid resolution like 640x480? Unlocked of course.
(I'm trying to understand for example if we are talking about dropping 1 frame every second, or some fixed ms amount of frames).

DWM might be doing its own v-sync, but it's buffered. If the game is still actually doing 60fps, then there should be no skips.

No. DWM takes completed frame from game in regular basis, and if the frame pace is not stable, it can become an issue. And of course, game does not run at a fixed frame pace, or I would say all modern applications cannot run at a perfectly fixed frame pace.
Consider a special application render in such frame pace: 1ms, 19ms, 1ms, 19ms ... It is 100fps apparently.
If it's on a 100hz monitor and DWM takes frame every 10ms (consider there is another application on same monitor running at very smooth 100fps with 10ms frame time fixed). The first time, DWM takes frame 1, but next time when DWM want to take a new frame, frame 2 is not ready, so DWM can only take old frame 1 again. The third time DWM needs to take a frame, frame 3 is ready so it takes frame 3. See, in this example, frame 2 is totally skipped.
The even worse, DWM is lazy. If there is nothing changed on screen, it does not take frames from buffer. If there is no other application running at same time, then after DWM takes frame 1, it sleeps until frame 2 is ready and let monitor self refresh, then it takes frame 2 after ready. But once DWM takes frame 2 it still need to wait for next monitor refresh to present it. So in both condition, DWM introduces random frame drop and stutter.

This is actually why frame pacing is important. Monitor is a bus that takes passenger in fixed interval, and DWM is the guy who guide people from hotel to bus stop. If no people, this guy just sleeps. And since the time there are new people is not fixed, it may not align with the bus interval, so sometimes two batch of people on the same bus and sometimes the bus is empty. And the ultimate solution is let people call uber directly so no alignment is required, that's how FSE (or DXGI Flip model) works with VRR.

I would suggest you to upload csv from PresentMon, that will help a lot. If you don't have second monitor, just start it in background and run game as normal. Once sample is enough, stop PresentMon and upload the generated CSV file.

Consider a special application render in such frame pace: 1ms, 19ms, 1ms, 19ms ... It is 100fps apparently.

Yes, but then the thing would suck bigly even without the DWM, isn't it?
The only scenario the DWM could make worse is something that has to run at a fixed lower frequency (say an emulator targeting 50Hz or the much more insidious 59.94Hz, on a fixed 60Hz display which you cannot be bothered to downshift) that over time will necessarily have to present a doubled frame. The stuttering isn't present on the rendering layer, but entirely caused by presentation.

Here instead something is obviously interfering with DXVK. Even though a presentmon log (also left4dead2_d3d9.log) is welcome.
EDIT: vsync and DWM can make the already bad matters worse though, so please only try everything already suggested uncapped and with exclusive fullscreen

@Stickend

As I understand dxvk.enableGraphicsPipelineLibrary = False + dxvk.allowFse = True did not fix your issue?

That's right. Even if I'm standing still looking to a damn wall, the frame drop occurs.

That points to the thought that some routine process happens on a loop. It could be some sync process, memory management routine, Windows Scheduler threads management routine etc.

Please provide the next information:

1. What is your in-game resolution and textures settings? On your screenshots of L4D2 you have almost fully saturated 4 GB VRAM and since L4D2 is a 32-bit game, DXVK's VRAM defrag/resource management may play a certain role here too. Try to lower both resolution and textures settings, in order to lower the VRAM saturation, with dxvk.enableGraphicsPipelineLibrary = False + dxvk.allowFse = True settings set, then report back the results of testing.

2. Does this issue happen on not modded map in offline/single mode of L4D2? Checking 1st campaign mission in offline/single mode would be enough.

3. Can you provide screenshots with DXVK's HUD of any other game that is 64-bit and behaves the same?

4. Does this issue happen with the latest development build of DXVK? GitHub Actions Download Link: https://github.com/doitsujin/dxvk/actions/runs/27853115756

Yes, but then the thing would suck bigly even without the DWM, isn't it?

It's not good enough, but if with FSE and VRR it can get some acceptable actual presenting framerate. In modern systems, thanks for P/E cores and so many background applications, this type of jitter is quite common.

And if you disable low latency mode in Nvidia cpl to allow application queue frames, then you can even get perfect smooth experience, at cost of latency.

Update: when the frame drop occurs out of nowhere, if i Alt+Tab to get out of the game, then I come back, the framerate comes back to normal (to 60fps).

But why? why does alt+tab fix the framerate when it stars behaving badly? it's obviously not a performance problem.

Please log the game with presentmon during all these operations, and tell which PresentMode you happened to stumble.

No idea about presentmon nor what PresentMode it is

https://github.com/gametechdev/presentmon

No idea about presentmon nor what PresentMode it is

Then, simply get PresentMon executable from https://github.com/GameTechDev/PresentMon/releases/tag/v2.5.1 (the 900k executable).

Run it with admin privilege and just minimize the terminal.

Then run the game, reproduce the stutter.

Close game, close terminal window, upload the csv file in same folder, that's it.

No idea about presentmon nor what PresentMode it is

Then, simply get PresentMon executable from https://github.com/GameTechDev/PresentMon/releases/tag/v2.5.1 (the 900k executable).

Run it with admin privilege and just minimize the terminal.

Then run the game, reproduce the stutter.

Close game, close terminal window, upload the csv file in same folder, that's it.

I will do this. But the stutter (frame drop actually) it's not something I can reproduce. It happens at random. I can be playing for an hour with no issues, or it can happen 10 minutes later into gameplay.

I'll still upload the CSV file, even if it takes a lot to happen.

It will be interesting to see if the alt-tabbing entails any change there.

PresentMon-2026-07-11T165407.csv

It wasn't such a heavy framedrop this time, but I did the alt-tabbing and came back to the game to see if it got better (which it did), then I closed PresentMon, so I guess what you guys are looking for should be at the end of the document?

Hope you can find the answer here.

PresentMon-2026-07-11T165407.csv

It wasn't such a heavy framedrop this time, but I did the alt-tabbing and came back to the game to see if it got better (which it did), then I closed PresentMon, so I guess what you guys are looking for should be at the end of the document?

Hope you can find the answer here.

Sorry for late analysis.

I can confirm your game is having issue with GDI copy. I can see Composed: Copy with GPU GDI in csv for the game process.

So, I would suggest to enable FSE or try nvidia profile inspector tweak to force DXVK run on DXGI swapchain, which should fix your issue.

Tbh composed with gpu gdi copy shouldn't result in this disaster, and it's especially sketchy that alt-tabbing would fix it.

Tbh composed with gpu gdi copy shouldn't result in this disaster, and it's especially sketchy that alt-tabbing would fix it.

So what do you propose?

Tbh composed with gpu gdi copy shouldn't result in this disaster

It depends on resolution. The higher resolution, the higher copy cost. Based on my test, 4k is enough to reveal the difference and under 6k the difference is really huge even with flagship GPU.