Input latency measurements (and D3D11)

[Retro-Nerd]

Works in windowed mode so far in Windows 10 1607. What tests do you need? It's very responsive but probably on the same level like D3D9 with the best latency settings set.

[mark_k]

Today's winuae.exe 16:29, I get this:

D3D11 free start
D3D11 free end
Max hardware surface size: 16384x16384
Allocated draw temp buffer (1600*1280*32) = 13093020
D3D11 init start
CheckFeatureSupport(DXGI_FEATURE_PRESENT_ALLOW_TEARING) = 00000000 1
IDXGIDevice1 QueryInterface 00000000
Plugin path not found
D3D11 free start
D3D11 free end
D3D11 free start
D3D11 free end
D3D11 ERROR!

I'll make directory plugins/filtershaders/direct3d11 and try again (didn't realise that was essential).

[Toni Wilen]

Works/not work status mainly.. and if someone wants to test windowed variable refresh rate mode. (When WinUAE window has focus, monitor refresh rate matches Amiga refresh rate. This needs Windows 10 Anniversary update. And obviously gsync or freesync hardware)

And someone to find projection calculation that does not use obsolete d3d9x (D3DXVECTOR3 and friends), also calculation that actually results in 1:1 pixel mapping (current does not).

Latency stuff comes later when fullscreen works and other dxgi advanced stuff gets implemented.

I'll make directory plugins/filtershaders/direct3d11 and try again (didn't realise that was essential).

Check my previous post again, it also need 2 files.

[Retro-Nerd]

You mean the variable sync option? It's smooth and no sign of tearing. A general issue, not related to the selected refresh rate mode: I have to enable the null filter, without i get flickering and smearings when objects are in motion.

[mark_k]

OK, working for me now. Both windowed and full-window mode are similar, there's no tearing (i.e. forced vsync). I think my graphics card is FreeSync capable, but my monitor isn't if that's relevant.

Edit: You probably know already, but trying to use low-latency or legacy vsync causes WinUAE to crash.

[Toni Wilen]

Originally Posted by Retro-Nerd

You mean the variable sync option? It's smooth and no sign of tearing. A general issue, not related to the selected refresh rate mode: I have to enable the null filter, without i get flickering and smearings when objects are in motion.

No, I mean allowing non-vsync windowed mode. Windows desktop always (sine DWM was introduced) buffers windowed display updates. DXGI 1.5+ allows to bypass this.

Combined with gsync/freesync hardware: real refresh rate matches program's frame rate, even when windowed. (My display's OSD shows 100Hz when normal programs have focus, when winuae has focus, monitor's refresh rate changes to 50Hz/60Hz. It would also enable stable windowed black frame injection.)

Originally Posted by mark_k

OK, working for me now. Both windowed and full-window mode are similar, there's no tearing (i.e. forced vsync). I think my graphics card is FreeSync capable, but my monitor isn't if that's relevant.

Redownload. DXGI_PRESENT_ALLOW_TEARING Present() parameter was lost when I added some fullscreen support (fullscreen still does not work properly)

EDIT: Vsync is not supported. It crashes by design

[mark_k]

Now there's tearing in full-window but not in windowed mode. Maybe an AMD graphics driver difference/limitation vs Nvidia?

I couldn't see any off-by-one or other problem with scaling (Highgfx 1024×768 Workbench).

In CameraClass_Render() I think d3d->m_rotationX/Y/Z are always 0.0f, so you could maybe try removing the calls to D3DXMatrixRotationYawPitchRoll() and D3DXVec3TransformCoord()?

[Toni Wilen]

Originally Posted by mark_k

Now there's tearing in full-window but not in windowed mode. Maybe an AMD graphics driver difference/limitation vs Nvidia?

Maybe but I haven't tried what happens with gsync disabled.

I couldn't see any off-by-one or other problem with scaling (Highgfx 1024×768 Workbench).

Resize the window few times. Sometimes image is blurry, sometimes it is sharp. (I used KS 1.3 "hand" screen to test it)

(Note that resize still means complete re-creation of everything)

In CameraClass_Render() I think d3d->m_rotationX/Y/Z are always 0.0f, so you could maybe try removing the calls to D3DXMatrixRotationYawPitchRoll() and D3DXVec3TransformCoord()?

