Application.targetFrameRat It doesn't work in versión 2020.2.0b5.3233

Accidentally posted too early. Oops. See picture.

Shifting the rendering a bit closer to the wait-for-flip part, so there is more input captured closer to the same vlabk

 

Finally found this in my history:

And here is interesting inputlag data when using Vsync with external cap below refresh rate:https://forums.blurbusters.com/viewtopic.php?p=41138&sid=9f5c5febb97e895fb004ea025b2a5719#p41138

 

Is there something I'm missing here? Almost every single game I've played in the last 15 years has options to turn VSync on and off, as well as choose the frame rate. The player should be able to choose if they want to run at 30, 60, 120 or uncapped. That's a standard setting that can be found in almost every single option menu. How is this even a discussion?

Also - a crapton of games limit the frame rate to 30 or 60 on purpose, especially on console. Have I crossed over into another dimension where this isn't the industry standard?

 

This was tested with multiple different engines, not just UE, and it holds true for them as well (Overwatch, CoD, etc.) as well as different GPUs (AMD/Nvidia)

Yes, this is what Low Latency On in Nvidia panel does now in latest drivers, it just sets Queued Frames to 1 as old setting for that. Ultra one does some behind the scene magic to lower latency when GPU overloaded.

Yeah, that's a fair point. I guess you can offset scanline up (negative value) instead to get latest frame. Basically, it is a faster vsync but fine tuned and with a choice, with much more clear logic and understanding what is happening, instead of blackbox driver magic.

Judging by the latest updates to RTSS, latency and overhead were reduced even further and it seems like they are moving towards possibly automated solution, with jitter approximation. That would be pretty cool.


As a final thought, I still think it is worth for Unity to implement more precise generic framelimiter just like UE did. It is good that future version will now give the developer an ability to roll out his own in the update loop, but not many will do, so a tad more precise generic one would be great. Even if it is just slightly better in terms of input latency (nstead of random chaos as of now) than vsync - it still would worth it.

 

If anyone is interested, here is some interesting discussion about how latency can be induced in many different ways, starting from pages 4/5:
https://forums.blurbusters.com/viewtopic.php?f=10&t=7551&start=30

For example:

 

What is this talk about exclusive fullscreen not being true exc. fullscreen with presentation locked to its own process but rather some hacky compositor bypass at the end of presentation?

 

So which model do you use for what you've marked as "fullscreen exclusive"? What about Windows versions that are below 8.1?

 

So looking at the docs:
https://docs.unity3d.com/ScriptReference/PlayerSettings-useFlipModelSwapchain.html

Note that even if the flip model is enabled, the BltBlt model will be used in exclusive fullscreen mode to reduce input latency.

For VSYNCON case in FSE will still use Blt Presentation model on D3D11. is this regardless of Windows version?

 

I see. Any reason DXGI_SWAP_EFFECT_FLIP_DISCARD and waitables are not utilized? I assume in case of waitable you probably need to extend that control to the user render pipeline so he can utilize that.

 

See
https://devblogs.microsoft.com/directx/dxgi-flip-model/

What else is new in flip model?
In addition to the above improvements, which apply to standard swapchains without anything special, there are several features available for flip model applications to use:

• Decreasing latency using DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT. When in Independent Flip mode, you can get down to 1 frame of latency on recent versions of Windows, with graceful fallback to the minimum possible when composed.

Jesse Natalie also talks about it in the video you've linked.

 

Fair enough, I just wanted to make sure.
Did some testing with PresentMon to see what presentation modes Unity (2019.2+) uses on Windows 7 (DWM on). Running with

-window-mode exclusive

gives me "Hardware: Legacy Flip" which, if we reference Jesse's talk, is proper FullScreen Exclusive with flipping. Running in Unity's "default" fullscreen (borderles fullscreen) I'm getting Present mode "Composed: Copy with GPU GDI" which I cant seems to correlate to any of the MS terminology. I'm assuming this is Windowed BitBlitTransfer with some Compositor trickery?
Interestingly enough, UE4.2+ win Borderless Fullscreen run in "Composed: Copy with CPU GDI".

 

Oh, I see, I just realized this is only true to Win8.1+ and Win10 when proper flip model + waitables are used, this makes sense now as I was thinking in the context of older Windows and FSE. Took me this long to understand what did you mean and why there was disagreement in the thread, since in Win10, Borderless Fullscreen with all new presentation improvements is essentially as fast as FSE, so the FPS limiter/cap that is equal to refresh rate versus vsync is essentially the same, yes. And the rest of the participants were talking in the context of old FullScreen Exclusive where it is not the case and where latency hit with vsync is very high, which Jesse demonstrates in his presentation @ 9:18

 

