"Multithreaded Rendering" vs "Graphics Jobs"

[Peter77]

Unity built-in (legacy) renderer:
In the Player Settings you find the “Multithreaded Rendering” and “Graphics Jobs” options. The following text is copied from the documentation, but it sounds very similar to me:

@""

Multithreaded Rendering
Enable this option to move graphics API calls from Unity’s main thread to a separate worker thread. This can help to improve performance in applications that have high CPU usage on the main thread.

Graphics Jobs
Enable this option to instruct Unity to offload graphics tasks (render loops) to worker threads running on other CPU cores. This reduces the time spent in Camera.Render on the main thread, which is often a bottleneck.

Unity - Manual: Android Player settings

It seems the difference is that Multithreaded Rendering runs on exactly one worker thread, where Graphics Jobs might run on multiple worker threads.

• What are the pros and cons of each method? They must have different pros and cons, otherwise more than one option wouldn’t exist.
• When would I use MTR over GJ for example?
• The MTR and GJ options don’t seem to be exclusive, I can enable just one or both. Which option dominates when I enable both?

[aleksandrk]

Hi!
The options are not mutually exclusive, you can enable both.

Multithreaded rendering: graphics API calls are moved from the main thread to a separate render thread.
Graphics jobs: multiple threads prepare commands for the thread that submits graphics API calls.

If you have both enabled, main thread schedules some work for worker threads, which prepare commands for the render thread, which in turn submits graphics API calls.

[leozzyzheng2]

@aleksandrk

Hi!
The options are not mutually exclusive, you can enable both.

Multithreaded rendering: graphics API calls are moved from the main thread to a separate render thread.
Graphics jobs: multiple threads prepare commands for the thread that submits graphics API calls.

If you have both enabled, main thread schedules some work for worker threads, which prepare commands for the render thread, which in turn submits graphics API calls.

If I disable Multithreaded rendering and only enable Graphics jobs, will main thread offload all its works including something like Batch.DrawInstanced to Render Thread?

[aleksandrk]

@leozzyzheng2

If I disable Multithreaded rendering and only enable Graphics jobs, where main thread offload all its works including something like Batch.DrawInstanced to Render Thread?

There will be no dedicated render thread in this setup.

[leozzyzheng2]

@aleksandrk

There will be no dedicated render thread in this setup.

Sounds like it won’t benefit to performance?

[aleksandrk]

It depends on what your performance bottleneck is and on the target hardware. If any of those options would’ve been a clear performance benefit in all possible scenarios, there wouldn’t have been an checkbox

[leozzyzheng2]

@aleksandrk

It depends on what your performance bottleneck is and on the target hardware. If any of those options would’ve been a clear performance benefit in all possible scenarios, there wouldn’t have been an checkbox

Thanks for reply.

My scenario is I found Batch.DrawInstanced run on Main Thread will dispatch Batch.FillInstanceProperties to job worker threads but it will wait for it to finish the job. So the Batch.DrawInstanced will cost much on Main Thread.
I found enable Graphics jobs will dispatch some calls of Batch.DrawInstanced to Render Thread on Editor, but it has no effect on Android with OpenGLES 3.2, so I’m wondering if there is any way to make Render Thread or job worker thread also run some Batch.DrawInstanced to reduce the workload on Main Thread on Android with OpenGLES?

[aleksandrk]

If you want to reduce the load on the main thread, you need to enable multithreaded rendering.

[leozzyzheng2]

@aleksandrk

If you want to reduce the load on the main thread, you need to enable multithreaded rendering.

Yes, I always enable multithreaded rendering, but I found the Batch.DrawInstanced on MainThread will wait Batch.FillInstanceProperties which takes a lot of time on MainThread. I found Graphics jobs could move some works to Render Thread but it donesn’t take effect on Android with OpenGLES, so I want to know will Graphics jobs have effect on Android with OpenGLES?

[aleksandrk]

Ah! Now I get your question
No, OpenGL ES doesn’t support graphics jobs.
You can try enabling Vulkan.

[dnach]

As @aleksandrk mentioned above, on Android you can target Vulkan in order to enable Native Graphics Jobs which aim to better utilize the CPU during rendering setup. You can read a bit more on the different ‘Rendering Thread Modes’ in the API docs: https://docs.unity3d.com/ScriptReference/Rendering.RenderingThreadingMode.html

Worth noting, we are now working on a new graphics jobs threading mode which aims to remove unnecessary synchronization between the main thread and graphics jobs threads at the beginning/end of frames. In addition, we are also working to provide official Graphics Jobs support in Editor. We are first targeting DX12, but support for other compatible graphics backends will follow shortly.

[DevDunk]

@dnach

As @aleksandrk mentioned above, on Android you can target Vulkan in order to enable Native Graphics Jobs which aim to better utilize the CPU during rendering setup. You can read a bit more on the different ‘Rendering Thread Modes’ in the API docs: https://docs.unity3d.com/ScriptReference/Rendering.RenderingThreadingMode.html

Worth noting, we are now working on a new graphics jobs threading mode which aims to remove unnecessary synchronization between the main thread and graphics jobs threads at the beginning/end of frames. In addition, we are also working to provide official Graphics Jobs support in Editor. We are first targeting DX12, but support for other compatible graphics backends will follow shortly.

Good to know that it’s being worked on. Vulkan support would also be great since it’s cross platform by design (and has issues in 2021 on quest 2 which then could be included)

[leozzyzheng2]

@aleksandrk

Ah! Now I get your question
No, OpenGL ES doesn’t support graphics jobs.
You can try enabling Vulkan.

Thanks! I’m already trying the vulkan!

[leozzyzheng2]

@dnach

As @aleksandrk mentioned above, on Android you can target Vulkan in order to enable Native Graphics Jobs which aim to better utilize the CPU during rendering setup. You can read a bit more on the different ‘Rendering Thread Modes’ in the API docs: https://docs.unity3d.com/ScriptReference/Rendering.RenderingThreadingMode.html

Worth noting, we are now working on a new graphics jobs threading mode which aims to remove unnecessary synchronization between the main thread and graphics jobs threads at the beginning/end of frames. In addition, we are also working to provide official Graphics Jobs support in Editor. We are first targeting DX12, but support for other compatible graphics backends will follow shortly.

Thanks for the explaination, seems there are some compatibale problem on my android device for Vulkan, I will digging more about it.

[Voxel-Busters]

If you don’t mind, can you please tell what kind of tasks/works these are?
Are these something like

1. Uploading image/buffers data to gpu?
2. Filling up data in MaterialPropertyBlock? (When populating data for GPU Instancing)
   etc…

Thanks!