Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Bug (IN-33187) [1.0.0-pre.44] 0.06 KB gc spike every frame

Discussion in 'Graphics for ECS' started by optimise, Feb 23, 2023.

  1. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,797
    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
     
  2. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    3,722
    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.
     
  3. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,797
    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.
     
  4. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    3,722
    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.