I assume this only should happen if we use SyncMode=1 (VSYNC ON) in FSE. If there is no syncmodel, Unity should use legacy HW fs flip without copying buffer? Unless it ALWAYS uses Blt Fullscreen mode regardless of syncmode?
PresentMon cant distinguish the presentation mode I guess, I did quick tests:

Uncapped FSE:

0000000067E726E0 (DXGI): SyncInterval=1 Flags=0 3.93 ms/frame (254.4 fps, 254.4 fps displayed, 1.99 ms latency) Hardware: Legacy Flip

FSE + syncmode=1 (classic VSYNC ON):

0000000068B5EC80 (DXGI): SyncInterval=1 Flags=0 12.48 ms/frame (80.1 fps, 80.1 fps displayed, 34.10 ms latency) Hardware: Legacy Flip

FSE + syncmode=1 +RTSS AfterPresent async cap -00.01 of RefreshRate:

000068954170 (DXGI): SyncInterval=1 Flags=0 12.50 ms/frame (80.0 fps, 80.0 fps displayed, 27.13 ms latency)  Hardware: Legacy Flip

Interesting present latency results.

Which is why people who run it on Win7 or Win8 prefer true FSE with external limiter like RTSS which you can fine tune or use scanlinesync trick to get less than half or even just 1/3 of (additional) frame latency and have basically VSYNC on.

 

Pesky frame rats

 

Really appreciate the work on reducing any engine lag there is. The world is full of games that benefit from very low latency input, and I think these kind of features enable many new kinds of gameplay to be made with Unity.

 

Got vsync working in Unity (2020.1.7).

Did some testing with different configurations with my 240hz monitor, on Windows. (RTSS below is Rivatuner Statistics Server ). All tests have maxQueuedFrames = 1, exclusive fullscreen. Tried maxQueuedFrames = 0 but it makes fps go below 240.

From best to worst:
A: targetFrameRate = 1000, vSyncCount = 0
targetFrameRate = -1, vSyncCount = 0
targetFrameRate = 500, vSyncCount = 0
Can't tell a difference between all of these 3, got best score with 1000 limit.


B: targetFrameRate = -1, vSyncCount = 0, RTSS fps limit = 240fps
Feels similar to A, what surprised me is that setting RTSS fps limit = 300fps somehow made it worse.

C: targetFrameRate = 300, vSyncCount = 0
It feels more responsive than vSync (F) but looks a bit choppy compared to B, A.


E: targetFrameRate = 240, vSyncCount = 0
Game looks choppy but has slightly better responsiveness and min fps drops than vSync (F).


F: targetFrameRate = -1, vSyncCount = 1
So with vSync game looks better/smoother than E but is less responsive - mouse feels like it's floating. Definitely adds input lag, will try again in 2020.2. Min fps drop to 100-140. Somehow max fps goes beyond 240(?):


If I had to pick between D and E I would maybe pick E for smoother graphics but worse responsiveness. Depends if fps could handle it. Anyway A, B, C are all better.

Conclusion: Setting targetFrameRate = monitorHz * ~1.5 (or more) and turning off vsync gives best results.

I wish Unity would focus more on improving targetFrameRate (and maxQueuedFrames) rather than vsync. I've noticed that maxQueuedFrames = 2 looks a bit smoother than 1 despite getting more fps than monitor hz with both settings. Maybe that could be improved?

Testing was nothing else than playing the game, A case:

 

Just to make sure, you do know that 2020.2 has hugely improved delta time measuring? Some targets like Vulkan and VR are not yet supported but where it has been changed already it's like night and day compared to previous versions.

 

Interesting I hope it will improve choppiness.

https://blogs.unity3d.com/2020/10/0...020-2-for-smoother-gameplay-what-did-it-take/

Somehow I'm able to set it to 0 and it halves average fps:
maxQueuedFrames = 2: avg fps 1000
maxQueuedFrames = 1: avg fps 500
maxQueuedFrames = 0: avg fps 250

 

Tried 2020.2.9b, my results are that I get 50% less fps :/
With maxQueuedFrames = 2 I get previous maxQueuedFrames = 1 performance:

Sometimes waitforsignal spikes are huge

I'll probably go back to 2020.1 for now and make similar screenshots for comparison.

Anyway trying vsync again and I can't imagine myself using it. Still noticeable making me miss a lot of targets :/

 

Directx 11, tried also automatic but I guess that's the default one so it didn't change anything. Exclusive fullscreen.

Prob would be worth checking performance with other projects and possibly make

maxQueuedFrames = 3

new default value.

 

Interesting, completely different fps:

maxQueued = 1
Exclusive:

FullscreenWindow:


maxQueued = 2
Exclusive:

FullscreenWindow:


maxQueued = 3
Exclusive:


