I think because I automatically handle sRGB conversion now. The game wants an sRGB framebuffer, so I have to intercept and change the format of any RenderTargetView and ShaderResourceView that the game creates for rendering into / reading-back the swapchain backbuffer.
Earlier versions of Special K couldn’t do that, so if you’re comparing the behavior of those versus any other solution for forcing Flip Model, earlier SK is probably the wrong behavior.
Hmm i tried a way older release ca 2015, and it has the same behavior with the game getting all dark in flip mode, i was talking about microsoft’s solution to flip mode as it was in windows 1709 not older SK versions, maybe MS is doing non-standard stuff to get it to work?
Did you test a version of Special K newer than about 0.11.0.44 or so? This change is relatively recent, having to do with HDR stuff I was working on. sRGB should just work correctly (even in SDR) now when forcing Flip Model on in most games.
0.11.0.49 was linked to a few posts back:
Yeah i’m pretty sure i have that version of the dll file installed.
I don’t know what the problem is then, I cannot reproduce it. I know it used to work that way, but got fixed at some point for me.
Holy crap, 12 FPS capped w/ RTSS:
SK:
So, the latency is > 4x higher with RTSS, and RTSS apparently doesn’t do very good with small numbers either because 14 FPS and 12 FPS are equivalent in its mind 
Really good test here. You can feel the difference between 150 ms and 650 ms I don’t care how old and close to death’s door you are. There’s 12 FPS without a limiter (unplayable), 12 FPS with RTSS (unplayable) and 12 FPS with SK (unpleasant, but a completely different experience).
According to presentmon the game in borderless mode is in hardware composed: Independent Flip in windows build 1709 while specialK still reports the game as bitblt, and DXGI_FORMAT_R8G8B8A8_UNORM_SRGB.
Isn’t Independent Flip, and flip mode the same thing though?
Independent Flip is only possible with a fullscreen borderless window
Hmmm presentmon is still reporting Independent Flip in fullscreen though, is it possible to force Independent Flip without changing DXGI_FORMAT_R8G8B8A8_UNORM_SRGB to DXGI_FORMAT_R8G8B8A8_UNORM, maybe a override somewhere in SK?
i want to check if this maybe fixes it as that combination seems be the one windows 1709 build uses.
It’s possible to do that at the driver level, but the DirectX runtime won’t allow it and will fail to create the swapchain if you leave the format _SRGB with a flip model presentation effect.
Oh, so the reason it works on that windows build is due to it being at a lower level than DX, too bad… i really wish i could get it working.
OS bug I think.
EDIT: Oops.
https://www.reddit.com/r/Windows10/comments/c5ahfc/bug_dx9dx11_games_do_not_enter_independent_flip/
Hmm seems according to that reddit post that they disabled it for compatibility reasons, and want to in the future allow us to whitelist games for that feature, so in MS time probably 2021-2023 if enough people want this feature,
Probably for the better. There can be a ton of compatibility problems, the simpler solution is to go smack some sense into developers like Unity to start using modern graphics APIs.
Unity now supports Flip Model, but it’s not enabled by default and they don’t explain to developers using their engine why they should enable it.
Honestly the only games i seen use flip mode is DX12/UWP titles, even vulkan in those games i played that has it had problems with DWM related stutter in multi monitor scenarios, you don’t even need a monitor with a different refresh rate, as i have DWM related stutters with only 60hz + 60hz setup.
MS really needs to force developers to use it…
I’m still not sure exactly what that issue is, despite having seen people talk of it over multiple years now…
Only stutter-related issue I experience is when Nvidia’s drivers decides that the secondary monitor (regardless of refresh rate) should follow the same refresh rate of the primary G-Sync enabled monitor.
It even does this with the secondary monitor being a non-G-Sync monitor – if the primary monitor runs at 3 FPS/Hz, then the second monitor will also only update the image on the display at 3 Hz.
I’m pretty sure that has nothing to do with NVIDIA. The only way the DWM can draw at two different rates is if the software it is composing has that new Tearing flag enabled. That allows the DWM to change its internal composition rate.
Wasn’t there a problem with Hardware Accelerated GPU Scheduling and multiple displays too unless that’s been fixed?
NVIDIA has it supported now but AMD’s taking their time implementing it outside of a by this point a very outdated branch of the May 2020 driver release. (20.5.1 with GPU scheduling support.)
Latest updates for 20H1 and 20H2 I think also improved refresh rate variance across multiple displays and how that’s handled but I’m not 100% on how VRR or G or Free sync manages with this maybe more so with the varying panels and firmware updates here like some flickering issue with the Samsung Odyssey and I think one of LG’s recent models had a upcoming Ampere GPU compatibility firmware fix which might be out by now.
That flag have seemingly almost always been enforced with G-Sync enabled in most games I’ve tested (in only a few were the flag not already applied on the swapchain), and it have had no effect on the issue for me… 
That’s because Microsoft describes that flag completely wrong.
It’s not about tearing in a single application, it’s about the DWM being able to invalidate the results of other windows to meet changes in rate of the foreground window.
Normally, all applications are competing for a place in the DWM compositor’s flip queue and they all have to be composed at the same rate. Tearing lets the DWM adjust its composition rate to match the foreground window.
