D3D9Ex overlay support?

[mark_k]

I read about Hardware Overlay Support on MSDN.

"Starting in Windows 7, Direct3D 9 supports hardware overlays. This support is intended primarily for video playback, and differs in some respects from earlier DirectDraw APIs
...
To query for overlay support, call IDirect3D9::GetDeviceCaps. If the driver supports hardware overlay, the D3DCAPS_OVERLAY flag is set in the D3DCAPS9.Caps member.
...
To create the overlay, call IDirect3D9Ex::CreateDeviceEx and specify the D3DSWAPEFFECT_OVERLAY swap effect. The back buffer can use a non-RGB format if the hardware supports it."

Do all/any modern graphics drivers support D3D9Ex overlays? Could it be possible to achieve non-vsynced output in windowed mode via the overlay feature?

[Toni Wilen]

I am quite sure "real" hardware overlay does not exist and it is just some GPU internal blit or similar.

[Dr.Venom]

Originally Posted by mark_k

Could it be possible to achieve non-vsynced output in windowed mode via the overlay feature?

Just out of interest, is there a specific reason why you would want such a feature?

[mark_k]

In case it's possible to have non-vsynced output in windowed mode. DWM can't be disabled on Windows 8 or later, so there would be no other way to achieve that in windowed mode. Non-vsynced means potentially lower latency and it doesn't look as bad as some frames being skipped when e.g. running a PAL demo with 60Hz desktop.

[Here, by non-vsynced I mean without DWM-forced buffer flipping in the PC vertical blanking interval (where there is no tearing visible). That's currently only possible in full-screen mode (on Win 8+).]

[mark_k]

It sounds like D3D9Ex overlay bypasses DWM, allowing non-vsynced rendering & lower latency in windowed mode. A blog post by the developer of VirtualDub: Exploring hardware overlay support in Windows 7, written back when Windows 7 RC was current:

"Windows Vista appeared to be the end of the line for overlays, as they were not supported in desktop composition mode, but guess what... they're back in Windows 7. As it turns out, hardware overlays are still valuable for a couple of reasons, one being that you can flip them faster and asynchronously from the composited desktop (good for performance) and because you can't capture their image in a screen grab operation (good for the paranoid). And this time, they have a few improvements, too."

Maybe it depends on the video driver, but it would be great if that allows windowed non-vsync with AMD graphics cards. [I can't achieve that on my system with WinUAE's D3D11 mode.] And it could/should work from Windows 7 up. (Not sure about Vista with Platform Update.)

[mark_k]

I tried a simple binary patch to WinUAE 3.6.0b8, equivalent to changing
d3d->dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
in direct3d.cpp to
d3d->dpp.SwapEffect = D3DSWAPEFFECT_OVERLAY;

Not too surprisingly, that didn't work! Starting emulation gave this in the log:
CreateDeviceEx failed, 8876086C S=1 F=0876 C=086C (2156) ()

If anyone else feels like checking (maybe different with other OS version or graphics hardware?), in 32-bit WinUAE 3.6.0b8 change the byte at offset $5B469C from 01 to 04.

[Toni Wilen]

D3DSWAPEFFECT_OVERLAY worked for me but I am not really interested in testing and debugging something that is only supported in theory and no one probably used it..

[mark_k]

Overlay swap effect might be used by video player programs (esp. ones which try to implement some DRM like Windows Media Player maybe, since you can't easily screenshot the overlay). Was tearing visible? That and lower latency if it bypasses DWM would be the main reasons to consider supporting it.

I tested on my old laptop with Nvidia graphics on Windows 7 and Windows 10 1511. It did work, kind of. Some tweaking would be needed to properly support it, e.g. updating colour key when the window is moved/sized.

On Windows 7 with DWM disabled, there was no tearing. So at least with the one-byte patch the overlay always gets updated in vblank. Similarly no tearing on Windows 10 which has DWM always-on. Would WinUAE have been using D3DPRESENT_INTERVAL_IMMEDIATE in this case?

[mark_k]

Did you notice tearing when you tested D3DSWAPEFFECT_OVERLAY? Even if not, it's possible that using the overlay has lower latency than going through DWM (since it may well be handled separately in hardware by the driver).