So avg fps are similar when queue is 1 higher for exclusive but min fps and peaks are very different.

 

Similar story for vsync:
queue = 1, exclusive:


All other settings are something similar to

 

Huh?
That does not explain his VSYNC OFF ExclusiveFullscreen uncapped fps. FrameQueing mostly relevant when you use some kind of syncinc, as Jesse mentioned, in FullScreen with Queue 2+ he should be getting full achievable FPS but he does not.
Looks like an issue to me,

 

Probably GPU, screenshots are from paused menu scene (with visible BoatAttack water system). Not sure if my custom implementation of AudioSource.GetSpectrumData with Burst runs when game is paused.

I have this thing checked (also tried disabling but it didn't change much).


I believe you should also use it when testing, furthermore if player has in unchecked then DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT should be used as: https://devblogs.microsoft.com/directx/demystifying-full-screen-optimizations/

So with optimizations enabled game runs in windowed FSE mode.

Question is if it's possible to check if user has true old FSE or new fake FSE (FSE with optimizations enabled).

https://docs.microsoft.com/en-us/wi...xgi/for-best-performance--use-dxgi-flip-model

I guess if it's true then I may remove exclusive fullscreen at all from my game, will do more tests.


What about this one, any chance to be able to test it?

 

Another question for my tests. Does it make sense to test windowed fullscreen 2020.1 vs 2020.2 or DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT was already used before 2020.2?

 

Use PresentMon.
FYI, old FSE and new FSO in Win10 under D3D12 perform the same with VSYNC OFF. With VSYNC ON, waitable object gives an edge to new Fullscreen mode that uses True Immediate Independent Flip model

 

I'm trying d3d12, overall experience is pretty good. It seems that old exclusive fullscreen doesn't work at all (it behaves the same as borderless). The only issue I have is that game usually gets stuck when switching from FSE to FS. I can hear music being played but can't click anything as game is frozen.

Game finally crashes after ~25 seconds:
Bug report case 1290288:

Code (CSharp):

1. Stack Trace of Crashed Thread 10668:
2. 0x00007FFA6DD43953 (UnityPlayer) D3D12Fence::Wait
3. 0x00007FFA6DD62762 (UnityPlayer) GfxDeviceD3D12::FinishRendering
4. 0x00007FFA6DD359F2 (UnityPlayer) D3D12SwapChain::FlushGPUAndReinitializeBackbuffer
5. 0x00007FFA6DD3354C (UnityPlayer) D3D12SwapChainBase::Adjust
6. 0x00007FFA6DD403F7 (UnityPlayer) InitializeOrResetPrimaryD3D12SwapChainHWND
7. 0x00007FFA6EF73342 (UnityPlayer) WinScreenSetup::SetResolution
8. 0x00007FFA6DE2CAED (UnityPlayer) ScreenManagerWin::SetResolutionImmediate
9. 0x00007FFA6E1F24BD (UnityPlayer) ScreenManager::SetRequestedResolution
10. 0x00007FFA6E3F8EA8 (UnityPlayer) `InitPlayerLoopCallbacks'::`2'::PostLateUpdateUpdateResolutionRegistrator::Forward
11. 0x00007FFA6E3E4F0C (UnityPlayer) ExecutePlayerLoop
12. 0x00007FFA6E3EAC09 (UnityPlayer) PlayerLoop
13. 0x00007FFA6DE2AEB6 (UnityPlayer) PerformMainLoop
14. 0x00007FFA6DE28F0E (UnityPlayer) MainMessageLoop
15. 0x00007FFA6DE2E79F (UnityPlayer) UnityMainImpl
16. 0x00007FFA6DE2F6EB (UnityPlayer) UnityMain
17. 0x00007FF61F9211F2 (BeatAim) __scrt_common_main_seh
18. 0x00007FFB34DE7C24 (KERNEL32) BaseThreadInitThunk
19. 0x00007FFB34F4CEA1 (ntdll) RtlUserThreadStart

 

Submitted new bug report with repro project as it seems like it's happening only when any Screen Space - Camera canvas is active. Case 1292076.

Took me 2 days of cutting and rebuilding my project to pieces to find it...

 

https://issuetracker.unity3d.com/is...less-and-canvas-is-set-to-screen-space-camera

Seems like not related to only 2020.2.

 

Sent another project with a button to switch fullscreen mode and max queued frames slider. 1700 fps vs 250 fps - it's an empty project so I guess cpu bound issue not gpu. Case 1293091

I'm a bit stuck now in 2020.2 with my project, can't use dx11 as exclusive fullscreen has bad fps, can't use dx12 as switching freezes the project. My only option is to disable exclusive fullscreen but players won't like it. Hopefully one dx will be fixed asap.