One of the goals of the new Hybrid Renderer is to provide good performance also in situations where the current Hybrid Renderer has trouble due to technical limitations. Examples include transparencies (which require depth sorting), and scenes with a lot of Mesh/Material variety.
Is that only phone that supports GLES3.1 will work properly? How about GLES3.0 only phone?
We are trying to make it possible for the BatchRendererGroup API itself to support GLES3.0, but since it doesnāt have support for compute shaders or SSBOs, users will be more limited in the ways they can upload instance data on GLES3.0 only devices.
Hybrid Renderer uses compute shaders, and will require GLES3.1.
1 Like
I see but for Hybrid Renderer how u handle GLES3.1 mobile phones that cannot support compute shader?
Isnāt compute shader support required for OpenGL ES 3.1?
Yes. 3.1 requires compute and that is the target for the Hybrid Renderer for now.
Supporting non compute capable devices would require a rewrite of the data model, doable but it would require quite some work and would lead to worse CPU performance for those devices.
4 Likes
Just want to say I am very happy to see Unity embracing the latest technologies (ES 3) as ES 2 is basically non-existent these days, especially for mobile gamers who care at all about gaming.
Looking forward to seeing this trend continue. Maybe in the future it will be worth it for us to switch to URP. Every mobile dev knows that every bit of performance matters on this platform.
2 Likes
@joelv So I finally got around to doing to some test on this and Iām getting very mixed results.
Iām using a exact copy of the RenderBRG script from the URP test project. Iām using Unity 2022.1.0b8.2747 and URP: 13.1.5 with forward rendering and XR single pass instanced enabled.
In my test scene I have about 7k renderers, 1 dir light with shadows and 3 points lights with shadows. Naturally the point lights donāt work with the BRG path. Iām getting my frame timings from SteamVR. With the BRG enabled I get about 5.8ms on average, however when I toggle it off and restore the normal renderers I get about 5.4ms on average.
Any insights on why this is happening and what I could be doing wrong ?
The RenderBRG script in the URP test project is a relatively simple test script, and does not have very sophisticated culling, especially for shadow maps. My first guess would be that the RenderBRG version is rendering more things in the shadow maps than the GameObject version is. You can check whether this is the case e.g. by using RenderDoc.
@YuriyPopov There is a known issue in the 22.1 RenderBRG.cs script related to the picking that causes huge performance issues. You can find a throw away branch with a fix here. It has already landed to master, but thatās for 2022.2. So alternatively you can probably just grab the latest RenderBRG.cs script on Graphics master.
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.
3 Likes
@VincentBreysse I will profile the shadow caster rendering on Monday. Since my case is on URP perhaps the issue you mentioned is not affecting me. I dont see any shadow culling being done in the BRG renderer over at the gpudriven branch. How would I go about culling the shadow caster besides checking distance in the culling job and changing the shadowcasting based on that ?
So if itās 2022.1 integration with hybrid renderer will land in same time as DOTS 1.0?
So I did more test with RenderDoc, no shadow casting lights, no shadow rendering option on all renderers. On URP Single Pass Instanced the BRG is about 0.5ms slower on both the CPU and GPU. So I decided to do a non-XR test just as a sanity check. Exact same scene BRG get a average of 630 fps (1.7ms frame time) and disabling it leads to a average of 250fps ( 4 ms frame time). So I would say that perhaps there are some problems with XR rendering and BRG.
1 Like
@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.
Indeed Iām using the script from the master branch that contains the picking fix. I suppose this is why the non XR has a significant improvement when using the BRG. I also saved two renderdocs for XR version. Would you like me to upload them somewhere ?
@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.
1404871
I isolated it into a simpler project. Did a quick test, results are the same. Hope it helps 
3 Likes
Hello everyone. Has anyone checked whether this will work with 2D URP? I just have a problem with that Graphics.DrawMeshInstanced does not want to draw anything other than the standard URP Unlit (not Sprite Unlit), and this does not suit me at all, because I still want to Sprite Lit.
2 Likes
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.