Unified renderer goal

[tulip lichen]

Currently from what I know is unified renderer will merge urp and hdrp together into one single renderer but there's no update for entities graphics. Does official have plan to merge entities graphics into unified renderer too that no longer required to specifically write yet another new implementation for game object land to speed up rendering performance of game object. And also if I understand correctly currently entities graphics does not support GPU occlusion and STP that available at game object land that make this situation worst that entities graphics can't get the same level of support of new graphics features.

[foggy parrot]

I don’t see why STP, being just an upscaler, wouldn’t be compatible with projects using entities graphics, I think it have nothing to deal with that and so, I think you will be able to enable STP anyway if you want to gain performance. Regarding Entities graphics, it is actually usable for both pipelines and improve batching by relying on Batch Render Group (BRG) for drawing entities per batch if the shader support it, so I am not worry, as a user, about having this BRG feature ON by default, using the futur UnifiedRP. And about GPU occlusion, I don’t really know for sure, but I think GPU occlusion and entities graphics altogether make no sense, as entities graphics is using it’s own occlusion policies regarding drawing meshes (entities) which is super efficient, so I think that GPU Occlusion is really only for game objects land as you said, where optimization is not at the best by default regarding drawing meshes and batchcount, I think meshes can benefits from GPU occlusion only if these meshes don’t already benefits from the new BRG implementation (well, on my side, I already see benefits of BRG tech using gameobjects, on batch count, using U6, without doing anything special except that the shaders are BRG friendly, and enabling GPU occlusion don’t really change anything in this project)

[coral bane]

We are working on consolidating entities graphics and the GPU resident drawer, both using BRG. That work is progressing well and would remove entities graphics all together. Both game object and entities rendering will go through the same code path.

[rough vine]

What will be baseline here? Current resident drawer implementation or entities graphics?

[coral bane]

resident drawer

[tulip lichen]

After this consolidation will it improve more performance at low end Android mobile phone since the current entities graphics implementation is slower at OpenGLES graphics API?

[rough vine]

Ok, but taking into account that every GO will be backed by entity in the future, it seems for BRG input data layout - entities will be used?

[lavish plume]

Would that also mean that things like sprite renderers will be natively supported?

[vagrant oyster]

Yes, I'm working on unifying both GRD & EG currently. The baseline is indeed GRD and it will basically be able to render Entities. Features and platforms supported by EG like material property override & GLES 3.1+ support will also be added to GRD

[vagrant oyster]

It will likely be the same at first. But hopefully we can invest more resources in making GRD rendering faster afterwards for low-end devices

[vagrant oyster]

Not initially, but hopefully at some point it will. Long term vision is to get everything in Unity to be rendered via GRD. That's mostly intent for now though. Nothing official yet

[rough vine]

@vagrant oyster anything about that? #1298320638028550227 message curious about what inputs it will get, purely entites based according to every GO backed by entity, or idea is have multiple data source types (from pure entities and from go components directly) with transformation provider? Not asking specific details, just general direction Unity decided to follow

[vagrant oyster]

Yeah there will be multiple source data (like GOs and Entities) and an internal rendering data representation. We call it the RenderWorld currently, and conversion systems take care of turning the source data into instances in the RenderWorld

[rough vine]

Isn’t that adds a bit of overhead (and in case of entities at scale it’s even more overhead)? To have intermediate transformation step

[vagrant oyster]

We can't fully piggy back on Entities because not all components will be backed by an ECS representation at least initially. That's the case for MeshRenderer for example

[vagrant oyster]

Yes, there is data duplication and memory overhead involved. But this brings us one step closer to move rendering off the main thread entirely

The goal is to have a rendering representation of the world that is never updated directly by the users

This way we can have CPU rendering jobs like culling, draw submission, render graph and etc of the frame N running while you're doing simulation for the frame N+1

That's long term vision though, and still just intent. So nothing official either

[rough vine]

Sure, asked just direction, thanks for responses! Just a bit worry for performance in pure entities, in comparison to current one, like pure dots users technically will have performance degradation out of box with more intermediate steps and memory according to off thread rendering, yeah it sounds cool, but you anyway need to have force frame synching to prevent waterfall, and you can’t postpone rendering results for a lot of frames, yes n+1 can be acceptable but doubt more will be acceptable )

[vagrant oyster]

Yes N+1 is the target, not sure we will do more than that at least initially. Otherwise you get input lag and so on. But that's already enough to largely compensate for the copy step. Also yes it is not favorizing pure DOTS users. It is favorizing DOTS & GOs users, which should be much more common. Having GRD rendering both GOs & Entities means having only one BatchRendererGroup instead of two. From my perf testing, this alone is enough to compensate for the perf loss induced by the copy step on Megacity Metro. You get better batching and less redundant work this way

Also keep in mind those copy steps are only happening for what changes and are incremental

• You get all the power of GRD for entities. Like GPU occlusion culling and so on. So in practice you shouldn't get any regression hopefully

[rough vine]

Yeah sure it’s incremental and sparse upload idea based

Anyway we always can write our own pure entities BRG renderer with less memory consumption and without additional steps

[vagrant oyster]

Well you can, but hopefully you don't have to. If that ends up being a better trade for most users, then there is a problem with our design. But I don't think it will be the case. Having rendering jobs + simulation running in parallel is really big and should be worth the cost of an additional copy in most cases

[rough vine]

Also yes it it not favorizing pure DOTS users. It is favorizing DOTS & GOs users, which should be much more common.

Sad, after so many years - we, old DOTS users, been loyal and now got knife in a back (just a joke)

[vagrant oyster]

At least you should get actually good integration with the engine 😄

[rough vine]

Been good enough since 2018 just made us better devs in world of limitations but I started to flow this thread from the topic! Thanks for responses again appreciate transparency in what direction Unity follow (for now), and sure, we take all that as just general direction which possibly could change in general or in some specific parts.

[vagrant oyster]

No problem ! Been quite impressed with what users managed to pull off with DOTS honestly. It's really not ideal workflow 😅

Also one note on the data duplication thing. We don't need to do it for everything. For example the transform matrices (heaviest per-instance component) are directly uploaded to the GPU and never stored in the RenderWorld

• We bitpack things heavily since the RenderWorld does not need to be user friendly. Just very efficient

So there is memory overhead, but it's not full data duplication either

[rough vine]

Yeah, I expect it more like for material properties diff world

[vagrant oyster]

We probably won't duplicate those either. Just queue some upload buffers and flush right before rendering. Same as matrices

[rough vine]

As it is right now with sparse uploader, then point of render world is more for mesh/materials uploads, render graph attachments binding, draw commands upload?

[vagrant oyster]

Goal is to move basically everything in that capture here off the main thread

Again, long term goal. There is work to do here 😄

[rough vine]

Just a bit

[tulip lichen]

Does it also means case IN-65173 about main thread stalling at entities graphics will be addressed too?

[rough vine]

Well, there wouldn't be entities graphics anymore, as result no need to fix it in entities graphics 😄

[tulip lichen]

From what I see it's possible to migrate most of rendering data to become ECS data until eliminate the need of creating new internal data representation and then like Mesh renderer for example become Monobehavior thin wrapper that when change its settings basically is just change ECS data. I believe moving to ecs data is also essential to make rendering off main thread. Any reason this can't be archived?
I believe the reworked Transform component at Game Object for Unity next gen also applies similar idea that changing Transform at Game Object basically is just changing LocalTransform component at ECS or in other word point to same piece of ECS component data.

[vagrant oyster]

Not sure what this is about exactly, but yeah entities graphics won't exist anymore. So this ticket will be N/A