Showdown on Quest Part 2: How We Optimized the PC VR demo for Meta Quest 2

Showdown is a PC VR demo built by Epic Games with Unreal Engine 4 (UE4). First shown at Oculus Connect 2014, Showdown presents an action cinematic in bullet-time slow motion; it was originally released for the Oculus Rift.

We converted the Showdown demo to run on Meta Quest 2 with the goal of maintaining the visual fidelity of the PC version. The finished project runs on Quest 2 at a consistent 90 FPS. To reach that mark, we had to significantly optimize CPU and GPU performance for the mobile renderer.

In our previous post, we examined how Application SpaceWarp (AppSW) improved the performance of Showdown and demonstrated how to profile the impact of AppSW and other render settings.

In this article, we’ll review how we converted Showdown to Quest 2, our conversion process, how to identify performance bottlenecks, and describe specific optimizations to address CPU and GPU heavy apps. This post is intended as a reference for developers porting their own project to Quest. We may mention settings or optimizations that weren’t used in Showdown but might be useful to other developers.

You can find the Quest app on App Lab and the project source code in the Oculus fork of UE4.27. We recommend VR developers stay on the Oculus fork of UE4.27 until our support for VR in UE5 is ready for production use. See our documentation on how to gain access to the Oculus fork and what it includes. Showdown for Quest depends on the forked version of Unreal Engine as it includes AppSW and the mobile tonemap subpass. These features have not been upstreamed to Epic’s repo yet at the time of this post’s publication.

Please note that while the Showdown app does run on Quest 1, all profiling and performance data in this doc were collected on Quest 2.

Starting with the PC VR project, our conversion involved several phases:

After opening a copy of the PC project in the Unreal Editor and adding Android to the Supported Platforms, there are some other less obvious settings to change. A quick way to find many of these settings is to use the Oculus Performance Window.

Additional details on setting up your project for Quest can be found here.

Other changes we made to the project outside the scope of this document include:

Our next step was to get the project simplified as much as possible to get passable performance (at or above 60 FPS) on Quest. To do so we:

At this point we are able to package and run an apk on device though it still suffered from poor framerate and frequent hitches. If you encounter similar issues, don’t worry. We’ll address each of these, but first collect some performance metrics to measure improvement as changes are made.

The key to optimization is identifying the specific system resources that are overloaded. With that knowledge, you can target features and processes that are taxing those resources and optimize or eliminate them.

Each time you profile your app, ask these questions:

Let's take a look at our process for determining bottlenecks and ways to fix them. We may describe several tools for examining each area. There is significant overlap between profiling tools and every developer has their own preferences, so we try to present multiple options.

When you need to determine whether your bottleneck is on the CPU or GPU, there are several ways to check which is pushing the framerate down.

When profiling the CPU you will see two main threads; the game thread and the render thread. If either thread takes more than the desired frame duration it will negatively impact your framerate. Let’s look at how to determine if these threads are taking too long and how we can optimize them.

Which thread is taking too long?

UE4 Session Frontend

ADB

From the overlay you can determine if the game or render thread is taking longer. In the screenshot above, the app is clearly constrained by the game thread. Next we will look at how to optimize both game and render threads.

The game thread handles all your game logic and physics simulations. It can get bogged down by lots of actors and complex blueprint logic.

Epic provides helpful details about particle system optimization here and here.

The render thread issues draw calls to the GPU. Combining objects into a single draw call is more efficient even if there is no reduction in geometry data because of the overhead of preparing and issuing the draw call. The primary way to improve render thread performance is to reduce draw calls by combining actors and utilizing instancing.

tldr: Reduce draw calls

Instancing - Instancing allows you to render a batch of identical meshes in a single draw call. The vertices of the mesh are already available to the GPU. However, the GPU also needs a transform to render each occurrence of the mesh. Instancing stores those transforms in GPU memory so they can be batched into a single draw call.

Epic provides more details on render thread optimization here.

Unlike other GPUs which have different compute units for vertex and fragment shaders, Qualcomm uses a unified shader architecture. The same cores run vertex shaders and fragment shaders. You won’t encounter a situation where you have so much fragment work that vertex work can be done in parallel without cost.

That said, it is still useful to know which stage, fragment or vertex, is demanding the majority of your GPU time as different optimizations apply to each.

You can use ovrgpuprofiler to see how much time is spent on fragments versus vertices.

Another test is to render fewer pixels by shrinking the app’s render scale to something small, like 0.2. This will render fewer fragments, but retain scene complexity.

Vertex heavy apps have issues with scene complexity. This is essentially too many triangles rendering at the same time.

tldr: Reduce triangles/vertices

Fragment heavy apps have issues with shader complexity. In effect, too much time is spent calculating individual pixels.

tldr: Simplify shaders

Material Analyzer - Identifies all materials or material instances in your project.

Some optimizations provide significant performance improvements for both CPU and GPU. As these don’t fit neatly into the above categories, we will discuss them here.

Before - Infiltrator bounding boxes extend back to root.

After - Tighter bounding boxes result in more efficient object culling

tldr: Eliminate runtime shader compiling

PSO Cache - Collect shader data ahead of time and build it into your application to compile the shaders on startup. On the fly compilation can tax the CPU and cause temporary frame rate reduction or hitches.

There were very obvious hitches in Showdown on first playthrough that were not present the second time through the sequence. Unreal Insights showed the hitches as PSO Vulkan Creation. You can also see these hitches with OVR Metrics as dips in the FPS graph. When built with a properly generated PSO cache, the full sequence runs without hitches the first time through. This is especially important to VR applications as even small hitches are much more noticeable to the user than on a monitor or mobile device.

This Unreal Insights screenshot clearly shows the hitches caused by PSO creation.

See the Unreal documentation for details on setting this up. You need to make a special build and play through your entire app to collect PSO data, so wait to do this until the project is nearly finished. Once configured, it is fairly simple to capture cache data again if needed.

The Showdown source includes GeneratePSOCache.bat to handle pulling data files from the headset, building the csv, and moving it to the project directory for packaging. You can modify the parameters of this script for use in your own project.

Now that you’ve seen how we optimized Showdown, you should have a better understanding of what it takes to port a PC VR project to Quest 2, how to find CPU and GPU bottlenecks, and how to optimize your application accordingly. Please check out the project on GitHub and post to the Oculus developer forums with any questions.