Official BatchRendererGroup sample: High frame rate even on a budget GLES device

Hi

You wrote about Vulkan Metal Dx and Gles 3.0 but what about Gles 3.1-3.2 do it support SSBO instead of UBO?

 

Amazing article and tool!

Do you have any idea of how it compares in terms of performance to the latest built-in SRP batcher?
https://docs.unity3d.com/Manual/SRPBatcher.html

Any restrictions on using BatchRendererGroup in BiRP?

 

Hi. Any plan to port the project to entities graphics to battle test entities graphic performance? It seems like entities graphic can't achieve the same high performance compares to fully manual written brg that u show.

 

nice to see ready to use examples!

any way to optimize this part? (just increased background object count to test)


*ah ok, can get rid of that, if i dont need to move the objects.
with 16 million static quads, its then here

 

Does BRG support lighting per-instance? I know in the past it did not.

Great article, by the way! Love deep dives like this.

 

Fantastic! I know BRG is meant to be super low level so it's not meant to have all features, but glad to hear dynamic lighting is included. Very excited to try this out!

 

I understand entities.graphics is much more versatile and generic solution but still it shouldn't takes so much time like over 2ms at mobile platform which is not acceptable. Currently why entities.graphics takes so much CPU time is caused by it's not using burst ISystem. I understand there's couple of graphics api does not burst compatible yet but I think official can split them out as ISystem to burst all the burst compatible items and managed items can't burst goes to SystemBase. I believe by doing so can further reduce the time cost significantly today. But still official should try to make those graphics api burst compatible until entities.graphics able to fully adopt burst ISystem. Currently entities.graphics seems like it's zero burst ISystem adoption.

Another huge performance issue is main thread stalling caused by low level graphics api i.e. Vulkan, OpenGLES3 implementation is still on main thread and cause entities.graphics systems stuck on main thread and slow down other module like dots physics significantly. Official will need to improve all the low level graphics api supported by entities.graphics off the main thread. I hope these 2 huge tasks official can start work on them asap and hopefully can ship them soon.

 

Thank you for the article! You've compared BRG to Graphics.DrawMeshInstanced, but what about Graphics.DrawMeshInstancedIndirect?

Currently I'm using Graphics.DrawMeshInstancedIndirect like this:

Code (CSharp):

