Optimizing DirectX apps for low latency input and longer battery life

[Dr.Venom]

I came across the following blog; It focuses upon the subject of low latency input by setting up a separate thread for input processing:

https://blogs.windows.com/buildingap...-battery-life/

Especially scenario 4 got my attention as it possibly seemed applicable to WinUAE:

4. Render 60 frames per second and achieve the lowest possible input latency. Similar to scenario 3, the app is constantly updating the screen so power efficiency will be the same. The difference is that the app responds to input on a separate thread so that input processing isn’t blocked by presenting graphics to the display. Online multiplayer games or rhythm timing games might fall into this category as well as fighting games like Street Fighter because they support move inputs within extremely tight event windows.

Could WinUAE possibly benefit from having input processing on a separate thread?

There's also a specific code example that seems related to this on the Microsoft Github: https://github.com/Microsoft/Windows...owLatencyInput


------------
With regards to the blog, almost the same article is on MSDN, but more recently updated:

Optimize input latency for Universal Windows Platform (UWP) DirectX games: https://msdn.microsoft.com/pt-pt/win...coredispatcher

Which also mentions "Reduce latency with DXGI 1.3 swap chains": https://msdn.microsoft.com/windows/u...-3-swap-chains

These seem to be for D3D 11 so not sure how helpful it would be for WinUAE currently.

[Toni Wilen]

It is not going to help. Emulation itself is still going to get blocked and it is not running in real time anyway.

Comparisons to games are invalid

[Dr.Venom]

I did some analysis on this using Intel Graphics Percormance Analyzer (https://software.intel.com/en-us/gpa) with a iGPU (HD4000) and additionaly by using Microsoft's GPUView (https://msdn.microsoft.com/en-us/win.../using-gpuview) with a few graphics cards, both ATI and NVidia.

The general conclusion is that with WinUAE the GPU is occupied for only ~100 - 500 microseconds, i.e. 0.1 - 0.5 milliseconds, per single frame.

So in general I think your previous comment holds

This was tested without any shaders/filters and max 2x2 scaling.

While testing it was interesting to see that the iGPU / graphics cards that I tested ran in their power saving / desktop state when WinUAE is running. Only using "warp mode" made them run at max GPU speed. Generally they run at 1/3 to 1/2 of the GPU speed when in throttled mode.

I guess when using special d3d filters this could lead to a tipping point where the GPU stays in power saving / throttled mode, negatively impacting shader performance.

Using a few utilities that make the GPU clock to the max, the "GPU occupied" time scaled linearly lower versus their higher clocked GPU speed.

Bottom line conclusion is that you were right that it won't make much use putting input on a separate thread.

The only case I can think of where it could possibly make sense would be some very heavy shader/filter, which would probably multiply the above mentioned times several times (especially on lower end hardware)...