Bug (IN-33187) [1.0.11] 0.06 KB gc spike every frame

I notice InstantiateDeformationSystem and SkinningDeformationSystem generates 288 byte gc spike every frame for each system and total around 0.06 KB gc spike every frame. I think both system should upgrade to ISystem that make it fully burst compatible to fully eliminate gc allocation and make it truly high performance

 

This has less to do with ISystem and more to do with how they are acquiring mesh data for skinning.

I solved this issue by baking skinning mesh data into blob assets. Scales much better too because I don't have to iterate through each unique mesh on the main thread, so I can render thousands of unique skinned meshes with ease.

I would love Burst-compatible GraphicsBuffer and ComputeShader API. I'd also really like a "culling complete" callback in BatchRendererGroup to force job completion and do the final compute shader dispatches so that culling jobs can run while SRP does its thing.

 

The main reason I asking for ISystem is I can guarantee it won't have system that has gc spike anymore and also SystemBase is really too slow. Currently seems like all systems are SystemBase. Maybe currently not all systems can become ISystem yet but I guess most of the system can upgrade to ISystem? But still I would like to see all systems upgrade to ISystem in future release by making all the required graphics APIs to be burst compatible.

 

That doesn't guarantee that. All it guarantees are that you can't have managed member variables on the system. If you Burst-compile the code, then you have that guarantee, but that won't work in this case because ComputeShader is not Burst-compatible.

 

Hi. Will gc issue will be addressed at next release or it requires editor fix?

 

Hi @JussiKnuuttila. I would like to know about this that I want to get gc free at performance critical Android platform.

 

I see then I guess the fix and improvement won't available at 2022.3.x and will only available at 2023.2.x in future?