The swapchain part, yes. That just skips rendering desktop window content, but everything still goes through like usual on a single plane. DXGI flip still goes through the DWM( https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model) it just doesn’t have any more “work” done on it while at that step. But there’s a ton of caveats to it all. Without turning this into a 20 page essay here’s some key parts to note:
-
DirectFlip with multi-plane overlay (MPO): Your swapchain buffers are within some hardware-dependent scaling factor of your window dimensions. The DWM is able to reserve a dedicated hardware scanout plane for your application, which is then scanned out and potentially stretched to an alpha-blended sub-region of the screen.
Windows 10/11 current builds and the latest Nvidia drivers use MPO. So even if you set your program to use the flip mode, it’s still not going to benefit you at all because it’s all going to be ran through the MPO compositing systems.
Flip model swapchains have a few additional requirements on top of blt swapchains:
1. The buffer count must be at least 2.
2. After [Present] calls, the back buffer needs to explicitly be re-bound to the D3D11 immediate context before it can be used again.
3. After calling [SetFullscreenState], the application must call [ResizeBuffers] before Present.
4. MSAA (multisample anti-aliasing) swapchains are not directly supported in the flip model, so the application will need to do an MSAA resolve before issuing the Present.
I highlighted some important parts to note. This article is dated though and needs to be updated. Also, it’s completely leaving out the fullscreen optimizations for fullscreen borderless windowed mode, which is almost the exact same performance as FSE, minus a very tiny bit of overhead. Talking like 1% differences at best.
The last time I checked, it still worked, but that was a handful of months ago. You just have to periodically make sure it’s still disabled. I think new drivers or occasional windows updates will flag it back to enabled.
I have thought about using diagnostic capture softwares to dig into the shader code being ran, but I know it’s a grey area for potentially getting banned because they might ban me for “reverse engineering” even if I don’t use it to make anything or exploit anything.
My guess is that there’s something going wrong in the way Blizzard or DX12 is handling using the CPU to batch draw calls, that are then sent to the GPU to be rendered. Very very few games have this DX12 flickering issue. The object flickers seem like they are hitting some kind of null/NaN/zero state, that’s causing the GPU to render them black. Maybe it’s some kind of async issue where something isn’t finishing in time and the rendering thread says “I don’t care if you’re not finished, screw it, we’ll render without you anyways.”
OHHH and try this real quick: Hit Windows+P and set it to single monitor. See if that fixes the problem. If it is tied to MPO issues, this might help get to the bottom of the issues. A lot of people will have mismatched refresh rates on displays and it could be that the DWM is getting out of sync with stuff trying to line up frames for the displays.