90 degree rotation may be useful sometime

[Toni Wilen]

I found post that told to replace vertex shader with this:

PixelInputType TextureVertexShader(VertexInputType input)
{
	PixelInputType output;

	input.position.w = 1.0f;

	output.position = mul(input.position, projectionMatrix);

	output.position.z = 0.0f;

	output.tex = input.tex;

	return output;
}

It seems to fix blurriness issue.

[Retro-Nerd]

No, I mean allowing non-vsync windowed mode. Windows desktop always (sine DWM was introduced) buffers windowed display updates. DXGI 1.5+ allows to bypass this.

Combined with gsync/freesync hardware: real refresh rate matches program's frame rate, even when windowed. (My display's OSD shows 100Hz when normal programs have focus, when winuae has focus, monitor's refresh rate changes to 50Hz/60Hz. It would also enable stable windowed black frame injection.)

It's smooth and tearing free in non-vsync mode too. But the OSD of my Freesync monitor doesn't show 50/60Hz when the WinUAE window has the focus. It stays on 75Hz (it's the limit of my monitor).

edit: In Full Window mode the monitor switches to 50Hz. But this happens with D3D9 in Full Window mode too. You probably don't have a Freesync monitor to test it, right?

[mark_k]

In direct3d11.cpp you have:

UINT presentFlags = d3d->m_tearingSupport ? DXGI_PRESENT_ALLOW_TEARING : 0;
// Present as fast as possible.
hr = d3d->m_swapChain->Present(0, 0);

Should the third line be

hr = d3d->m_swapChain->Present(0, presentFlags);

Also

// Set the width and height of the back buffer.
swapChainDesc.Width = w_w;
swapChainDesc.Height = w_h;
... [initialise various fields of swapChainDesc] ...
fsSwapChainDesc.Windowed = isfullscreen() <= 0;

Should the last line be

swapChainDesc.Windowed = isfullscreen() <= 0;

[Toni Wilen]

Originally Posted by mark_k

In direct3d11.cpp you have:

UINT presentFlags = d3d->m_tearingSupport ? DXGI_PRESENT_ALLOW_TEARING : 0;
// Present as fast as possible.
hr = d3d->m_swapChain->Present(0, 0);

Should the third line be

hr = d3d->m_swapChain->Present(0, presentFlags);

That was post #46 fix.

Also

// Set the width and height of the back buffer.
swapChainDesc.Width = w_w;
swapChainDesc.Height = w_h;
... [initialise various fields of swapChainDesc] ...
fsSwapChainDesc.Windowed = isfullscreen() <= 0;

Should the last line be

swapChainDesc.Windowed = isfullscreen() <= 0;

No. It is DXGI_SWAP_CHAIN_DESC1, not DXGI_SWAP_CHAIN_DESC. Original code used dxgi 1.0, 1.1+ is different. (and required for tearing stuff)

[Dr.Venom]

Originally Posted by Toni Wilen

Very experimental D3D 11 support added.

Cool

It works for me in (full-)window mode..

Originally Posted by Toni Wilen

- Enables (if available) windowed variable refresh rate mode (DXGI_FEATURE_PRESENT_ALLOW_TEARING). G-Sync confirmed working. Which is nice.

Even though I don't have a gsync/freesync monitor to test it, this sounds like a really neat feature.

Originally Posted by Toni Wilen

Latency stuff comes later when fullscreen works and other dxgi advanced stuff gets implemented.

Great, looking forward to further progress!

[pandy71]

Originally Posted by modrobert

In either of these cases you will most like have a weak (low power) MCU adding latency, not to mention serial to parallel protocol conversions.

USB can be forced to work in low latency mode at a cost of higher CPU load (or rather more frequent interrupts that destroy modern CPU code flow).
USB latency can be verified for example with help of http://www.thesycon.de/eng/latency_check.shtml

Originally Posted by modrobert

The same goes for the CRT connected to PC, it will require some kind of display adapter handling the HDMI or display port signal to process the analog CRT video (RGB or composite) signal adding to latency.

Not necessarily - from at least decade you can on PC create own video mode, there is plenty of video cards still offering VGA RGB output natively.
No reason to not set 800x600 100 - 200fps mode on PC.
Plenty of PC CRT's should be able to deal with such signal.

Originally Posted by modrobert

The speed of light (photons) travel roughly 30cm (~299.792458mm) in 1ns, and electrons move a bit slower, which means you introduce over 3ns lag by just having a 1 meter cable.

Rarely electrons in cable moving with speed close to speed of light, usually they moving slower and this depend from way how cable is designed and what kind of materials are used to build cable - it is well known as velocity factor and usually signal propagate trough cable with approx 60 - 70% of light speed https://en.wikipedia.org/wiki/Veloci...locity_factors so it will be not 3 but for example 5ns (but this is irrelevant for this discussion).

Originally Posted by Retro-Nerd

Sorry, but this are too many unknown variables. And the measurement method filming via iPhone cam sounds adventurous too.

It is correct way to measure this kind of problem however 240 fps may be insuffcient speed - 240fps gives around 4.16ms resolution of measurement so it is clear that it will be difficult to measure something lower than this.
For more accurate measurements oscilloscope can be used (stimulus from button can trig timebase in scope and for example cheap photodiode for example BPW34 can be used as light to electric current converter).

[mark_k]

Just updated AMD graphics driver to 17.Q4 from here. Now in D3D11 mode CPU% reads about 650%, FPS about 9.

I'll try a clean driver install to see if that fixes it. If not it looks like AMD broke something since 17.Q3.1.

[Toni Wilen]

D3D11 Fullscreen mode should work now. (Still no filters etc..)

btw, DXGI fullscreen has also some weird issues, I originally used WM_ACTIVATE to detect when fullscreen is lost by calling SetFullscreenState(FALSE, NULL); and then minimizing the window but WM_ACTIVATE can come when execution happens inside Present() call (probably when it is waiting for vsync or similar). Calling any DXGI functions in this situation will cause crash inside Present().. So I had to store only a flag and do the mode change in uae main loop.

[mark_k]

Testing with winuae.exe 2017-10-28 18:55, there's a "D3D11 ERROR!" dialog on starting emulation (windowed mode) and it falls back to using DirectDraw.

That's on Windows 10 1709 x64, with the 17.Q4 AMD driver which "works" albeit incredibly slowly as mentioned in post 55 with the earlier 2017-10-22 18:53 winuae.exe

Log output:
D3D11 free start
D3D11 freed3d start
D3D11 freed3d end
D3D11 free end
Max hardware surface size: 16384x16384
Allocated draw temp buffer (1600*1280*32) = 12C01020
D3D11 init start
CheckFeatureSupport(DXGI_FEATURE_PRESENT_ALLOW_TEARING) = 00000000 1
D3D11CreateDevice 887a002d
D3D11 free start
D3D11 freed3d start
D3D11 freed3d end
D3D11 free end
D3D11 free start
D3D11 freed3d start
D3D11 freed3d end
D3D11 free end
D3D11 ERROR!
DirectDraw displays:

There's an MSDN forum thread which could be related. One of the replies there says
"Removing creationFlags |= D3D11_CREATE_DEVICE_DEBUG; in DEBUG mode did the trick in my case..."

[Toni Wilen]

Updated. I forgot to remove debug flag..

[Retro-Nerd]

Yep, Fullscreen works fine and everything is still smooth.

[Dr.Venom]

Originally Posted by Toni Wilen

D3D11 Fullscreen mode should work now. (Still no filters etc..)

btw, DXGI fullscreen has also some weird issues, I originally used WM_ACTIVATE to detect when fullscreen is lost by calling SetFullscreenState(FALSE, NULL); and then minimizing the window but WM_ACTIVATE can come when execution happens inside Present() call (probably when it is waiting for vsync or similar). Calling any DXGI functions in this situation will cause crash inside Present().. So I had to store only a flag and do the mode change in uae main loop.

Full screen mode works for me..

I noticed a different issue with regards to pixel mapping occuring in both full-screen, full-window and window mode.

I noticed when testing on my CRT setup (which uses 1:1 pixel mapping), that the picture is scaled / distorted in single line mode.. This while double line mode is "pixel perfect".

This can easily be seen on the corsair crack intro for Turrican 2. At the right bottom it says "corsair" drawn in tiny letters (I can upload the corsair cracked Turrican 2 to the zone if needed). I've attached the screenshots, with two enlarged crops of that section, that clearly show the issue in single line mode.