Official New BatchRendererGroup API for 2022.1

Another important general note: There are many known issues that can cause the BRG peformances to be much worse than GameObjects ones currently.

For example, we recently discovered that shadow caster culling for point lights is simply not working at all when rendering with a BRG, at least for HDRP. The culling planes we receive in the culling callbacks are setup in a way that causes the shadow caster culling to always pass. So you effectively end up rendering all the BRG objects in the scene to the shadow maps. From our recent discoveries, it might also affect directional shadows. There are probably other issues like this we aren't even aware of at the moment. Especially around the culling code.

We are currently working on fixing all those things. But until it's done, beware of the perf measurements you get when using a BRG. There are many rough edges that could cause performances to drop because of various stupid things.

 

@YuriyPopov I think we might expect XR to be a bit slower, but not by such a big margin. We would probably need to investigate this.
Also did you test with the picking fix I mentioned before ? This one is by far the most important. It causes each object to be rendered with a single draw command, so you effectively get no instancing at all.

 

@YuriyPopov Thanks for taking the time to test all that stuff! So yeah that sounds like we might have a performance problem with XR on our side. The best you could do is sending us a bug report and link your captures there. It would make it easier for us to track the issue.

 

Currently you can't use any 2D URP shader pass with a BRG. Those shader passes don't handle the DOTS_INSTANCING_ON keyword which is necessary for a BRG to render anything.

AFAIK it should be doable to get the 2D URP shader passes to work with a BRG if you are willing to put some extra efforts into modifying the shaders yourself. I'm not aware of anything in the BRG API itself that would prevent you from doing 2D rendering.

We haven't investigated this ourselves though, so as always there might be some unknown blockers. Also 2D rendering is not our focus for the moment so you might not receive a lot of support from our side regarding this.

 

It's more of a Hybrid Renderer and Unity thing. As it is now the Hybrid Renderer is designed to have a big buffer where only changed per instance data is changed every frame. This data is scatter written using a set of compute shader dispatches from some upload buffers.

With GLES 3.1 we need to limit batch sizes since we need to read the data from a UBO instead of an SSBO. The UBO has a limitation so a single draw command can only access a limited amount of data. We can still use the compute shader upload path here though, and can use a big buffer we bind at an offset to the draw calls.

For GLES 3.0 support though data cannot be written using a compute shader (obviously) so it would need to use a glBufferSubData path. It means we would need to maintain two different upload systems in the hybrid renderer. We would also needs to spend time optimizing the GraphicsBuffer.SetData path probably as that is not super efficient as it is now. Possible, but it does complicate things and we need to weigh the priorities.

If you use the BRG raw it will probably be fully possible to write something like this though.

 

This is the API that Sebastian used for that project, but it does require you to write code currently (or base it on the RenderBRG code in our tests which is the actual code Sebastian wrote when he was tweeting that). And yes it is like DrawMeshInstanced, a lot more complicated but also a lot more powerful. We will be building new technology on top of this and hopefully make it more accessible in the future.

 

Our teams focus is the hybrid renderer so I can only speak about that. But we have written this to be a stand alone and supported interface and hope it will become usable both externally and internally.
Regarding the hybrid renderer I know it is a big dependency to pull in but even here it is possible we can be usable even for non DOTS/Entities projects. You can create you static visual world, put it in a sub scene and it will render using the hybrid renderer (and therefore the BRG) without you having to write a single line of code. That's our goal at least. If it is feasible is probably up to each project in the end.

 

Multi draw is sadly not easily implementable cross platform as it is now. Worst case it will fall back to a CPU draw dispatch loop and no way to specify the multi draw count late from a compute shader. But we are working on something like this. Exactly what shape it will take and when it will ship is still not decided.

 

An update regarding GLES 3 support.

Work has now landed and the interfaces will be available in the next alpha (2022.2.0a13). If you don't plan to use GLES 3 with the BRG in your projects you should not need to do anything.

If you plan to support GLES 3 you will need to create the batch buffer differently for that platform, as the GLES backend will bind this as an UBO instead of an SSBO. Use BatchRendererGroup.BatchBufferTarget to check for this. You will also need to use the new overload for AddBatch which takes an offset and a size, where the offset has to be a multiple of
SystemInfo.constantBufferOffsetAlignment and the size has to be less or equal to SystemInfo.maxConstantBufferSize.

This means that the batches can't be arbitrary in size. You will have to write some kind of batch splitting logic as well to keep the size down. Examples of this will land to the public Graphics repo once the mirroring does its magic.

Usage of this interface will be landing to the Hybrid Renderer shortly and will be available for the Entities 1.0 release. Here the requirement will be GLES 3.1, as we are still using some compute shaders.

 

We are testing and we are seeing a bit better performance on GLES as it uses an UBO path instead of SSBO. That said the way the hybrid renderer is written it relies on compute shaders (a few dispatches at the beginning of the frame), the persistent GPU storage of instance data and instancing. This will continue to be slow paths on some hardware and it will be next to impossible to get away from that without a full rewrite. There will probably cases on some devices where game objects will render faster than entities in an identical scene due to this.

