GPU Driven Rendering In Unity

[Tim-C]

@Walter_Hulsebos

The errors I got from this setting don’t log to the console, only the log seemingly.

It mentions I’ve got a warning in the bottom bar of the editor:

The aforementioned warning not being visible in the Console
**

Can you check the editor log?

[optimise]

@Tim-C

Performance
The GPU Resident drawer is specifically a CPU time optimization and may change GPU performance characteristics; please read to the end of this section to understand more.

How much CPU time is gained varies depending on the content that is rendered. Specifically content with more instancing and similar will benefit more as less draw calls will need to be submitted to the GPU. From our testing we have seen some larger scenes benefit massively, halving the CPU frame time. Smaller scenes also tend to benefit but often only show marginal improvements.

Here we have some numbers from an internal test project, your scenes may differ so please profile on your own projects to be sure.

On the project in the Editor running on Metal we go from about 15ms main thread rendering and 31ms render thread time with the regular Game Objects path

Hi. Does dots mobile project that using entities graphics will also benefit from this new GPU Driven Rendering feature?

[Tim-C]

They will not. Entities graphics is already going via this rendering pathway (batch renderer group) so already has the benefits.

[Reanimate_L]

@Tim-C

Give it a go with the hdrp spaceship project.

Not sure what happened here to be honest
Also the ARUI Grid Map VFX are broken here, everytime camera looking at the map the fps just dipped to single digit. . .

ON

OFF

[Tim-C]

This is so fast on the cpu for you that there is barely any difference before and after. Guessing you have a very powerful pc?

[Reanimate_L]

@Tim-C

This is so fast on the cpu for you that there is barely any difference before and after. Guessing you have a very powerful pc?

I guess so… i’m on Ryzen 7 5800x but it seems i’m GPU bound as i have to reduce the scaling to 80% to get stable 60+ fps, well except when looking at the map

[Tim-C]

Yep the cpu time is tiiiny on your pc so gpu bound makes sense

[optimise]

@Tim-C

For quite some time we have been working on some deep performance improvements to how we do rendering and batching of draws for Unity. These improvements are designed out of the box to ‘just work’ with projects you have already created with URP and HDRP. We would like to share this work with you now so that we can get some feedback… We want it to be rock solid and work for all platforms that are capable of handling this improvement. What is described in this post is available in 2023.3a8

Seems like currently official needs to create another different solution to support game object land. For the long term future improvement, I would like official to consolidate dots and game object land solutions into one to reduce maintenance cost significantly. The solution to achieve it is to change game object rendering part to use entities graphics that everything at game object is still work exactly the same like before. So basically the rendering part become entities and game objects syncs transform to entities under the hood . But before that I think official needs to merge RenderPipelineManager.DoRenderLoop_Internal() into entities graphics to remove the duplicated rendering logic and also burst rendering logic as much as possible. The last step is to completely remove built-in rendering pipeline since entities graphics not support built-in meaning that needs to make sure entities graphcis + urp performance is similar to or better than built-in.

[Tim-C]

@TJHeuvel-net

Super interesting development! We’ve been investigating developing this using the Graphics.RenderMeshIndirect api, but its great to see this builtin. Ill definitely try to share some of our results.

