Achieve Faster CPU Rendering with Render Modes & Graphics Jobs

Know what Unity is doing behind your back with the game objects of your scene?

You’d be surprised to see how rendering works under the hood.

Most likely, all you know is that Unity swallows your game objects into its own obscure render pipeline… just for them to appear on the screen a few milliseconds later.

And that’s enough knowledge for most devs. After all, you only care about programming your game mechanics and leave all that dirty rendering work to the Unity engine.

… Until something goes wrong.

… Or until (less commonly): your curious mind wants to truly understand this shy behind-the-curtains rendering process.

But honestly?

The best motivation for you to understand will happen when you read your angry players complain about the unprofessional performance of your game. And worse, when your profiling efforts only show a barely used CPU and GPU. Like, one CPU core working at a 100% full load while all other cores sleeping bored with no work.

So, what’s going on?

Most likely: the wrong Unity Render Mode is going on.

Let me ask you: have you ever seen that ”Graphics Job” checkbox from the player settings that had apparently no effect after ticking it? Surprise: that checkbox also is related to the concept of Render Modes.

In this post, you will learn what these Render Modes are and also what that mysterious checkbox called Graphics Jobs potentially could do for you. With this knowledge at hand, you’ll speed up the CPU rendering of your game (if you go smart about it).

The Graphics APIs

First: Unity relies on a pillar technology to render anything at all: the graphics Application Programming Interfaces (APIs). Some of them are:

• OpenGL, OpenGL ES
• Vulkan
• Metal
• DX11, DX12

Familiar?

Basically, what you must realize is that ultimately Unity transforms your scene game objects into low-level commands your graphics API understands.

This process must happen because Graphics APIs do not understand the concept of scenes, game objects, materials etc.. These are just dummy abstractions that all game engines offer you to simplify your game development work.

The Translation Process: RCMD’s & GCMD’s

So for now we may call this component the scene-to-graphics-API-commands translator.

Well, it happens that this translation of “engine components” into graphics API calls is pretty expensive on the CPU side. This is because Unity has to undo all these abstractions it offered you into something more low level that, for instance, DirectX 12 understands.

Now that you (hopefully) get the main idea, we can give these components a name:

• The high-level commands are called RCMD (Rendering Commands). Here, we are in the realm of materials, renderers, etc..
• The translated, low-level commands that graphics APIs understand are called GCMD (Graphics Commands).

Since the translation from RCMD to GCMD is pretty slow on the CPU, as I said, it truly does not matter if you have an RTX 5090… if the bottleneck is in this draw call translation pipeline. Your powerful GPU will be bored to death. Indeed, you might be better off using one of these crappy Intel iGPUs for that matter.

So we must get this conversion of RCMDs to GCMDs to happen FAST or you will be starving the GPU of your players.

The Render Modes in Unity

And how exactly this scene-to-graphics-API-commands conversion happens is called Render Mode. So the Render Mode is the performance strategy Unity uses to perform this translation.

Things are starting to make more sense now, aren’t they?

Obviously there must be multiple Render Modes in Unity. Otherwise this post would make zero sense. Here are those:

• Direct rendering / single threaded: the main game thread does everything. The main thread fully converts “Unity scenes” into “graphics API calls”.
• Multithreaded rendering: the main thread passes your scene contents to the Render Thread, which then converts your content into the API calls.
• Graphics Jobs: the main thread and its job workers (more threads) pass your scene content to the Render Thread and its own job workers (more threads) for the final conversion to happen.

Basically, that’s how I put it simply any time I talk to my performance team and Unity consulting clients.

Yet the curious devs don’t stop there and start to ask me about the specifics of each mode. Questions that I like and am prepared for. The kind of questions asked by the type of clients I like to work with.

Indeed, each Render Mode has some nuances. For example, the Graphics Jobs Render Mode has actually multiple “sub Render Modes” you can choose from:

• Native Jobs
• Legacy Jobs
• Split Jobs

Again, all of them have different performance profiles depending on the type of game you are making. The wrong choice may be impacting your CPU rendering performance up to 50%. At least, that’s what I have seen with our Unity performance consuling clients.

But I don’t want to overwhelm you with tons of information in this short post. Actually, you don’t even have to know all the details to achieve a good-enough result. Because most of the time you’ll just want to tick the Graphics Jobs checkbox and use a modern Graphics API that supports this Render Mode.

If you want to really dig deeper into render modes, I already talked about them extensively in the Unity Performance Taskforce membership.

All you need to remember (for now) is:

Render Modes dictate how Unity distributes the CPU work to convert your game objects data into actual API calls such as GPU state setting and draw calls

If your game studio could use a performance boost going forward, let’s have a chat.

Book a free call with my performance consulting team or shoot me an email.

Ruben (TheGameDev.Guru)