We are also tracking down a few bugs regarding worse performance than expected so hopefully there will be additional improvements in the future.

 

Sorry, I don't have any numbers for those specific devices. Functionality has been tested from what I can hear and we are ramping up performance testing and fixes. They are in the device support matrix for 1.0 so work will be done on ensuring things works on them. We have quite a lot of platforms to cover for a small team though.

 

Yes the GPU side is a bit so so on certain devices still. On the CPU side we should be seeing quite good numbers, but the difference to GO path is not as big as it is on other platforms.

 

HR will stay as it is for the 0.5x streams (and anything lower than 1.0 the way things looks now). A new version with a bit better feature support will be released for the 1.0 stream and will require unity 2022.x.

 

Thanks for pointing it out. Some thing broke during the move of graphics code. I am waiting for some processes to finish and will update the links as soon as possible (though you should be able to find everything but the RenderBRG.cs script by some repository browsing)

 

A rewrite is currently not planned no. Basing the data model on what works best for the phones will probably make things worse over all for the rest of the platforms. Though we will try to do mobile specific optimizations and mobile specific data paths where it makes sense.

 

The underlying interface is completely rewritten (the parts that are in Unity, not in the package). Most of the hybrid renderer is still there and uses the same data model as before. What we have improved on is the ability to make many more things be able to batch together. Note that the hybrid renderer version using this interface has not yet been released.

Rewriting the data model is a much bigger task

 

No what I mean with data model in this case is how we go from data in the components to data usable in the shaders. Matrices here is a good example. Each renderable entity has a matrix attached to it and that is needed to get read by the vertex shader to place the mesh in the correct position.

Traditional unity game object code paths will copy this matrix for every instance every frame to the GPU just before the drawcall. Add to this lot of other per draw or global data and the cost quickly adds up.

The Hybrid Renderer model is that all data is persistent on the GPU. We only upload the matrix whenever is has actually changed, and we do this my packing things into a big GPU buffer. This gives us a lot of CPU time back, and for most GPUs there is no access penalty when doing things this way (and since we can instance draw automatically with this setup we can actually get better performance in many cases). Some GPU does have a harder time reading from an arbitrary buffer location though and are seeing a bit of a penalty.

 

We have a way forward here and want to explore GPU driven rendering as well. The BRG will at some point (hopefully soon) get procedural and indirect draw support. We did not have time to take it all the way in this rewrite since we where focusing on the current features hybrid renderer needs. With the coming extensions we can explore GPU driven there and you can as well in custom renderers, much easily and more efficient than what you can with the current Unity interfaces (I hope).

Regarding HLOD that is probably a question someone else has to answer

 

Links have now been fixed and point to the last place before some restructure happened. I will try to update links again once GLES3 work is fully mirrored as well, but using that code will require 2022.2 alpha anyway

 

The interface improvements are for BRG. We can potentially then use it for hybrid renderer if we find a way to do that. However I think it will be more useful for custom rendering.

Hybrid Renderer stores two 3x4 float per instance (or four if you need motion vectors IIRC). And in the static case we do no work except loading it into the shader. Sure there are probably a bit more compact ways of storing things but this is what we need to support the general case. And you would have to run on a _very_ bandwidth constrained platform to get any saving to go for something more compact (which also would discard a lot of flexibility).

A bit OT: To get maximum performance out of Hybrid Renderer you would want to have your static entities separated from your dynamic entities in the chunks (you can do this by some manual static/dynamic tag component). This way you will minimize transfers to the GPU when dynamic entities move.

 

In general DrawInstancedIndirect is not really related to performance directly (with possible exceptions on some very specific platforms), it's more about enabling the use of the GPU for things like culling, which can then bring performance improvements.

Tagging entities as static is not related to DrawInstancedIndirect either. Instead, what the tagging does is it ensures that static entities will not be placed in the same chunks as non-static entities, and this makes it possible for the Hybrid Renderer to skip those chunks very efficiently when their transforms don't change. The Hybrid Renderer keeps the transforms on the GPU, and it will only need to update them when a change is detected.

 

A bit tricky yes. Hybrid renderer will soon be using the API described in this forum post, and that will only be available in Unity 2022.1 and up. It will require specific shaders since we have a data model that allows you to do per instance overrides in a very flexible and performant way. Not all of the builtin unity shaders have been converted to support this setup yet though but we are slowly getting there. Your best bet is to use a shader graph based on your SRP of choice to get compatibility.

Sprite renderer uses interfaces not available in C# as it ties heavily into the lower level parts of the engine to be efficient. But I suspect it could be written using the batch renderer group instead now that it is available. It is quite an involved task though.

If you do want to render bullet hell sprites I would suggest you look at the BRG Raw example scene which shows you how to procedural draw a lot of instanced things. I hope this helps at least a little bit.