1. // Per Instance properties.
2. public struct InstancedMeshProperties
3.     {
4.         public float4x4 ObjectToWorld;
5.         public float4x4 WorldToObject;
6.         public Vector4 Color;
7.  
8.         public InstancedMeshProperties(float4x4 trs, Color32 color)
9.         {
10.             ObjectToWorld = trs;
11.             WorldToObject = math.inverse(trs);
12.             Color = new Vector4(color.r, color.g, color.b, color.a) / 255f;
13.         }
14.  
15.         public static int Size()
16.         {
17.             return sizeof(float) * 4 * 4 + sizeof(float) * 4 * 4 + sizeof(float) * 4;
18.         }
19.     }
20.  
21. // Job to write data to gpu.
22.   [BurstCompile]
23.     public struct WriteToGPU : IJob
24.     {
25.         [ReadOnly] public NativeList<Instance> Instances;
26.         [ReadOnly] public NativeArray<InstancedMeshProperties> MeshProperties;
27.  
28.         [WriteOnly] public NativeArray<InstancedMeshProperties> GPUBuffer;
29.  
30.         public void Execute()
31.         {
32.             for (int i = 0; i < Instances.Lenght; i++)
33.             {
34.                    GPUBuffer[i] = MeshProperties[Instances[i].ID];
35.             }
36.         }
37.     }
38.  
39.  
40. // Create buffer for max visible instances.
41. _buffer = new GraphicsBuffer(GraphicsBuffer.Target.Structured,
42.                     GraphicsBuffer.UsageFlags.LockBufferForWrite, _maxInstancesVisibleInRuntime,
43.                     InstancedMeshProperties.Size());
44.  
45. // Write to GPU with LockBufferForWrite mechanism to prevent SetData.
46. new WriteToGPU()
47. {
48.     Instances = instances,
49.     MeshProperties = _instancedMeshProperties,
50.     GPUBuffer = _buffer.LockBufferForWrite<InstancedMeshProperties>(0, _maxInstancesVisibleInRuntime)
51. }.Schedule(culling);
52.  
53. // Unlock buffer and draw.
54. _buffer.UnlockBufferAfterWrite<InstancedMeshProperties>(instancesCount);
55. Graphics.DrawMeshInstancedIndirect(_mesh, 0, _material, Bounds, _argsBuffer, camera: cameraValue,castShadows: ShadowCastingMode.Off, lightProbeUsage: LightProbeUsage.Off);
56.  
57. //In shader update matrices and color.
58. void vertInstancingSetup()
59. {
60.     #ifndef SHADERGRAPH_PREVIEW
61.     #if UNITY_ANY_INSTANCING_ENABLED
62.     unity_ObjectToWorld = mul(unity_ObjectToWorld, _Properties[unity_InstanceID].ObjectToWorld);
63.     unity_WorldToObject = mul(unity_WorldToObject, _Properties[unity_InstanceID].WorldToObject);
64.     #endif
65.     #endif
66. }
67.  
68. void GetInstancedColor_float(out half4 result)
69. {
70.     result = half4(0,0,0,0);
71.     #ifndef SHADERGRAPH_PREVIEW
72.     #if UNITY_ANY_INSTANCING_ENABLED
73.     result = _Properties[unity_InstanceID].Color;
74.     #endif
75.     #else
76.     result = half4(1,1,1,1);
77.     #endif
78. }
79.  
80.  

For each visible instance I'm writing to GPU a lot of bytes(InstancedMeshProperties struct), but if I change the previous code to two buffers like described in the article - a persistent buffer<InstancedMeshProperties> with data for all instances and another buffer<int> with visible ids of instances that I'll update with LockBufferForWrite mechanism - will this be slower than BRG? Am I right that If I set data once for this persistent buffer<InstancedMeshProperties> it will stay in GPU memory and I'll too have GPU persistency like in BRG?

When a scene is rendered using both SRP batched rendering for some objects and BRG rendering for other objects am I right that transparent objects of BRG batches can only be rendered before or after SRP batched transparent objects - we can't sort them together in a correct back to front order?

Can we use LockBufferForWrite mechanism with BRG?

Also in your example used single GraphicsBuffer, but don't we need to use Ring Buffer(array of GraphicsBuffers were every frame we write data to the next buffer) to prevent writing from CPU to buffer that currently used by GPU for rendering? I'm doing this for Graphics.DrawMeshInstancedIndirect in the showed code I just omitted usage of buffers for clarity.

Does BRG support dynamic(additional) lights in URP's Forward or BRG supports them only in URP's Forward+?

 

Thank you for your answers!

Can you please elaborate about aligned data? It's that I need my struct to consist of float4( or float2 + float2 for example) so on different platforms everything works correctly?

 

Thank you!

 

Currently, I'm using BatchRendererGroup to render a cubes scene in HDRP by using RenderBRG.cs in Unity Graphics repo and get warning "Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak". It looks like the Native BatchRendererGroup release unmanaged memory too late. Is it right?

EDIT: It seems like a Unity 2022.3.3f1 bug, after upgrade to 2022.3.11f1, the warning disappear.

 

Hi, Can we use BRG to render directly to RenderTexture?
Currently there is No Instancing function on LowLevel rendering to RTs, Command Buffers does not work and need a Camera to work, aswell as having a quite chunky Initial overhead. Currently have to rely on Graphics.DrawMeshNow to draw fastest as possible but it has downtimes of passing data to GPU over and over again which limits its speed at higher numbers of instances.

 

Is it true that ByteAddressBuffer is used for the BRG buffer? If so - why? It's supposed to be more performant to use Constant Buffer for uniform access as far as I know.

 

