Search Issue Tracker
Fixed in 2020.1.X
Votes
0
Found in
2018.3.5f1
2019.1
2019.1.0f2
2019.2
2019.3
Issue ID
1166735
Regression
Yes
[Android][Vulkan] Performace hit in PostLateUpdate.PlayerUpdateCanvases when tapping a Button on Mali GPUs
To reproduce:
1. Open the QA's attached project
2. Build and Run a Dev Build with "Autoconnect Profiler" option selected
3. Open the Profiler and switch the CPU view to Hierarchy
4. Expand Player Loop and select PostLateUpdate.PlayerUpdateCanvases
5. Observe the spike when tapping the button
Expected result: Performance hit is very slight
Actual result: The graph spikes up to the 60fps limit
Reproduced with: 2018.3.5f1, 2018.4.5f1, 2019.1.12f1, 2019.2.0b10, 2019.3.0a11 <- Performance spikes on both Mali and Adreno GPUs
Not reproduced with: 2017.4.30f1, 2018.1.9f1, 2018.2.21f1, 2018.3.4f1
Reproduced with devices:
Huawei P20 8.1.0 HiSilicon Kirin 970 Mali-G72 OpenGL ES 3.2
Samsung Galaxy Note8 9 Exynos 9 Octa 8895 Mali-G71 OpenGL ES 3.2
Not reproduced with devices:
Oneplus OnePlus6T 9 Snapdragon 845 SDM845 Adreno (TM) 630 OpenGL ES 3.2
Xiaomi MI MAX 7.0 Snapdragon 617 MSM8952 Adreno (TM) 510 OpenGL ES 3.2
Notes:
On 2019.3.0a11 the performance spikes reproduce on both Mali and Adreno GPUs
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
Resolution Note (fix version 2020.1):
In this case UI rendering has to wait for previous frame's UI rendering to complete. This would otherwise be done in "WaitForPresent".
I'm closing this as "By Design" because the overall frametime is constant.
There is slightly less overlap of main an render threads when this happens, so in theory this could cause a slight performance hit, but so far we have not seen this in a real project.