How to Improve Unreal Engine Material Shader with Adreno Offline Compiler

We recently integrated the Qualcomm Adreno Offline Compiler in our Unreal Engine fork. Details can be found in our documentation.

Dive in to learn how Adreno Offline Compiler (AOC) can help you analyze and optimize the material shader performance.

Before AOC was integrated, Unreal developers didn’t have a fast, iterative way to improve the material shader offline for Meta Quest. As a workaround, two common methods were utilized:

With the release of AOC, Quest developers can now access rich shader stats and collect them offline with minimal effort, greatly shortening material iteration time.

As shown in the picture above, AOC provides rich shader stats for different shaders (VS, FS, binning VS, etc.) directly inside the UE5 material editor. Additionally, AOC supports various command line options including GPU arch targets, view mask, graphics APIs, and more, which gives developers and game engines greater flexibility. Note: All of the AOC stats are explained in detail in the OfflineCompiler.html installed together with binaries.

AOC is now well integrated into the Shader Stats window of Unreal Engine, and developers can access and export all shader stats easily. Please visit our documentation for usage details.

Please note that we recommend using AOC to check the material performance trends by changing the material properties and then checking the shader stats changes. We don’t recommend using AOC to compare the performance of materials whose shaders could be hugely different—for example, when one material has flow controls and many memory accesses while the other has high register pressure. In this case, it’s very challenging to use AOC to estimate the performance difference.

To better demo AOC’s effectiveness, we’ll go over several use cases below where we change some material’s properties and then check the performance trend by using shader stats of AOC, shader stats of RenderDoc, and the realtime App time. Follow the links below to set up your environment (all use cases were run using UE5, AOC1.3, and Meta Quest 2):

Note: We use AOC1.3 because RenderDoc uses the same stats, making it easier to compare the results between the two tools (AOC1.3 has a stat called “Shader processor utilization percentage” and AOC1.4 has “ALU fiber occupancy percentage,” which are similar but not identical). For GPU real-time measurement (example output below), we’re only using the App time for each use case.

04-16 23:21:46.004 475 2186 I VrApi : FPS=72/72,Prd=29ms,Tear=0,Early=0,Stale1/2/5/10/max=0/0/0/0/0,VSnc=0,Lat=-1,Fov=0D,CPU4/GPU=4/3,1478/490MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=2092MHz,Free=3030MB,PLS=0,Temp=33.7C/0.0C,TW=0.00ms,App=3.86ms,GD=0.00ms,CPU&GPU=10.07ms,LCnt=1(DR0,LM0),GPU%=0.28,CPU%=0.28(W0.32),DSF=1.00,CFL=19.79/21.58

The four use cases below demonstrate how you can use AOC to analyze and optimize material shader performance.

For all use cases above, we focused on the common stats between AOC and RenderDoc to show an apples-to-apples comparison of AOC’s effectiveness. But, even for the common stats, the absolute values of AOC and RenderDoc might be different because the online GPU compiler (used by RenderDoc) works with other driver data on-the-fly and does much more optimizations than the offline AOC.

The use cases above demonstrate how you can better understand and optimize your apps using AOC. There isn’t a single stat that can tell you if the material performance trend is good or bad—instead, you can use different shader stats for different materials based on your unique app.

From a high-level perspective, parallelism and memory access are two critical factors affecting shader performance. Register pressure can affect the parallelism heavily while memory access can introduce major latency if they aren’t hidden well. That is why “register footprint,” “ALU fiber occupancy percentage,” and any memory-related stats, including texture ones, are often interesting.

On the other hand, if the material uses complex instructions or if it uses flow controls which could have bad performance penalties, then you might want to focus on “Complex instruction count” and “Flow control instruction count.” Normally, ALU instructions are very fast, and that’s one of the reasons why it’s important to be careful of “Total instruction count,” which can be misleading. Higher “Total instruction count” doesn’t necessarily indicate bad performance, and a detailed look at other stats will help inform what further performance trend could look like.

Unreal Engine’s framework doesn’t support offline compiling the entire shader pipeline (VS+FS) well. As a result, when AOC is integrated into Unreal Engine, we always compile each shader, VS or FS, separately with AOC, and we assume there are no cases where shaders could be optimized greatly by compiling the whole shader pipeline (for example, VS output not being used by FS). We also assume there are only VS and FS (no other shader types—Multiviews are also supported).

Currently, the integration is only supported in Meta’s Unreal Engine fork. We’re working with Epic to upstream this feature to the Unreal fork.

As shown in the examples above, we believe AOC is a powerful tool that can help you analyze and optimize the material shader performance. Thanks to its ability to run offline, AOC enables you to greatly reduce the material iteration time. To get started, check out our documentation.

For more news and updates for developers building on Meta Quest, be sure to follow us on Twitter and Facebook.