This time last year, at GDC 2016, Khronos launched Vulkan 1.0 and Khronos members including ARM released Vulkan drivers and SDKs. This year’s GDC sees the release of Unity v5.6 with the built-in Vulkan renderer. This shows Unity’s support of not only Vulkan, but also of developers that expect the very best from the Unity engine.
At GDC’17 we’ll be hosting a talk, with the same title as this blog, to demonstrate the main advantages the new API brings to developers in general and also the benefits we can expect when running Vulkan on ARM CPUs and GPUs. Marek Wyszyński, VP & Co-Founder of Infinite Dreams, will talk about their experience in developing the Sky Force Reloaded mobile game and will show some very interesting data when comparing Sky Force Reloaded execution in OpenGL ES vs Vulkan. Finally, we will have the opportunity to hear from Mikko Strandborg, the Vulkan lead at Unity, about their experience in implementing the Vulkan renderer into the Unity rendering pipeline.
It has become apparent that OpenGL and OpenGL ES are reaching the end of their life cycles, that it is impossible to evolve on top of an API that carries a lot of inherited weight after serving the industry for more than 25 years. Additionally, GPUs are now highly programmable and compute capable, the mobile platform is becoming more important, memory is being unified and processors are being implemented in multi–core configurations. This part of the talk covers the most relevant benefits of Vulkan for graphics: multithreading and multi-pass.
Figure 1. A wrap up of Vulkan benefits.
Nowadays even mainstream phones come with four cores traditional graphics APIs were not designed to run across many cores with multi-threading support. This resulted in a lot of synchronization with the CPU to manage draw calls, resulting in high CPU overhead with the CPU becoming a bottleneck, especially on mobile devices.
In Vulkan, the lower CPU load due to driver simplification helps reduce energy consumption and makes the battery last longer. Here multi-threading plays a key role by allowing the CPU to finish tasks earlier since it can spread the work out across multiple cores.
The Multi-pass rendering feature in Vulkan is conceptually very similar to the Pixel Local Storage introduced by ARM in 2014. In Vulkan you could think of the begin/end render pass functions almost like a scope. While you're inside the scope of that pass, everything you execute/draw is part of that render pass.
Especially on tiled GPUs, like ARM Mali, multi-pass allows the driver to perform various optimizations when each pixel rendered in a sub pass accesses the results of the previous sub pass at the same pixel location. In this way all the data can be contained and remain on the fast on-chip memory. That means less data transfer to the main memory and thus less bandwidth use that helps save energy and reduce battery consumption.
Infinite Dreams is the game studio behind the popular mobile shoot’em up game Sky Force Reloaded. The game features intense action and has very rich graphics. It pushes the CPU & GPU to their limits and is built using Unity.
According to Marek Wyszyński, the CEO and Co-founder of Infinite Dreams, the only way to optimize the game was to minimize the number of draw calls or modify them in a way so that they could be batched by the game engine. Draw calls are very expensive and the OpenGL ES driver is not optimal because it keeps the CPU busy for a long time. The very moment they heard about Vulkan, Infinite Dreams couldn’t wait to give it a try to see how it could improve the performance of their game. In Unity, Vulkan is just another rendering API and absolutely no knowledge is required from a game developer in order to use it - all the hard work is done inside the Unity engine.
Figure 2. Sky Force Reloaded FPS in Vulkan and OpenGL ES.
Infinite Dreams created a synthetic benchmark that can be replayed the same way multiple times to measure OpenGL ES and Vulkan performance. In Fig. 2 it is possible to see that while OpenGL ES struggles, Vulkan is able to maintain 60 fps for the majority of the time and the overall performance improvement over OpenGL ES is 15%.
Next they started to increase the complexity of the scene by adding additional objects to the benchmark level, up to the point where even Vulkan was not able to achieve 60 fps. At this point the gap between OpenGL ES and Vulkan was getting bigger. In this case, on average, Vulkan was 32% faster than OpenGL ES, as shown in Fig. 3. This demonstrates that there was extra power that could be utilized.
Figure 3. Sky Force Reloaded FPS after increasing the complexity of the scene.
During his talk, Marek will also show a very interesting video that demonstrates how the extra power that Vulkan brings to developers can be used to render more complex geometry. Fig. 4 shows a screenshot from the video where it’s possible to see how Vulkan can render a lot more particles than OpenGL ES while still maintaining 60 FPS.
Figure 4. Vulkan vs OpenGL ES in terms of scene complexity.
Marek will also show the energy consumption comparison that demonstrates that Vulkan can reduce power consumption by up to 10-12% over OpenGL ES when running Sky Force Reloaded. This means 10-12% more minutes of gameplay when running the game with Vulkan vs OpenGL ES. I’m sure any gamer will agree this is vitally important on mobile.
The final part of the talk will be a rare opportunity to hear about the experience of the Unity Vulkan team while implementing Vulkan into the Unity rendering pipeline.
I personally recommend this talk not only to Unity developers to understand what is behind when we select Vulkan in Unity as the renderer to use, but also to those developers that are implementing the Vulkan renderer into their own engines. Mikko’s tips and recommendations can save them a lot of time and effort.
Hopefully this blog has sufficiently peaked your interest to encourage you to attend the talk and learn how to get the very most from Vulkan in the Unity Engine, where some the hard work has already been done for you!
Learn more about Unity for mobile devices.