I have been working on Unity 2020.1.0f1, then when I have seen the new 2020.2.0f1 finally released I updated
it forces me to use the new URP versions which is nice, but i have noticed a really big performance problem,
from using the 2020.1.0f1 where my game on Quest went at 72 fps (and 90 on Quest 2)
to using 2020.2.0f1 where my game went from 72 to 30 ~ 50 fps
Also, the Editor Play mode performance has decreased bt a lot.
Any more information on this? I am experiencing the same issue.
In a test scene, I have noticed that the profiler reports a very long sempahore.WaitForSingle of ~40ms on the CPU while the GPU âonlyâ shows a total computation time of 15ms.
GPU time comes from
5ms DrawOpaqueObjects
5ms DrawTransparentObjects
2.5ms Camera.RenderSkybox
2 ms FinalBlit/Graphics.DrawProcedural
unfortunately, I cannot profile my previous build for comparison, because the profiler will not attach, reporting âConnection is no longer valid. Calling auto disconnect.â
Hello, thereâs a known URP regression in Playmode, tracked as issue 1277222, with more details in [this post]( https://discussions.unity.com/t/807644 page-2#post-6699508), but it might be good to report a separate bug report for each of your cases to provide further context, ensure that itâs not a different issue and ultimately helping our teams in finding and shipping a solution to these.
Is that Semaphore on the main thread or the Render thread? Because the regression I mentioned is on Render Thread performance which would push out when the GPU can be done with the frame further into the next frame and the Semaphore on the Main thread has to wait on that whole process. So if your GPU isnât too busy, itâs likely down to your render thread CPU performance. Timeline view would be good to look at for this, with the list of common profiler markers handy to help make sense of that.
Thanks for the response!
I am profiling the apk running on the Quest. I am not sure about playmode.
I rolled back to Unity 2020.1.17f1 where I find in the same scene about half the render time on the GPU for each of the mentioned calls. So it might be that the CPU render thread also takes longer, but there definitely is a severe impact on the GPU as well.
The issue affects URP simple lit, custom shader graphs, skybox, so I think it is not a problem with specific shaders.
Going back to Unity 2020.2.4f1 takes a lot of time, and so does building the apk (unfortunately, only with build+run can I attach the profiler). Also the saved profiler data seems to be incompatible between the two unity versions, so its hard to compare. Thus, I probably will not find the time to create a decent bug report for this.
Yeah, we sadly broke the compatibility and can no longer ship a bugfix to 2020.2 as it is closed for changes. You can load the data into Profile Analyzer though and save it out as .pdata from there, which is unit version agnostic.
As for the attaching⌠We are working on several fixes/improvements for those but those too wonât evere reach 2020.2 anymore.
Itâs worth nothing that I canât even repro the perf regression on my repro case using 2020.2 and URP 10 because itâs fine on my tests on all versions before 2021.1. It does drop the perf considerably only on URP 11 when used in VR (HDRP 11 and built-in are fine with same VR setup on 2021.1). Also worth noting that it happens even on a blank scene, doesnât require any geometry to be rendered (can only reach 30fps in VR).
Itâs certainly possible tha there are several separated performance regressions on this area, which is why additional bug reports can be useful to help cover all bases. Thank you for that report
Are there any updates on this?
I took the time to reproduce the issue with the most basic setup and submitted a bug report including some profiler data.
To reproduce (at least some of) the performance regression, it is enough to:
create a new URP project
add Oculus VR plugin package
convert main camera to XR rig
activate Oculus plugin
Hit play (needs VR device, of course)
From Unity 2020.1.17f1 to Unity 2020.3.15f2 the GPU time increases on my hardware from 3.5 ms to 4.5ms
The same effect appears in a standalone android build on the Oculus Quest 2. For this I set:
Minimum API Level: 26
Scripting Backend: IL2CPP
Target Architectures: ARM64
Stereo Rendering Mode: Multiview
(not sure, if these settings affect the issue at hand at all)
Here I see an increase in GPU time from 13 ms to 14 ms and CPU time from 19 ms to 22 ms. Profiler overhead is included.
In a larger project I get an increase from 8ms to whoppinâ 13ms just by upgrading the Unity version. I also tried 2021.1 where a similar-sounding bug is reported as fixed, but I see no improvement in my case. Unfortunately, this keeps me stuck with 2020.1.17f1 which is no longer officially supported.
The original bug got resolved and never existed on 2020.3 so what you experience and (thanks for the report btw) reported seems like a separate issue. There are many moving pieces that can contribute to performance regressions so additional bug reports are usually always a good option, especially if they keep you from upgrading through Tech releases towards LTS. That path should never be blocked and we need to know of any details that do block it.
If youâve got the issue ID for the bug you reported, I can give the team a heads-up on this one.
Yeah this happens also to me but Iâm not sure how to submit a bug report on my side for this case, itâs pretty simple, just doing what olejuer says
This keeps me also with fear to upgrade, along with the URP 10 update which breaks ALL single-pass rendering instance custom blit bassed postprocessing
In fact, i think that the performance problem is here from URP 10, maybe that has something to do?
@MartinTilo thanks for your support. The bug ID is 1357411 , but it has not been handled by Customer QA yet. I sure hope that I can upgrade my project some time. The biggest hurdle is that the process of âupgrading, importing, adjusting shaders to new URP, build, testâ easily takes a couple of hours or days. So I cannot possibly try this regularly.
I generally always update minor versions. These are supposed to be bug fixes and should not break things. So far, I have not had issues with upgrading minor versions. So I recommend you try upgrading to the latest minor version, which is 2020.1.17f1. Of course itâs always a good idea to have version control for backup.