Kaldaien, you can enable the fullscreen borderless upscale without any latency if the game already starts its window at desktop resolution, yes?
And if it doesn’t, you can untick the option and then set the resolution yourself with centering if needed?
No, any upscale operation done using windowed mode prevents you from drawing directly to the DWM. That will add at least 1 frame of latency while the DWM compositor activates and rescales the window’s image.
1 Like
Ubisoft’s DRM / Anti-Debug actually breaks DXGI Waitable Swapchains 
One of their anti-debug tricks is to replace calls to CloseHandle (…) with a function that crashes when you call it. They then monitor all calls to CloseHandle (…) to see if the exception is caught or uncaught. Said exception is caught when there is a debugger attached, it’s uncaught and would completely crash the software when no debugger is attached.
I need to close the wait handle on the SwapChain, or, well, this happens:
When your deliberately introduced software defects to make debugging a nuisance can do this to my framerate limiter, it’s time to admit that it has overstepped its bounds and is harming customers. I am certain that their tricks are breaking other software too, not just mine.
In regards to that, would it even introduce 1 frame of latency if SK could set the window client region and swapchain buffer up in such a way that the GPU scanout hardware performed the actual scaling?
If I understand it correctly, that would prevent DWM from scaling it and introducing latency?
- DirectFlip with panel fitters: Your window client region covers the screen, and your swapchain buffers are within some hardware-dependent scaling factor (e.g. 0.25x to 4x) of the screen. The GPU scanout hardware is used to scale your buffer while sending it to the display.
With windowed flip model, the application can query hardware support for different DirectFlip scenarios and implement different types of dynamic scaling via use of IDXGIOutput6:: CheckHardwareCompositionSupport. One caveat to keep in mind is that if panel fitters are utilized, it’s possible for the cursor to suffer stretching side effects, which is indicated via DXGI_HARDWARE_COMPOSITION_SUPPORT_FLAG_CURSOR_STRETCHED.
Furthermore, applications should leverage IDXGIOutput6:: CheckHardwareCompositionSupport to determine if they need to scale the content before presenting it, or if they should let the hardware do the scaling for them.
(from For best performance, use DXGI flip model - DirectX Developer Blog)
That’s all to do with the Multiplane Overlay API. It doesn’t automagically happen, it takes a bit of work and requires writing DirectComposition code. It’s on a TODO list of mine, but no idea when I’ll get around to it.
1 Like
This list of broken things seems complete enough now…
Now… how to bring this to Ubisoft’s attention without something horrible happening? The last time I fixed something for Ubisoft, I got a system-wide ban on Steam for malware.
My stance on their DRM and anti-debug, evidently, makes me malicious 
. But I’m pretty firm on this; Ubisoft’s got to do more than fix their game, they need to stop being so hostile w/ their customers. Some of these things are broken precisely because they have so many layers of self-destruct in all of their software.
And how about when using G-Sync, same thing?
Hmm does anyone if it’s normal to get stuttering/skipping in flip mode in both fullscreen, and borderless when game bar is recording? CPU/GPU usage is fine.
EDIT: seems like it’s because some overlay is shown while recording, i need to find a way to disable it.
(Final?) Test Release of SK 0.11.1
+ Corrected near-black noise when processing sRGB LDR images for HDR tonemapping
--------------------
* Care must be taken when using sRGB gamma if the input image may have negative
color values, because sRGB gamma's x*x*x property preserves negative values.
--------------------
+ Added support for HDR10 image processing so that SK's HDR widget can control
games with official HDR support now (usually does a better job :P)
>> When running a game with official HDR support, most are HDR10 and you
will need to run SK's HDR widget in HDR10 Passthrough or Filmic mode,
Expect to target ~10,000 nits because games that use HDR10 don't
actually bother to encode luminance levels into the signal.
+ Boosted black level when using ACEScg tonemap mode for more shadow detail
+ Fixed issues preventing Ys8 from starting (again...)
+ Fixed a bunch of anti-debug problems in various Ubisoft games
+ Added more details to latency monitoring in framepacing widget
+ Framerate Limiter now defaults to Screen Refresh if no limit is set,
for the framepacing widget's scale
+ Added Gamut Overshoot Visualization
+ Added HDR Overbright Bit Visualization
This should improve automatic HDR retrofit black performance significantly, and also add support for visualizing and correcting HDR in titles that have official HDR support (e.g. Watch Dogs Legion). Please make sure you reset any HDR widget image profiles because gamma, contrast and saturation have different zero-points now.
SpecialK32.7z (6.3 MB) SpecialK64.7z (7.6 MB)
3 Likes
Yep, that’s normal. It causes the DWM compositor to enable. You can also see added frames of latency because of the game bar.
can you post this update with fix for uplay games? wanna try this with ac odyssey/origins and the crew
Huh? It’s already posted.
Use the HDR10 ACEScg (Double Rainbow All the Way) tonemap mode for those engines.
oh thanks, I thought it had to be a special version with the fix that you shared earlier
Hah… I just found out that the process I use for HDR tonemapping is roughly the same thing Unreal Engine does when you turn on its HDR in the command console a game may or may not make it easy to access.
Both solutions use ACES Filmic tonemapping, and that’s practically all that Unreal Engine does when it comes time for HDR. That’s I guess, why, it’s as simple as changing a console variable to turn HDR on and doesn’t require any real color grading.
Don’t know if Unreal Engine 5 does anything more sophisticated, but this definitely explains why the ‘HDR Overbright Bits’ visualization lights up like a Christmas tree in Unreal Engine games, they’re designed to leave that information in the framebuffer because they more or less work the same way SK does (just with UE having a less precise framebuffer image format, sadly).
I feel like with every new update configuring HDR gets more complicated and the end result looks worse than before. Before I would just have to adjust 1 or 2 things and the image looked great in my eyes. What shpuld we aim for to get a good HDR image ? I’m reading about avoiding the “bright pink pixels” and stuff like that. Would it be possible to get a reference picture or something like that ?
There’s a few more options and I think you also have to set it for sRGB or scRGB and pass-through modes if the game itself can do HDR which I assume is something that Assassin’s Creed Odyssey has to be tuned against now going by the above results.
Maybe game HDR to enabled and then configuring it through the widget in SpecialK.
This from the above quote by Kaldaien.
The results get better but the setup and tweaking becomes more complicated until the user becomes familiar with it plus I would expect the user to not be immediately aware of what HDR the game itself is doing and what format the game is rendering through so it at worst becomes trial and error testing a few different settings.
Or having to disable flip model which introduces having to restart the game as well.
Don’t have the proper HDR hardware to give most of this a go so I can’t say much on it or give a good answer.
EDIT: Think it’s a breaking change from some of the earlier versions and presets too for some of the settings and how these apply.
It’s closer to a full on calibration suite and you get a lot of options and tools like the histogram and overlays and all sorts of ways to compare and check and get the settings right once the correct options and modes are set.
Pretty advanced and some really good results I would imagine but a bit more work to calibrate or set up at least initially getting used to it all. 
I don’t know what a perfectly calibrated HDR image should look like and therefore I need some help to guide me in the right direction.
I know that for every game the configuration process is different but a baseline would be nice.
Yeah the only thing I hear is to calibrate against a bright area like the sun or sky box that’s going to be the peak brightness and base but then there’s color balancing and modes plus your own hardware capabilities and it quickly becomes a bit more complicated.
The earlier images Kaldaien showcased are for aiding in this setup so you can use the histogram and other data to get immediate real-time feedback which is also a lot more in-depth than merely adjusting towards brightness.
That’s what the XBox app is updated to handle far as I know but on a closed system where it’s intended to be done a certain way against PC and separated modes and implementation and wildly varying results yeah.
Hopefully once he’s online Kaldaien can provide a better answer and once 0.11.x itself is ready the wiki, PC Gaming hub and other resources will have the documentation and information to get started plus for the PC Gaming wiki you could then have settings that would be a good baseline which can then be calibrated from for brightness and gamma once the main bits per channel and HDR settings are covered for.
You cannot use a 1/2 gamma power and get correct colors, especially not in HDR10. Set that to 1.0
As for the UI glow-through, I suppose I should do something about that. SK’s internal HDR doesn’t ever go that aggressive with dynamic range to be in a position where the scene underneath the UI is that much brighter. I know how to fix this, I just never have had the need to do it