Special K v - Framerate Limiter Stuff

 + Added "Drop Late Frames" (DXGI Flip Model) to allow rendering at rates > Refresh
    ( Without Triple-Buffering's normal Latency ); Default = ON
 + Added "Limiter Enforcement Policy" to allow users to pick between smooth / low latency
 + Removed references to "Adaptive Tearing," because the feature was removed a long time ago.

 + Added a new "Ultra Low Latency" mode to D3D11 SwapChain settings if you turn
     on Flip Model and engage Special K's Framerate limiter.

   >> This limiter mode has the potential to cause stuttering if your system is
        barely hitting its framerate target (which needs to be Refresh Rate)

 + Waitable SwapChains have no configurable duration anymore, they are ON or OFF.
 + Fixed issues that prevented using Flip Model in Cross Code and Disco Elysium

     Download Special K v

Source Code (v



Additional things to note…

1. Turning on “Drop Late Frames” will prevent CapFrameX from guessing latency.

It was never terribly accurate to begin with, but if you don’t turn that off prior to taking measurements, it’ll just come back with all 0s :slight_smile:

2. There are now two settings in the control panel for latency; one more than there really ought to be

The D3D11 Swapchain settings for “Ultra-Low Latency” are actually a combination of multiple settings, nothing that an educated user could not configure themselves

The framerate limiter latency settings are unique settings.

3. The “Drop Late Frames” option has the potential to reduce input latency

Since CapFrameX cannot measure latency while it is in-use and NVIDIA hasn’t sent me a latency tester kit, I’m not going to comment on how much latency (if any) the feature reduces … it’s on by default BTW :slight_smile:

4. Most of this stuff applies only to D3D11 and D3D12, Vulkan/GL/D3D9 don’t see any real benefits.

Just FYI, to everyone who grabbed the update before this post …

SKIF was using 10x as much CPU as it should have been (DXGI stuff causing rendering at unlimited framerate) :wink: I silently re-packaged a release with the fixed version of SKIF and uploaded. Probably worth nabbing.


What’s so special with “Drop Late Frames” anyway? Wasn’t that basically the behavior when using flip discard with more buffers than 2 ?

No, Flip Discard just means that after a finished image is handed off to Windows, Windows is allowed to draw on top of it :slight_smile:

In other words, it means, “I’m done with this frame, and I don’t want its image back after it’s displayed.” This then allows stuff like popups and volume control to draw their overlay without any performance penalty.

“Drop Late Frames” prevents sequencing the FIFO Queue, it is DXGI_PRESENT_RESTART.

Restart removes all queued buffers and makes the current buffer the one that displays next.

Truth of the matter is, SK has defaulted to using DXGI_PRESENT_RESTART for almost its entire existence. I only disabled it when doing latency testing, and then I thought rather than simply re-enable it hard-coded, it should be a config option in case anyone else wants to use CapFrameX for latency tests.

I think a surprising amount of my article on framepacing is going to have to cover the swapchain; I have a good all-around framerate limiter, certainly better than RTSS’s, but to get the most out of it, you have to understand DXGI / Vulkan’s swapchain.

GL doesn’t have a swapchain per-se, and D3D9 doesn’t have enough tuning knobs.

Not sure how to do this for an open source framerate limiter; it’s clearly going to be tied heavily to Windows and on top of that, with a strong bias toward D3D. Maybe I can get some feedback from the author of DXVK – we’ve spoken a few times :slight_smile:

Could I ask what the recommended configuration for Persona 4 Golden is with this release? I recall to get past the whole ‘blurring’ issue you had to do a thing where you had the game render at twice the refresh rate of your monitor. I don’t precisely understand the logistics, but it seems like these changes would have an impact.

Also, that reminds me, is having changes made through the D3D11 Render Mod Tools persist through closing/restarting still planned?

Do you mean changes to “Constant Buffer” values? I really do not think that is all that practical, I have a few mods that dynamically feed new Constant Buffer data into shaders to alter post-processing and so forth (of which the Motion Blur bypass is one). But it is extraordinarily expensive performance-wise to do this as a general purpose feature.

3DMigoto’s approach is more practical, it just disassembles the shader and hardcodes new values. I do not plan to re-invent that wheel :slight_smile:

As for eliminating motion blur the brute-force way (rendering at 2-3x your display’s refresh), it’s marginally effective at best.

What I settled on was clearing the accumulation buffer to a constant value every frame. The game’s lighting model consists of multiplying the current frame by the previous, which is where the blur comes from. I don’t think the engine ever set out to create motion blur, it’s just a consequence of the way lighting is faked.

I’m not familiar with whatever you’re talking about here. It sounds like there’s a better solution than using SpecialK to fix Persona 4 Golden’s issues?

Which only makes this part more confusing… are you saying just running SpecialK on Persona 4 Golden with any configuration automatically fixes it?

3DMigoto is used extensively for shader tweaking in among other efforts NVIDIA 3D Vision unofficial compatibility and also for UI and HUD element toggles or effects like motion blur, film grain, chromatic aberration and more.

It dumps the shader data which can then be edited and re-injected in a more thorough way than what SpecialK allows for in this regard.


Doesn’t seem to have been updated in a while though but should work fine for D3D9 to D3D11 although while I know of the utility I don’t use it myself so I can’t say much on how to use it. :slight_smile:

Oh, I see. Is a good configuration for Persona 4 Golden posted up somewhere?

Not that I know of, Nexus has a mod network for some games but for this one it was gamepad button icons and a save editor and little else.

Not entirely sure what would be needed here in this case either, sounds like a simplified lighting model and a single shader effect with multiple purposes and side effects from how it’s utilized so just editing some of the values in example the strength of the effect it would reduce the overall motion blurring but would also lower or eliminate the shaders effect on much more in the game.

Separating just that pass or function might be a more extensive shader overhaul as a result and that’s without hopefully having to change other things too.

For increasing performance and that route DXVK could work.


This is a translation/wrapper layer from D3D(DirectX9 to DirectX11 for now.) over to Vulkan with the little side effect of potentially removing certain API bottlenecks or non-standard behavior and issues even on Windows.

Main project page is here.

And the newest compile from the code commits can be found here.
(Minus the last five commits since that automated build failed so the three from that commit and the two latest from today.)

DirectX VK I don’t think is entirely SpecialK compatible though as SpecialK doesn’t support native Vulkan though since DXVK translates from D3D to VK it’s possible the global injection process still works but maybe not for all of SpecialK’s functionality so that would be the trade-off here.

Don’t know what the games framerate is capped to if anything, 60Hz would make 4x to 240 but a 120Hz would be a 2x and diminishing effect plus framerate will be variable so some scenes could run worse than these example images from Meta Council show.

EDIT: DXVK isn’t needed in the first place if you can hit a 2x uncapped framerate over the monitors native refresh rate on it’s own with enough hardware or any major bottlenecks overcome by said hardware though D3D9 has some API limitations that I don’t know how well you could brute force and before it shifts to a more heavily CPU bound limitation instead.

I use it a lot but I’m on AMD and Navi10 doesn’t scale well for D3D9 though it’s gotten better, surprised to see how effective it can be even on NVIDIA though and that also includes some D3D11 examples.

“How was this coded.” And then that gets answered looking at the lengthy issue tracker for DXVK, quite a insight even if just a simpler one into some of these assorted problems and issues with some titles ha ha.
Persona 4 Gold PC from memory though primarily runs into multiple scenes with several draw call heavy operations going on which exceeds even D3D11 recommended limits here in addition to D3D9 as a more single core bound API CPU wise as a secondary bottleneck issue as well here.
(Patches have helped a bit with some of the other problems so that’s a good improvement from the launch state.)

Unfortunately I vaguely recall a discussion on the Steam forums where Kaldaien suggested using DXVK, but someone tested it and found that it didn’t work well for Persona 4 Golden for some reason.

This version of the mod doesn’t seem to work for me. The program is running, the services are running, it’s showing properly in Task Scheduler, but it just doesn’t show up in any of the games I launch; the previous versions worked fine after some tweaking

EDIT: Just tried rollbacking to previous versions, from 47 to 45 and… all of them are broken now. An issue with the software branches, perhaps?

So how does this work compared to the old SKIM tool, the one where you select your game and install the “product” from there. I cant seem to figure this one out. Currently I was trying to use this with Tales of Zesteria, and when opening the menu with ctrl shift backspace, I see none of the options that the old tool offered and came with when installing that tzfix from it. Also it doesn’t seem to auto install/run the fix, as I noticed im locked at 30fps in game when the fix pushes it to 60 when using the old SKIM. What am I doing wrong?

Use SKIM to install Special K for older games. SKIM installs the game-specific versions of Special K that is known to have the highest compatibility with those specific games. SKIF, however, relies on injecting the very latest version of Special K, which more often than not isn’t as compatible with those older games in the same way as the old versions of the mod due to multiple changes made to Special K’s codebase over the years.