Bug Standalone Build extremely slow when run in Background

So the situation is as follows:
(unsing Unity 2019.3 but the problem exists for all 2019.X and maybe earlier as far as i can tell)

We are developing a network game so when I want to test the game locally I do the following:
I make a standalone build, run it. And then run another instance of the game from the editor.
So far the theory. In practice however when I run the game in foreground in the Unity editor, the background standalone instance starts massively dropping frames, instead of running with >300 FPS it drops to like 6 FPS.

Which makes it absolutely impossible to test network synchronization issues.

I post profile information of the standalone build for the frame when it runs normal (before I start running the game in unity editor) and when it starts collapsing:
(this happens both with vsync enabled and disabled)

 

There's the "Run in Background" checkbox in Player settings. Other than that the OS is in charge of scheduling, and Windows gives priority to whatever application has focus. Does this computer have a very small number of cores?

 

Yes "Run in Background" is checked. No it has 4 cores with HT (8 logical). Its def. not a windows scheduler problem. I can run other stuff in background just fine. Including 3d games

 

Hi pragmascript!
Did you find a solution? I faced the same problem.

 

Unfortunately I did not find a solution. I have to debug the network code on 2 different PCs...

 

Anyone had any luck with this? I'm running into the same problem. Runs in the background fine with a single build or when connecting with another PC, but I can't test connecting two builds from the same PC because of this.

 

Same issue with DirectX

 

(this is now on unity pro 2021.1.16f1)

 

Did anyone figure this out yet?
I have the same issue, running the same Unity app twice on the same system in a window in Windows 10.
When both windows are out of focus, they run at about the same framerate (150 fps).
When one is in focus and the other is out of focus, the out-of-focus one runs at around 32 fps, the in-focus one runs at around 250 fps.
This is Unity 2020.3.9f1. Same results with Mono and IL2CPP.

In-focus (4ms)

Out-of-focus (31ms).

 

This is on a desktop with an AMD Ryzen 2950X and a GTX 1660 Super.
I'll post some screenshots of the GPU usage a little later today.

 

I tried to get screenshots from the profiler with GPU data, but the GPU module doesn't function with the excuse of 'GPU Profiling is currently not supported when using Graphic jobs'.

In the Task Manager (Processes tab) when both windows are out of focus, the GPU use is around 41% for each.
When one is in focus, its GPU use goes to around 93% and the out-of-focus one goes down to about 3% GPU.

I suspected some kind of Windows issue, but running an app like the 'Heaven' benchmark in two windows in parallel does not exhibit this behavior and the framerate in both Windows is consistent whether they are focused or not.

This whole issue is also easily reproducible by just creating a Unity app with a single spinning cube and some way of showing the FPS and running them in parallel (Windowed, TargetFrameRate = -1, Vsync off).

Thanks for any help or suggestions!

 

Ok, I did. Case # is 1397680

 

Can someone link the issue? I can't find it in the tracker.

 

https://fogbugz.unity3d.com/default.asp?1397680_dk9uul7uemasnmne

 

This doesn't seem very likely.

If this was the case, how is it that only Unity builds/Editor seem to exhibit this behaviour?

I have never seen another applications/engine drop down to ~6 FPS when if was prev. running focused at >300FPS.

 

