nVidia GPU Scheduling (Windows 10 2004) heavy flickering

[donizettilorenzo]

Heavy (really heavy) flickering in Unreal Tournament (469 beta patch, classic D3D(7) renderer) using this wrapper AND GPU scheduling on lastest nVidia drivers.

Disabling the scheduling -> No flickering

[narzoul]

I just update the experimental release. Please check that and also v0.2.1. Do both of them have this issue? Are you playing in windowed or full screen mode? What are the flickers like? Is it a full screen flash, or does it only affect parts of it?

[donizettilorenzo]

Fullscreen flashes, like low refresh rate in old CRT screen monitors ! Will try the new version!

UT supports only the DDRAW "classic fullscreen" of Win98/WinXP era. So your wrapper translates to borderless fullscreen or fake fullscreen?

[donizettilorenzo]

0.2.1 does NOT have the issue.

[donizettilorenzo]

But 0.2.1 creates a "quit freeze" while exiting UT (game can't terminate). Lastest WIP has the "low refresh rate"-like flashes issue but the game can terminate correctly.

[Syst3mSh0ck]

I don't believe the GPU Scheduling API is stable. The latest changelog from nvidia acknowledges several problems with the API as follows:

Video playback on the secondary display lags/freezes while playing a game on the primary display if Hardware-accelerated GPU Scheduling is enabled [200586262]

[Divinity Original Sin 2 - Definitive Edition]: The game experiences low performance when hardware accelerated GPU scheduling is enabled. [3009631]

Microsoft will need to work with GPU ISVs to iron out the bugs I guess.

[donizettilorenzo]

Of course, just reporting the issue! Not your fault!

[narzoul]

I don't have the hardware for testing this. Can either of you build DDrawCompat and use git bisect to figure out which commit introduced the issue between v0.2.1 and the current experimental release? If not, I can also provide the builds here, if either of you are willing to test them. It will be about 7 builds to test.

[donizettilorenzo]

Please post here the builds and I'll test them :D

[narzoul]

Thanks! Actually, before we get too deep into that, could you also attach the logs from the ReleaseWithDebugLogs build in ddraw-debug.zip of the current experimental release? Try to keep it as short as possible, less than 1 second of runtime is enough after the problem starts showing, then just close the game in the fastest way possible (Alt+F4?).

I'm also attaching the first build to test from git bisect, just let me know if it has this problem or not (or if it's not testable, e.g. just crashes): ddraw-7856637.zip

[donizettilorenzo]

Here SOME seconds (until the flickering in the intro sequence)

DDrawCompat-UnrealTournament.zip

[narzoul]

Ah, that's actually really helpful. It looks like it's not calling D3DKMTPresent from pfnPresent1 anymore. I'm guessing it would call D3DKMTSubmitPresentToHwQueue instead in this case, which isn't hooked. I'm not really planning to support it either, hopefully it can be forced to use the old function instead.

Here's an attempt to do that by overriding the reported runtime/driver WDDM versions. Not sure if the driver will like it, I guess there is only one way to find out. Please test it. :)

Patched version, based on current experimental release (b8bff744e544ed428f1293ef9630b74dc2a0784d): ddraw.zip

And the diff I built it with:

diff --git a/DDrawCompat/D3dDdi/Hooks.cpp b/DDrawCompat/D3dDdi/Hooks.cpp
index b8c81c3..b497a4e 100644
--- a/DDrawCompat/D3dDdi/Hooks.cpp
+++ b/DDrawCompat/D3dDdi/Hooks.cpp
@@ -49,10 +49,20 @@ namespace
    {
        D3dDdi::ScopedCriticalSection lock;
        LOG_FUNC("openAdapter", pOpenData);
+       if (pOpenData->Version > D3D_UMD_INTERFACE_VERSION_WDDM2_0)
+       {
+           return LOG_RESULT(E_INVALIDARG);
+       }
+
        D3dDdi::AdapterCallbacks::hookVtable(pOpenData->pAdapterCallbacks);
        HRESULT result = g_origOpenAdapter(pOpenData);
        if (SUCCEEDED(result))
        {
+           if (pOpenData->DriverVersion > D3D_UMD_INTERFACE_VERSION_WDDM2_0)
+           {
+               pOpenData->DriverVersion = D3D_UMD_INTERFACE_VERSION_WDDM2_0;
+           }
+
            static std::set<std::wstring> hookedUmdFileNames;
            if (hookedUmdFileNames.find(g_hookedUmdFileName) == hookedUmdFileNames.end())
            {

You can use the regular Release version from the zip file for testing. If it doesn't solve the issue, please use the ReleaseWithDebugLogs version instead and upload the log again.

[donizettilorenzo]

No luck : - ( Here's the new log

DDrawCompat-UnrealTournament.zip

[donizettilorenzo]

ddraw-7856637.zip

This one has no flickering issue. Please the next!

[donizettilorenzo]

Just putting here: https://devblogs.microsoft.com/directx/hardware-accelerated-gpu-scheduling/

[narzoul]

Thanks, but I think there is no need to continue with the bisect. The logs were sufficient. I'll have to rewrite the presentation handling to not depend on pfnPresentCb/D3DKMTPresent. Maybe I'll have something testable again this weekend.

[donizettilorenzo]

Any news?

[narzoul]

I didn't have time to fix it. Maybe this week, maybe not... we'll see.

[narzoul]

Didn't do a lot of testing, and of course I still can't actually test GPU scheduling itself, but hopefully the latest experimental release fixes the issues with it.

There is also a hefty performance boost in Unreal timedemo, not quite sure why, but it doesn't seem to have any negative side effects, so I'm not complaining.

[donizettilorenzo]

Working perfectly in Unreal Gold + Oldunreal Patch 227i (D3D7 renderer) and UT 459 beta (D3D7 renderer) :) Of course with Hardware accelerated GPU Scheduling.

Thanks man, much appreciated!

In the original Nali Castle FlyBy timedemo (-nosound) @1920x1080 (and maxed out quality for D3D7) I got 523 FPS with a Radeon RX 570 and 510 FPS with a GeForce 1050 Ti (the system with Hardware accelerated GPU Scheduling ON )