Bug Performance BUG ? HybridRendererV2 even slower than GameObject-Renderer ?

Hello!

This is definitely an unexpected result. In our internal tests we have typically seen HRV2 to outperform both GameObjects and HRV1, both in Megacity and in other benchmark tests. It's possible that this is a bug or that something has been configured weirdly.

The HRV2 capture has two specific things of note:

• There are large WaitForPresent / Present spikes in the frame, which suggests that the scene might be bottlenecked by GPU rendering instead of CPU. If possible, it would be good to take a GPU performance capture from both versions and look at the GPU side difference.
• UpdateHybridChunksJob takes a lot of time. If you are not modifying any entities each frame, then this could indicate a very high chunk count.

Looking at the HRV1/HRV2 comparison, we can see that in the HRV2 version the chunk utilization is extremely bad, and the vast majority of entities seem to be in single entity chunks. We also see the HybridBatchPartition component, which is used to force this situation in order to sort transparencies correctly. I would suggest checking two things:

• Make sure that your Materials are not marked as transparent unnecessarily. Transparent materials cause Hybrid Renderer to add HybridBatchPartition in order to sort transparencies correctly, but it costs a lot of performance. Regular opaque materials should not have it. It is also possible to disable this behavior with the DISABLE_HYBRID_TRANSPARENCY_BATCH_PARTITIONING scripting define, in which case you might see transparency ordering issues (in HRV1 you will always get this behavior, it cannot render sorted transparencies correctly).
• Try profiling with incremental conversion disabled. This has been known in some cases to increase chunk fragmentation.

I attached an edited version of the HRV1/HRV2 comparison picture to highlight where the problem is visible.

 

It is expected that HRV2 will always have some small baseline CPU cost, because it checks every chunk for changed data. HRV1 permanently classifies batches as static or dynamic, and has a very low CPU cost for static batches and a very high CPU cost for dynamic ones. In addition, adding new static batches also carries a high cost in HRV1. HRV2 does all of this automatically.

When comparing against HRV1, it's a good idea to profile total frame times instead of just system update times, as HRV1 also has a significantly higher draw call setup cost compared to HRV2, because it reuploads instance data from CPU to GPU each frame, even for static batches. In 100% static scenes, we would expect HRV1 to be slightly faster on the DOTS system side (like in your capture), but slower on the main thread rendering and render thread side.

We could consider adding some kind of feature (for example, a tag component) to mark entities as completely static and have Hybrid Renderer skip checking them for changed data to reduce this overhead. We will also continue to try to optimize the system update cost in general. If you want to test this kind of change yourself, you can try altering the query used by the Hybrid Renderer for UpdateHybridChunksJob to exclude entities with a certain tag component, and then add that tag component to your static entities.

 

It is definitely unexpected, so I guess we could say it's a performance bug. In the capture, HRV2 rendering is faster with the actual rendering (DoRenderLoop), but has the added DOTS system overhead which is more than the difference. If the DOTS system overhead is optimized more, it would be faster again.

Possibly this overhead could be reduced by adding a way to opt out some entities from data update checking, e.g. via a tag component.

 

I don't think this specific case (GameObject vs HRV2) requires a formal bug report. We will keep optimizing the Hybrid Renderer to try to make it faster. Thanks a lot for bringing this to our attention though!