Android Multithreaded Rendering and Graphics Jobs settings collision

Hi everybody!

We are trying to improve performance on our Android project and like many other developers have lots of CPU time spent in Camera.Render. To figure out how we can improve performance just with Player Settings we have created simple test which issues 1000 unbatched draw calls and track Camera.Render time in Main Thread using Unity Profiler->CPU Usage->Timeline. All tests are made on Samsung Galaxy S8. Unity version: 2019.1.4f.

Settings we tested:
- Graphics APIs: Vulkan, OpenGLES 3.0, OpenGLES 2.0
- Target Architectures: ARMv7, ARM64
- Multithreaded Rendering
- Graphics Jobs

Interesting facts:
- OpenGLES 3.0 and OpenGLES 2.0 shows nearly equal results, so no need to provide separate info for them.
- Vulkan is about 20% faster then OpenGLES.
- Multithreaded rendering is about 1.5-2 times faster both for Vulkan and OpenGLES.
- (!!!!!!!) ARM64 is about 2.5 times faster than ARMv7 but doesn't used by default (!!!!!!!!)

The most interesting part of this test is Vulkan:
- Multithreaded Rendering (true), Graphics Jobs (true): 20.1 ms
- Multithreaded Rendering (true), Graphics Jobs (false): 20.1 ms
- Multithreaded Rendering (false), Graphics Jobs (true): 2.7 ms (!!!!!!!!!)
- Multithreaded Rendering (false), Graphics Jobs (false): 32.8 ms

It looks like Graphics Jobs are working only in case of Multithreaded Rendering is disabled. And this is the point of Player Settings collision. For Vulkan we want to disable Multithreaded Rendering, but we want to enable Multithreaded Rendering for OpenGLES. Also, there is no ability to enable/disable Multithreaded Rendering in run-time. The only thing we can do is prepare separate apk's, but it's really inconvenient...

My suggestion is to change Unity logic on selecting rendering path. The optimal way is to use Graphics Jobs even if Multithreaded Rendering is enabled. Other solution to this problem is to provide API which can change Multithreaded Rendering option during run-time.

Do you have any ideas how to solve this problem now or in the near future?

 

Thanks for reply Florian!

I have found Vulkan Submission Thread in Graphics Jobs enabled version, but Camera.Render time is the same in the Main Thread for both cases (Graphics Jobs: true, false).

My primary concern is Main Thread time. Of course we can try to move some heavy gameplay logic to Jobs, but that's not really easy task for such a huge project as ours. So we have selected the easiest possible way of optimization.

This is the case Multithreaded Rendering (true), Graphics Jobs (true): 20.1 ms



This is the case Multithreaded Rendering (false), Graphics Jobs (true): 3.33 ms


As you can see in second case Main Thread have much less to do in Camera.Render. As far as I understand GfxDeviceVK.SyncSubmissions just waiting and doesn't affect the resulting performance. Also we can see a lot of activity in Job->Worker0-4, which means the rendering is really shifted to Graphics Jobs.

But when Multithreaded Rendering is enabled things become much worse... That is why I am talking about incorrect implementation.

BTW: Thanks for the hope about Unity 2019.3 solution, but we have only 3 months before worldwide release and Unity 2019.3 will not be stable enough to use it...

 

Hi @a-dolbilov I was wondering if you ever ran your benchmarks again to test 2019.3.0a7 or greater now that the fixes are in?

 

Hi @Prodigga, sorry for huge delay. I confirm that Vulkan+Multithreaded Rendering+Graphics Jobs works as expected in Unity 2019.3.0b4.

 

From which version is the modification applied in Unity 2018?

 

is there a way to switch to vulkan or opengl after a query to a server has been made? my problem is, that only a few devices seem to have problems with vulkan. but vulkan renders more beautiful. so I want to turn vulkan off only for some devices on request.

 

I thought about that, but how can I patch the apk or change the "activity"? I have no real idea how android is working.
Anyhow: I will post more details in a new post on this vkCreateImageView exception. I am currently testing on all available firebase > testlab devices and there seems to be consistent errors on the same devices all the time.
I don´t think that my code is causing that problem since it is happening before anything is loaded.

 

Could Unity with all its resources compile a list of devices that perform better with one than the other ? In our tests the difference is stark. Either Vulkan is a little better or same as OpenGL, OR it is incredibly worse. I would love to be able to select a "pick best for device" option.

As a simple example: OnePlus 5 vs OnePlus 6T.

https://m.gsmarena.com/compare.php3?idPhone1=8647&idPhone2=9350

My friends OnePlus 5 performs decently with OpenGL but sees improvement with Vulkan. The improvement was significant enough that I would pick it over OpenGL. (I can't recall exact numbers but do remember it was a noticeable difference)

Then on my OnePlus6T, great performance in OpenGL compared to One Plus 5. Expected. 6T is newer and it's hardware is more powerful compared to OP5. Then we tried Vulkan and it ran worse than OP5. No improvement. A complete degradation in performance. A newer device running slower than its predecessor.

So what do we do? Stick with OpenGL, miss out on performance boost for OP5. There are hundreds of devices out there, who knows which device performance better/worse with one or the other?

Recently ran some tests on Firebase TestLabs. All tests in OpenGL because we've since abandoned Vulkan. On a whim I tried Vulkan and some xiaomi devices which were struggling were able to hit 30fps every now and then. Big improvement.

You can't win. You need to profile a bunch of devices to see which graphics API it responds better to, then you need to ship this preference list with the build, write a custom Unity activity to lookup this list and pick the appropriate API on startup.

This really feels like the kind of problem the engine should solve. It would benefit everyone, collectively save so many developers so much time and improve performance across hundreds of Unity Android applications "for free".

 

thanks for the android hints.

Maybe it´s to early to party, but I found the following:
I made tests with 67 google testlab devices and 3 of them had problems terminating with that vkCreateImageView Exception.
After changing these settings:
- vulkanNumSwapchainBuffers: 3
- vulkanEnableSetSRGBWrite: 1
+ vulkanNumSwapchainBuffers: 2
+ vulkanEnableSetSRGBWrite: 0
(swapchain image was off all times)
Only one device had a problem. (Asus ZenFone 4, API level 28)

Since deployment I do not see any crashes in the google play console. So let´s see....

 

It does, but you've been around long enough that to know that Unity doesn't like to solve these and prefers to let the users solve them themselves.

As for Vulkan, just give up on it, it was much more solid when it was first introduced (was faster on all devices I tested and there weren't many issues), then at some point it took a nose dive.

 

@florianpenzkofer, fyi, according to google report, I have no vulkan related crashes since I changed the parameters mentioned above.

 

@florianpenzkofer Hi. Customizing Activity (https://docs.unity3d.com/2020.1/Documentation/Manual/AndroidUnityPlayerActivity.html) works well, but how to get GPU information before calling
updateUnityCommandLineArguments()? I can get device name or id by using android.os.Build, but can't get GPU information (GLES20.glGetString(GLES20.GL_RENDERER) throws error) because GPU is not initialized at startup.

Some GPU has problem in Vulkan mode, so I want to use opengles on specific GPU-devices. Is there any solution for getting gpu information?

 

I can do that on IOS?