Hi, I'm having the same issues described here with my application. It's intended to run in the background and, for the most part, runs fine. However, on some machines when they are also running full screen applications (doesn't happen with windowed) then the app gets throttled heavily by Windows.
A workaround that has been discussed and used successfully in another application is to use IDXGIDevice::SetGPUThreadPriority. This is tricky as it obviously requires external libraries to be built to access the C++ methods necessary as there aren't any C# wrappers available. If you could look into this that would be great!

 

I'm pretty sure it is the same issue, I will try the workaround and see if it helps. Thanks for the reply

 

So after a lot of trial and error and trying various things, I discovered that disabling this option in the build settings seems to have fixed the issue for those that were having the problem with my app.



When looking into what I the cause was in my case this does make sense but that's not to say there aren't other issues that might also contribute to the same problem.

 

I have the same issue, the workaround that Fred_H posted didn't change anything for me.

I did notice that when i have two windows of the game running, if they are both out of focus, then they both run fine, but if i focus one, the other drops to a very low frame rate (by very low i mean below 8).
For example to unfocus both, i just press on an empty space on my desktop. I'm on Windows 10 with a GTX 1070.
Definitely something going on where windows or the GPU is prioritizing the focused window. I know things were working fine a few months ago, so im not sure if a windows update did this, or a unity update did (i did update my unity a few times since.)

I did try to increase the priority (from task manager) like you suggested, but that didn't work either, unless i did it wrong, could you please explain how to do that on windows.

 

would greatly appreciate if you could tell us how to do that .

 

Sorry I couldn't really get it to work, I did manage to get that native rendering plugin, imported the plugin part (dlls) to my project, but after that, I was a bit lost. I can see in the plugin example how they were using it, that seemed pretty straight forward, they were calling existing methods (in RenderingPlugin.cpp) from the library dll that they imported in their C# code, they were in a MonoBehavior.

For our case, and correct me if I'm wrong, we need to write C++ code to the RenderingPlugin.cpp file to add the code you provided above and rebuild that library. Before making any changes to the library's source code, I tried to simply compile it as is, to see if it will actually compile, but I got plenty of errors about missing references and such (e.g. it can't find assert.h). Frankly I don't know much about C++ so I'm a bit out of my element here.

Now I'm on Visual Studio 2022 in windows 10, and I noticed the solution of the plugin source files was in Visual Studio 2015, so I'm not sure if that conversion from 2015 to 2022 is what's causing the compilation errors.

Would there be a way to get a sample unity project that simply does what we're trying to do here, just increases the GPU thread priority.

 

ok no worries, thanks a lot for your help.

I already have the "Desktop development with C++" installed, restarted VS and now it's complaining about

Error    MSB8036    The Windows SDK version 10.0.19041.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".    RenderingPlugin    E:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.WindowsSDK.targets

But my VS installer shows that Windows SDK version 10.0.19041.0 is already installed.
I did notice in my VS logs that Microsoft.Windows.UniversalCRT.Redistributable.Msi failed to install, I'm essentially having the exact issue described in the link below (and their solution doesn't work)

https://developercommunity.visualst...-redistributable-wont-ins/828184?viewtype=all

anyhow, if anyone manages to update the plugin with the provided code, plz drop a link to the dll, thanks.

EDIT:
Fixed my build issue.
if anyone runs into the same problem i had
https://developercommunity.visualst...-redistributable-wont-ins/828184?viewtype=all

you gotta go through your registry keys and clear the ones related to 'Windows Kits', there's probably only one culprit in there that stores the install location, pointing it to the non-existing drive, but since the entire drive doesn't exist anymore, it's okay to get rid of all of them.

 

If anyone is looking here, here's everything you need to add

Code (CSharp):

1. #include <wrl.h>
2. #include <d3d11.h>
3. #include "Unity/IUnityGraphicsD3D11.h"
4.  
5. void IncreaseGPUPriority(ID3D11Device* device)
6. {
7.     Microsoft::WRL::ComPtr<IDXGIDevice> dxgiDevice;
8.     auto hr = device->QueryInterface(__uuidof(dxgiDevice), &dxgiDevice);
9.     assert(SUCCEEDED(hr)); // this shouldn't ever fail... but you can add error handling if you want
10.  
11.     dxgiDevice->SetGPUThreadPriority(3);
12. }
13.  
14. extern "C" void    UNITY_INTERFACE_EXPORT UNITY_INTERFACE_API UnityPluginLoad(IUnityInterfaces * unityInterfaces)
15. {
16.     s_UnityInterfaces = unityInterfaces;
17.     s_Graphics = s_UnityInterfaces->Get<IUnityGraphics>();
18.     s_Graphics->RegisterDeviceEventCallback(OnGraphicsDeviceEvent);
19.  
20.     auto unityGraphics = unityInterfaces->Get<IUnityGraphics>();
21.     if (unityGraphics->GetRenderer() == kUnityGfxRendererD3D11)
22.     {
23.         auto unityD3D11 = unityInterfaces->Get<IUnityGraphicsD3D11>();
24.         auto d3d11Device = unityD3D11->GetDevice();
25.         IncreaseGPUPriority(d3d11Device);
26.     }
27.  
28. #if SUPPORT_VULKAN
29.     if (s_Graphics->GetRenderer() == kUnityGfxRendererNull)
30.     {
31.         extern void RenderAPI_Vulkan_OnPluginLoad(IUnityInterfaces*);
32.         RenderAPI_Vulkan_OnPluginLoad(unityInterfaces);
33.     }
34. #endif // SUPPORT_VULKAN
35.  
36.     // Run OnGraphicsDeviceEvent(initialize) manually on plugin load
37.     OnGraphicsDeviceEvent(kUnityGfxDeviceEventInitialize);
38. }
39.  

 

sorry for the double reply, but is it possible that the OS or the GPU driver itself is dynamically updating the GPU thread priority? So in essence, while we do call IncreaseGPUPriority when the plugin loads, and we set the SetGPUThreadPriority, our action are essentially voided when the OS/GPU driver update the priority dynamically.

I tried setting the GPU priority to 7 (max value), and I know the plugin works, it gets loaded and is able to draw a triangle with gradient colors, I basically used the code from the example plugin.

I'm still seeing the same problem though, when I focus my 2nd window of the game, the first window's FPS drops to something unusable (like below 6) and vice versa. I double checked and my project's unity player is using D3D11.
If I un-focus both windows, then they run fine.

So at this point I'm guessing something is dynamically changing the GPU thread priority? maybe windows when we focus an application that's heavily using the GPU ?

edit:
If you limit the fps of the app, that fixes it. I limited the fps to 30 and now it’s fine.

 

yes vsync is off.

 

Any resolution to this?
Did IDXGIDevice::SetGPUThreadPriority work?
I may be getting the same issue with 2019 LTS.

 

I can confirm that when using Unity 2022.1.X the issue is not there, so this is definitely a Unity issue.
I was on Unity 2021.3.8f1 LTS, the issue was there, I switched to 2022.1.13, the issue was gone (no change in my project at all), then I switched back to 2021.3.8f1 LTS, the issue came back.

I had to switch back from Unity 2022.1.13 because it's not very stable, had a bunch of crashes with regards to NetCode.

 

This worked for me. Thanks!

 

I'm having this exact problem, with Unity version 2022.3.1f1

When I run a fullscreen game that seems to take a lot of resources (I've most recently noticed this with satisfactory) the rendering loop of my unity application seems to come to almost a complete halt. Changing actual OS thread priority to real time doesn't seem to fix this at all, and I'm also currently using DirectX12 so the ability to set the thread priority in the way documented here doesn't work with an ID3D12Device as the IDXGIDevice seems no longer supported in this way.


I also don't think it's at all reasonable to write this issue off as OH WELL. WINDOWS GPU SCHEDULER LOL
because there have to be applications that can somehow demand this priority from the OS.

I think the reality is that I have an application that does not NEED window focus, but still NEEDS to render at a high priority. I have reasonble doubt that if I was doing something like encoding a video or calculating PI to the billionth digit windows could just do whatever it wanted to that tasks priority and there would be literally nothing anyone could do about it.


I feel like there is 100% a Unity issue here. It would be nice if this was somehow acknowledged and fixed.

---
For more information. I think I've noticed this twice now recently, specifically when Windows was also running a DX12 game. I had this happen while playing Only Up, and am currently also seeing this issue with Satisfactory.
I have the same issue mentioned here with a gigantic spike on
Gfx.WaitForPresentOnGfxThread


I have an RTX 3090 and an i9-12900k
Something like the OBS encoder does not come to an absolute dead hault with this happens, as I am actively streaming, recording, and rendering video with no encoder drops or issues. The Unity game application is literally the ONLY application across my entire OS that stops rendering.


--

Okay the issue gets weirder.
I rebuilt a new simple project to demonstrate my case. Literally just an empty floor with a spinning cube on it. I hit play on my app, watched the cube spin, clicked on Satisfactory, watched the cube stop on my second monitor, repeated this process a couple times.
Then, I went to setup a scene in OBS in record mode, one that can get both monitors. Didn't record anything yet. Clicked Satisfactory, watched my app stop. Clicked the desktop, watched both apps run again.
Then, finally, started recording in OBS to capture my issue. Noticed that while recording this issue doesn't actually happen.
Stopped the recording, watching my app go back to freezing when satisfactory had focus.

Tried a second time, this time using windows snipping tool to record video. Got the pause unpase effect. Not just for the unity app, but for the actual recording timer in the snipping tool itself. (Unity, sorry I misjudged you.)

Went back to OBS again, trying to record the issue, same thing as the first time. The game and Unity seem to run fine while OBS is in recording mode. This does not appear to be the case when OBS is in streaming mode.

Tried again in snipping tool, and ended up with the app still not freezing while snipping tool was running even without OBS up and running.

Went to adjust some Unity settings, double check my graphics API etc, and now I'm currently clicking between both apps without issue. Tried my other app again, just to see, and it seems like it's currently working fine, but I don't know if I as an end user have consciously changed anything for this to happen. I tried rebooting satisfactory and my other apps still didn't freeze.
Everything is fighting for framerate, so it's not like they're all running flawlessly, but nothing seems completely starved out of GPU cycles like before.

I'm really not sure what to make of this.
I'm going to check OBS project code and see if they're doing anything crazy with GPU scheduler priority when initiating recording on windows.

--

Closed OBS, wasn't in recording so I didn't think it was effecting things, apps that didn't have focus were immediately frozen.

--

Opened OBS again, and both Satisfactory and my app are running together just fine. Nothing in record mode or streaming. I'm getting the actual application output from the main app I noticed this issue in, into OBS in a bit of a weird way, as I'm not actually capturing the game window but instead writing camera output to a render texture, and then sharing that texture via spout into shared GPU memory which OBS is then importing/using.

Inititally I had thoughts that maybe OBS is doing some weird prioritisation to boost the games it's recording, and since I only have a game capture set for FactoryGame.exe (Satisfactory) maybe my unity app was getting the short end of the stick, but I thought if this were really the case, clicking my Scene with only Satisfactory on it would reboost the games framerate and make my app come to a dead hault. It didn't. I do still have both display captures in a separate scene though, so I'm almost wondering if the display capture is smart enough to enumerate the windows presented in a game capture and boost their priority or something. My app previously wasn't on the same screen that was being captured, so maybe it's priority wasn't getting the boost. It's now on a display that is captured, so maybe behind the scenes it's still getting this boost?
I feel like it has to be something to this effect. Otherwise I'm left to something completely arbitrary inside the GPU scheduler and I'll lose my mind.
I'm using HAGS for whatever it's worth so it's not completely unreasonable that something there might not quite be sane. Turning it off for me isn't really an option as I've noticed some insane overhead in some games without it, but for other people who don't care as much it might still be an option....
I'm going to check OBS project code and see if they're doing anything crazy with GPU scheduler priority when initiating recording on windows.

--

One more update before I check OBS code for real. I notice that if the DX12 game has focus OBS itself will never even boot. I have to ALT TAB for the window to finally show up and then it finally fixes things. I feel like there is likely a deep seated hardware scheduling issue here that OBS has some work around for.