That is sadly no real use here, but thanks for info about this.

 

The platform compatibility section in the official document says Unity supports BRG on Android using Vulkan and doesn't mention GLES. Does the document need to update, doesn't it ?

 

Will it support non instancing drawcall.Actually i just want a drawpersistant command.The current graphic.rendermesh or graphic.drawmesh called every frame take some time in main thread and it become a bottleneck when having a lot of drawcall.

 

Sorry i didnt make it clear. I am talking about shader which DOES NOT use gpu instance.Just like graphic.drawmesh but i dont need to call it every frame.Currently graphic.drawmesh/rendermesh need to be called every frame.And our project's target platform is opengles3.0 which means gpu instance is not well supported(and actually I dont need gpu instance in my case,but just want to get rid of meshrenderer overhead and reduce the time i have in main thread to call graphic.drawmesh/rendermesh every frame);

 

Designing a Render System Based on BRG

I'm in the process of designing a render system based on BRG and currently, I'm consider getting rid of idea of limited windows size, assuming that `window` is always size of whole RawBuffer . I'm confident that my code will never be deployed on low-end devices.

1. Are there any other considerations or potential issues I should be aware of when opting for a single large buffer?


2. Would it be possible to implement GPU based culling ? I asume that instances to draw are calculated internally based on visibleInstances array setup in `OnPerformCulling` jobHandle , but would it be possible to move this process to compute shader ? For example have acces to raw GPU pointers for visible instances and draw instances count ?

 

Just wanted to jump in here and say that this project (and associated blog post) are really great stuff. Thank you very much to @arnaud-carre and team!

Ben

 

Did you mean using the BRG api like a replacement for ctx.cmd.DrawRendererList(rendererList); in a Custom RenderPass? like the Draw renderers Custom Pass does? (using CustomPass we can actually draw a given mesh/layer to a RThandle that is not the camera, as long you have allocate it, it can be both a custom buffer or an RT.

For now, factually I doubt we can code it like that, but theorically it would be possible.

 

Almost, I am not sure about this new method havent tested it yet as I work on 2020LTS currently. I tried old cmd.DrawRenderer and cmd.DrawMesh but as it invokes Bounds update on every object in that cmd list which on mobile platforms actually accounts for 95% of the performance out the window when using CommandBuffers.

I am using Graphics.DrawMesh to render objects but now actually switched to runtime combining objects to one mesh using JobSystem to only need one call of Graphics.DrawMesh but this only works when meshes have the same material. Mesh Data as far as I know is on the CPU side and has to be pushed to GPU every time I do call Graphics.DrawMesh. Still the Graphics calls are the killer currently, doing SetPass and calling Graphics.DrawMesh from main thread is the last thing holding the system.
Also I do not use Renderers for this objects this way there is less overhead of having extra renderer components in game. Currently I simply have one data component with mesh field.

Use case for BRG with RTs
- Don't need to combine objects yourself to limit Graphics calls.
- Push mesh data to GPU only when transform updated or when object gets destroyed, streamed in/out, with current setup I would only push my own culling info so if its visible or not.

 

Hi,
I just tried the sample on a Quest 2.
- Installed XR plugin management, using Oculus for Android
- In OpenGLES3 Graphics API it works fine
- In Vulkan Graphics API the app is fully black and it throws errors in logcat (seemingly before the app properly boots as I can't attach the Unity profiler / console)

I tried toggling a whole bunch of Vulkan specific settings but none seem to change the outcome. Anyone experienced a similar issue with Vulkan / Quest 2?

- Quest 2 development build, Il2CPP
- Unity editor version 2022.3.10f1
- Universal RP 14.0.08

Edit: Also tried in Unity editor version 2022.3.14f1 => Same result

 

two questions about BRG:

will the API also sort the batches to minimise render states changes?
This is ignorance so forgive me if I am saying something stupid: is the OnPerformCulling called for each light too? How does shadow culling work?