DXGI and non-vsync/tearing support

[mark_k]

One of the recent commits to Dolphin (GameCube & Wii emulator) was D3DBase: Support the "allow tearing" DXGI flags.
That led me to read about DXGI on MSDN.

Could WinUAE use this to bypass the Windows 10 DWM forced-vsync behaviour? On my system with AMD graphics card, whatever I set display type (windowed/full-window/full-screen) or buffering (none/double/triple) to, it seems vsync is always forced. By which I mean, each Amiga frame is either shown or skipped entirely. So when running a PAL demo scrolling is juddery with no glitch line.

Without forced vsync, assuming your PC desktop is at 60Hz, run WinUAE in NTSC emulation without vsync and run a demo which scrolls smoothly (e.g. PCT-ScrollDemo), you should see a slowly-moving horizontal glitch line because the emulated Amiga frame rate doesn't exactly match the PC desktop refresh rate. [Running PAL emulation the glitch line would move much faster.]

Also, the way WinUAE currently sets up full-screen mode isn't really exclusive; if I press Vol+/- buttons Windows shows its volume OSD.

By comparison, some other programs do seem able to achieve true/exclusive non-vsynced full-screen mode. The Wii U emulator Cemu is one. In its full-screen mode, when I press Vol+/- the OSD doesn't appear, and the display isn't vsynced since I can see tearing if I move the camera in-game. Tearing support also allows a non-vsynced image in full-window mode. Dolphin shows tearing (when its vsync option isn't used of course) in both full-screen and borderless full-window modes.

Also, there's the DXGI flip model which is supposed to be more efficient since there is less copying of data by DWM.
Variable refresh rate displays has code related to tearing support.
The DXGI_SWAP_CHAIN_FLAG enumeration page says this about DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING:
"Tearing support is a requirement to enable displays that support variable refresh rates to function properly when the application presents a swap chain tied to a full screen borderless window. Win32 apps can already achieve tearing in fullscreen exclusive mode by calling SetFullscreenState(TRUE), but the recommended approach for Win32 developers is to use this tearing flag instead. This flag requires the use of a DXGI_SWAP_EFFECT_FLIP_* swap effect. To check for hardware support of this feature, refer to IDXGIFactory5::CheckFeatureSupport. For usage information refer to IDXGISwapChain::Present and the DXGI_PRESENT flags."

[mark_k]

Something which could be related to being unable to get non-vsynced (with-tearing) graphical output...

When the emulation window is active, if you hold Alt and press Tab, the "switcher box" which appears is the old-style classic theme one with small icons. However if the emulation window isn't active, doing that shows the new switcher with larger thumbnail images of each window.

The classic-style switcher also appears on Alt-Tabbing when you have the settings window open (and activated). It doesn't when the log window is active.

[Toni Wilen]

Originally Posted by mark_k

Also, the way WinUAE currently sets up full-screen mode isn't really exclusive; if I press Vol+/- buttons Windows shows its volume OSD.

You sure it isn't some 3rd party volume osd that only works in DX9 modes?

[Toni Wilen]

DXGI_FEATURE_PRESENT_ALLOW_TEARING is Direct3D 11+ only.

[mark_k]

I'm pretty sure it's Windows' own OSD. I just assumed it not appearing indicates that the program is "really full-screen".

I checked the full-screen modes of some PC games. All older titles, but downloaded via Steam or Uplay so may have been updated for recent OS compatibility. None should use anything later than DirectX 9?

Half-Life 1, Portal, Half Life 2: Lost Coast, Saints Row 2 - No volume OSD, tearing with in-game vsync option disabled. Alt-Tabbing takes you back to desktop before the task switcher appears; Windows doesn't overlay it over game graphics.
Assassin's Creed 3 - No volume OSD, no tearing (no in-game vsync option).
Splinter Cell - Goes full-screen (changes resolution), volume OSD does appear however, and Alt-Tab switcher appears over game image.

So they must be setting up the full-screen display differently to WinUAE in some way.

DXGI_FEATURE_PRESENT_ALLOW_TEARING is probably needed to allow tearing in full-window mode (on Windows 10). But full-screen mode should be capable of allowing tearing already as the various games show.

[Toni Wilen]

D3D9Ex (Direct3DCreate9Ex) probably makes it more friendly with other programs than standard D3D9 fullscreen.

It is exclusive fullscreen, only exclusive fullscreen can change resolution and refresh rate.

[mark_k]

This is strange. I went back and tested older versions of WinUAE. Full-screen mode, no buffer or double-buffer. [This is with Windows 10 1703 x64.]

3.1.0: Tearing present. No OSD on Vol+/-, but it appears if you press F12 to open settings window.
3.2.1: Same
3.5.0: Same
3.6.0b4: Same(!!!)

It turns out that 32-bit WinUAE has no problem. But 64-bit WinUAE always seems to force (something like) triple buffering since there's no tearing and the vol+/- OSD can overlay the image.

Here's the config I used:

https://www.media!fire.com/file/7397dhd3a07eant/A500_1.2_lace_test.uae.zip

[mark_k]

Originally Posted by Toni Wilen

DXGI_FEATURE_PRESENT_ALLOW_TEARING is Direct3D 11+ only.

I guess the thought of adding another code path (DirectX 11) just for that benefit isn't too enticing.

[Dr.Venom]

Originally Posted by mark_k

It turns out that 32-bit WinUAE has no problem. But 64-bit WinUAE always seems to force (something like) triple buffering since there's no tearing and the vol+/- OSD can overlay the image.

Hi Mark,

I just did a quick test with 3.4.0 64-bit, but with the "no buffer" and "fullscreen" setting I -do- get tearing.

Are you using the "-nod3d9shader " option by any chance? Using that once triggered my Windows 10 setup into some very obscure behaviour to always force vsync or some kind of buffering. In the end I reinstalled Windows and it went away. Probably not your issue, but just in case.


Edit: just tested 3.6.0b4 64-bit and with the "no buffer" and "fullscreen" setting I also get tearing.

[mark_k]

Hmmm, it could be. This is very very strange.

Normally I run WinUAE from a shortcut which specifies -nod3d9shader. But for testing here I wasn't doing that.

I just tested some other WinUAE 64-bit versions. Weirdly, 3.5.0 has the problem (no tearing), as does 3.6.0b4. But 3.6.0b3 seems fine??? [But see below.]

And, I just copied the WinUAE 3.6.0b4 executable to have a different name. On running that, there was tearing in full-screen mode!

Could Windows 10 be silently applying some kind of compatibility setting when WinUAE is run with -nod3d9shader? Maybe it stores the name/path of the executable in the registry so even when you run it without -nod3d9shader it still has the forced-vsync/triple-buffer/whatever behaviour applied???

Next I ran
"winuae64_3600b4 - Copy.exe" -nod3d9shader
and that didn't show the problem (could see tearing in full-screen mode). But after quitting I ran it again without -nod3d9shader and the problem is there (no tearing). The problem remains with or without -nod3d9shader now.

[Dr.Venom]

Originally Posted by mark_k

Could Windows 10 be silently applying some kind of compatibility setting when WinUAE is run with -nod3d9shader? Maybe it stores the name/path of the executable in the registry so even when you run it without -nod3d9shader it still has the forced-vsync/triple-buffer/whatever behaviour applied???

Next I ran
"winuae64_3600b4 - Copy.exe" -nod3d9shader
and that didn't show the problem (could see tearing in full-screen mode). But after quitting I ran it again without -nod3d9shader and the problem is there (no tearing). The problem remains with or without -nod3d9shader now.

That was -exactly- my experience. Basically using -nod3d9shader even if only once, messed up my W10 setup in such a way that (non-)vsync behaviour was beyond repair. Not only was it always vsynced / buffered in "no buffer / no-vsync " mode, but also when using v-sync i got strange latency problems with input, i.e. occasional "rubber band" movement.

I reinstalled Windows back then and it went away. Tried -nod3d9shader once more on the new install and the exact same problem returned. Reinstalled Windows 10 again and never touched -nod3d9shader again. I never found out the real cause and blamed a specific W10 + driver combination in my setup. And since I didn't felt reinstalling Windows again I left it a that.

Did you notice in the log that -nod3d9shader seems to switch from d3d9ex to d3d9, maybe that has something to do with it.

Edit. I remember one of the early Windows 10 updates having the forced vsync bug? Maybe the later releases fixed that for d3d9ex applications but not for d3d9? Just guessing...


Edit 2.:

Next I ran
"winuae64_3600b4 - Copy.exe" -nod3d9shader
and that didn't show the problem (could see tearing in full-screen mode). But after quitting I ran it again without -nod3d9shader and the problem is there (no tearing). The problem remains with or without -nod3d9shader now.

Giving your above comment another thought I guess the most plausible explanation indeed seems to be some sort of hidden "compatibility option" being applied by Windows 10.

If you look at the log than you see that using -nod3d9shader switches from d3d9ex to d3d9 (if I remember correctly that is..). If this "hidden compatibility" option is only applied to d3d9 apps, it could explain why this behaviour is only triggered after using the -nod3d9shader option with a winuae exe.

[mark_k]

AHA!!!

Since the various WinUAE executables on my PC have distinct names (e.g. winuae_3600b4.exe), I used RegEdit to search the registry for 3600b4.

Look in HKEY_CURRENT_USER\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode
There's a list of various WinUAE executable names (actually complete paths). The Data value for each is 1.

Also look in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store
You'll see entries for various WinUAE executables with REG_BINARY data.

And look in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
The entries there may relate to manual compatibility settings (when you right-click the EXE in Explorer, choose Properties, the Compatibility tab). Most of my WinUAE EXEs had this for each:
~ DISABLEDXMAXIMIZEDWINDOWEDMODE HIGHDPIAWARE
I'm not sure what the ~ signifies. [I had manually checked "Disable full-screen optimisations" and "Override high DPI scaling behaviour." on the Compatibility tab.]

See Compatibility Fixes for Windows 10, Windows 8, Windows 7, and Windows Vista. Quoting from there:
"DXMaximizedWindowedMode
Applications that use DX8/9 are run in a maximized windowed mode. This is required for applications that use GDI/DirectDraw in addition to Direct3D."

Note that if you run WinUAE, switch to DirectDraw mode then exit, that doesn't force maximized-windowed mode in future, unlike -nod3d9shader.

If you delete some or all the registry keys corresponding to your WinUAE EXE, that should restore proper full-screen behaviour. Or maybe just deleting the entry in HKCU\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode would be enough?

For WinUAE itself, is there any proper way to fix this? I guess it could delete the entry in HKCU\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode automatically when run??? Or could the way -nod3d9shader works be changed somehow?

Edit: It looks like the -nod3d9ex option causes the same problem.

[Dr.Venom]

Originally Posted by mark_k

AHA!!!

See Compatibility Fixes for Windows 10, Windows 8, Windows 7, and Windows Vista. Quoting from there:
"DXMaximizedWindowedMode
Applications that use DX8/9 are run in a maximized windowed mode. This is required for applications that use GDI/DirectDraw in addition to Direct3D."

Great find Mark

For WinUAE itself, is there any proper way to fix this? I guess it could delete the entry in HKCU\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode automatically when run??? Or could the way -nod3d9shader works be changed somehow?

Originally Posted by Dr.Venom

If you look at the log than you see that using -nod3d9shader switches from d3d9ex to d3d9 (if I remember correctly that is..). If this "hidden compatibility" option is only applied to d3d9 apps, it could explain why this behaviour is only triggered after using the -nod3d9shader option with a winuae exe.

Given that your quote shows the compatibility option being applied to DX9 apps, and -nod3d9shader seems to enable d3d9 (disabling d3d9ex, see the log) I guess this behaviour will always be triggered with -nod3d9shader.

Maybe a "no shader" option is possible while not disabling d3d9ex?

[Toni Wilen]

I think the problem is GUI opening in fullscreen mode (which is GDI) without D3D9Ex.

No shader mode also disables D3D9Ex. (But not anymore, reason was simply trying to be as compatible as possible with old drivers)

[mark_k]

Ah OK. So at least for exclusive full-screen mode this problem is solved.

When WinUAE is run without -nod3d9ex, could you check for the registry key in HKCU\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode and delete it if present?

But that's not a perfect solution, since if in future the user runs WinUAE with -nod3d9ex then the F12 settings window won't appear. (It will next time, because Windows recreated the shim registry key.)
Also, when you delete the registry key, since WinUAE already launched it may be too late for that run. The user would need to quit and re-run WinUAE. Maybe simpler to tell the user to delete the key themselves. (Can you detect when you request exclusive full-screen mode, but Windows actually puts you in full-window mode? If so maybe output a message to the log.)

BTW, does WinUAE use flip mode present with D3D9Ex?

[Toni Wilen]

Originally Posted by mark_k

When WinUAE is run without -nod3d9ex, could you check for the registry key in HKCU\Software\Microsoft\Direct3D\Shims\MaximizedWindowedMode and delete it if present?

No.

1) I won't modify registry entries that affect global system state (This should be never done!)
2) Those surely aren't documented as user modifiable anyway. (Same!)
3) Need more privileges than normal users have.

BTW, does WinUAE use flip mode present with D3D9Ex?

What do you mean?

[mark_k]

I think the registry key is readable without admin permissions, so you could at least print a warning in the log.

There's some info about flip mode presentation on this MSDN page. The benefit is that in windowed mode, the D3D runtime no longer needs to copy the surface to a DWM redirection surface. So reduced memory bandwidth. It also mentions something about present statistics, no idea whether that's any relevance to WinUAE though.