Reading the commit (https://github.com/Unity-Technologies/Graphics/commit/e23606ac43245be74c2607dd1dd58aab21fc03ad?diff=unified) im a bit confused. Is it the case that now GameObject rendering can use BatchRendererGroup, and secondly that brg can be done gpu driven/indirect?
Does this mean dots rendering gets this too of the box?

Cant wait to learn what the other tiers are too!

Yep so this puts gameobjects through the batch render group path. We render via instanced draws in this first milestone. In the future we will be using indirect and other approaches.

[TJHeuvel-net]

We’ve recently been experimenting with HDRP for our game (Isonzo, online fps) and have ‘upgraded’ one level. Esp now also trying out the alpha, its fairly broken, but plenty of objects render anyway.

Without the GPU resident drawer we seem to be hovering at 10.5ms CPU time, 9ms renderthread

With it enabled this drops to 9ms cpu, and 7.5 renderthread. For a gain in ~20fps.

This is on my fairly high spec machine, cant test on consoles because that version of the editor isnt out yet. Also note that this was in editor, but with C# set to release mode, burst to force sync compilation.

Either way, we’re excited and cant wait to use this! We’d love to share our project, if you are in need of a large test case

[Tim-C]

@TJHeuvel-net

Either way, we’re excited and cant wait to use this! We’d love to share our project, if you are in need of a large test case

When you get either the project or a representative level (content only) upgraded to 23.3 we’d love to do some internal testing on it - upgrading the project on our side might be too a bit difficult for us though.

Really happy to hear the gains you are getting!

[optimise]

@Tim-C

Yep so this puts gameobjects through the batch render group path. We render via instanced draws in this first milestone. In the future we will be using indirect and other approaches.

For indirect, do u mean the parameters to the draw calls are stored in GPU memory that most of draw call work now can directly done at GPU and reduce CPU works massively?

[slime73]

This is an exciting feature - I’m eager to see how it evolves and expands over the next while!

Does the new system work with Unity’s built-in texture mipmap streaming capabilities? I didn’t see it mentioned anywhere.

[Tim-C]

@slime73

This is an exciting feature - I’m eager to see how it evolves and expands over the next while!

Does the new system work with Unity’s built-in texture mipmap streaming capabilities? I didn’t see it mentioned anywhere.

We have to do some fixes to the lightmapping side of it to make that work (happening right now), but apart from that it should work exactly the same.

[Tim-C]

@optimise

For indirect, do u mean the parameters to the draw calls are stored in GPU memory that most of draw call work now can directly done at GPU and reduce CPU works massively?

We still do frustum culling on the CPU then it’s possible to inject a compute shader to cull further (for example do gpu occlusion). Frustum culling on the CPU is still beneficial as if you do GPU frustum culling it’s possible you end up with A LOT of empty draw calls (post gpu frustum culling) which takes time to submit. There is always some submit step needed from the CPU and keeping that small is still a good idea.

[Walter_Hulsebos]

@Tim-C

Can you check the editor log?

Sorry about the delayed response, it’s not specific to this option, it was just the first time I’d seen it.
It’s a bug I’m having with that Unity version in general, I’ll be making a proper bug report via the normal channels.

[Tim-C]

@Walter_Hulsebos

Sorry about the delayed response, it’s not specific to this option, it was just the first time I’d seen it.
It’s a bug I’m having with that Unity version in general, I’ll be making a proper bug report via the normal channels.

Thanks

[crushed_unity_dreams]

hello, i am achieving outstanding results with this over my previous benchmarks outside of this renderer modification (also, editor just seems to preform 10x better in this alpha than other 2023 versions, making me miserable in versions < 2023.3 alpha.),

I had a couple questions:

1. does this work with all shader graph shaders? Or is there something I must do to make them work with this?

2. my movement test was abysmal as expected(and rightfully so since that was just CPU, and had nothing to do with renderer) as it was not burstified, or utilizing ECS, or any entity component system(or occlusion culling), however, this is easily rectified, but my question is now, can I simply use regular game instanced object when using ECS code should I need them moving?
   This new render pipeline option seems to permit this workflow now? My hybrid objects instanced mesh containing objects will just gain a boost from this system + being able to utilize ECS code? So I still need a sub-scene or no.

[Reanimate_L]

@Tim-C out of curiosity, is there any significant difference in the implementation between this instanced drawing and this repo GitHub - Unity-Technologies/brg-shooter: Unity blog-post sample showing BatchRendererGroup and Burst/JobSystem. Focus is high performance even on budget mobile devices. Unity 2022.3.5 or above required? are they any performance different between them?

[Tim-C]

@retired_unity_saga

hello, i am achieving outstanding results with this over my previous benchmarks outside of this renderer modification (also, editor just seems to preform 10x better in this alpha than other 2023 versions, making me miserable in versions < 2023.3 alpha.),

I’m happy to hear this is working well for you

1. does this work with all shader graph shaders? Or is there something I must do to make them work with this?

It will work with any shaders that are Entities rendering / BRG compatible. Out of the box that should be the vast majority (I think it’s actually all standard 'used on a mesh renderer types, but don’t want to be wrong by claiming that as fact).

2. my movement test was abysmal as expected(and rightfully so since that was just CPU, and had nothing to do with renderer) as it was not burstified, or utilizing ECS, or any entity component system(or occlusion culling), however, this is easily rectified, but my question is now, can I simply use regular game instanced object when using ECS code should I need them moving?
   This new render pipeline option seems to permit this workflow now? My hybrid objects instanced mesh containing objects will just gain a boost from this system + being able to utilize ECS code? So I still need a sub-scene or no.

This depends on what you want to do tbh and would take more knowledge than I have about your project. What I can say is that if you want to do everything via ECS but copy transform data back to game objects… it will work. I just don’t know how fast that would be. In the end this is a game object based rendering system - if you can get the data to the game object it will render. The system doesn’t care how it gets to the game object.