Unity: The little default setting that kills mobile performance I wished I knew sooner (TLDR: It's Vulkan)

Hey all! I just found out about something that quite possibly gave me the biggest "BRUH" moment in my career as a Unity developer. I just want to share this experience of discovery with you all and who knows? Maybe this is new to you too (it probably isn't).

So let's talk about an innocent little default setting of any newly-created mobile project. Here it is:


 

This doesn't look wrong on its face, right? Vulkan is a low-level graphics API that usually sees better graphical performance and power efficiency in desktop and console games. Surely this is the better choice for graphics API. Or so I thought, so did my colleague think. The thought of Vulkan being the culprit of our game constantly dipping below 50fps even with a very simple scene never crossed our mind.

What my colleague thought was going on was a combination of Linear color space, post-processing effects and HDR causing this performance impact. He ticked on Auto Graphics API, which doesn't let you build with Linear color space, so he switched the color space to Gamma, along with disabling post-processing and HDR to produce a build. Sure enough, it performs better, maintaining 60fps for at least 100 3D objects on the screen.

But something doesn't seem right to me. I made my own build with HDR and post-processing disabled, but left the default values on the Player settings for Android and... the old performance dips return. Huh... So Linear color space is the culprit after all? That can't be right, Linear color space has some overhead comparatively to Gamma, but none this bad that I've ever heard of. That's when I started wondering something: What is it really using when I tick on "Auto Graphics API"? Through some runtime print-debugging using Unity In-Game Debug Console (Disclosure: I am a contributor to this project, the author of this project did not sponsor me to promote it), I found out that it was running on OpenGLES3.

This gave me an idea to start an experiment. I'm going to compare 2 builds: Build #1 with Gamma color space, HDR and post-processing disabled, BUT Auto Graphics API turned off, making Build #1 use Vulkan. Build #2 goes in the opposite direction - Linear color space, HDR and post-processing enabled, even MSAA 2x thrown in for good measure, all the performance overheads we thought were the issue. Build #2 has one more difference: I enforced it to only use OpenGLES3 as the graphics API.

The results are wildly beyond my preconceived expectation: https://imgur.com/a/iEDeKsv

Build #1 and #2 are represented in screenshot #1 and #2 respectively. The FPS number in both screenshots are on the top-left corners. Unity Vulkan performance is so bad and slow that stacking the overhead of Linear color space, post-processing, HDR and MSAA 2x on top of OpenGLES3 is still faster.

This is when I started searching around to see if anybody has seen worse performance on Unity Vulkan on mobile and sure enough, I found some, but not enough:

https://forum.unity.com/threads/vulkan-works-very-slowly.479189/

https://forum.unity.com/threads/vulkan-api-poor-performance.501381/

Well, add this post to the list of complaints toward Unity Vulkan for mobile. Please spread this awareness around. It's bad enough that a nominally low-level graphics API could run so unexpectedly slow on this engine, but the fact it is set as the default graphics API for mobile should be a source of shame.

Unity Technologies, your Vulkan renderer is not ready for production, not even in your LTS releases, and not even in your latest 2021 releases. Yes, I tried the Vulkan renderer in 2021.1.18f1 too, the performance is still bad. The least you could have done is putting OpenGLES3 on top the list of default graphics API and mark Vulkan as one of your preview/experimental features.

Thank you for reading. This post was written after many hours of building and experimenting on my own. I hope my time was not wasted and hope this awareness spread far and wide among Unity mobile developers.

Comments

Post a Comment

Popular posts from this blog

A better way to get letterboxing in Unity

Image
Alternative title: A critique of the existing Unity letterboxing solutions and how to improve them In a video titled " Handling different aspect ratios in your Unity 2D games ", Rabidgremlin pointed out a real issue with aspect ratio scaling in Unity: Different section of your game world is cut off from view when you switch aspect ratio due to Unity trying to preserve the vertical FOV of a camera at every moment. However, the solutions he chose have... problems. You see, the solution that Rabidgremlin chose for this issue was an asset on the Unity Asset Store called " Auto Letterbox ". The way this asset implements letterboxing is:  - At runtime, in a Start method, find all cameras in a scene using a FindObjectsOfType<Camera> call, save them to a list, modify each of their viewport rect to limit what they can display to fit the target aspect ratio. - Instantiate a new camera, set its background color to the color you would choose for your letterbox, set its...
Read more

CSS-like layout for Unity UI - Lessions from web development workflow

Image
Unity UI really is a pain, especially for mobile - the environment which the engine is really used widely in. You put everything into place for one screen aspect ratio, and then you switch to another screen aspect ratio and suddenly, the whole thing breaks. Left: Standard 9:16 layout. Middle: Same scene, in iPad Pro 11 (highest aspect ratio scenario). Right: Same scene, in Xperia 1 III (lowest aspect ratio scenario). This is a longstanding issue with Unity UI that has yet to be comprehensively covered by any guide I can find. Unity developers are just sort of... expected to figure this out. A major part of this issue is that Unity Editor's interface just naturally guides you toward using pixel count to layout UI elements, when this is absolutely the wrong way to handle multiple resolutions. Pixel numbers are absolute in Unity UI. Even with a Canvas Scaler set to a fixed reference resolution, it still cannot account for multip...
Read more

SortedAction - Guaranteeing order of execution in pure C# delegate

Image
There is something comforting about looking at a UnityEvent when serialized in Unity Editor's Inspector. It executes the actions assigned to it from top to bottom, in that order. No runtime accident can happen, this order of execution is pretty much guaranteed. Order of execution can make or break the logic of any program - did you refresh the money label before or after you subtract the amount of money paid for a restaurant meal? Order of execution is such an important concern that rearranging the actions on UnityEvent has been a recurring question asked many times on the Unity official forum, and a feature implemented by just as many packages . Order of execution is serious business. How then do we control order of execution without UnityEvent ? Surely you will encounter scenarios even within a Unity project where you have only access to pure C# delegates, such as a static event. In a pure C# delegate, actions are invoked in the ordered they are registered. This presents all...
Read more