Search Unity

In 2018, we’ve introduced a highly customizable rendering technology we call Scriptable Render Pipeline (SRP). A part of this is a new low-level engine rendering loop called SRP Batcher that can speed up your CPU during rendering by 1.2x to 4x, depending on the Scene. Let’s see how to use this feature at its best!

This video shows the worst case scenario for Unity: each object is dynamic and uses a different material (color, texture). This scene shows many similar meshes but it would run the same with one different mesh per object (so GPU instancing can’t be used). The speedup is about 4x on PlayStation 4 ( this video is PC, Dx11 )

NOTE: when we talk about x4 speedup, we’re talking about the CPU rendering code ( the “RenderLoop.Draw” and “ShadowLoop.Draw” profiler markers). We obviously don’t talk about global framerate (FPS))

Unity and Materials

The Unity editor has a really flexible rendering engine. You can modify any Material property at any time during a frame. Plus, Unity historically was made for non-constant buffers, supporting Graphics APIs such as DirectX9. However, such nice features have some drawbacks. For example, there is a lot of work to do when a DrawCall is using a new Material. So basically, the more Materials you have in a Scene, the more CPU will be required to setup GPU data.

Standard Unity rendering workflow

During the inner render loop, when a new Material is detected, the CPU collects all properties and sets up different constant buffers in the GPU memory. The number of GPU buffers depends on how the Shader declares its CBUFFERs.

How SRP Batcher works

When we made the SRP technology, we had to rewrite some low-level engine parts. We saw a great opportunity to natively integrate some new paradigms, such as GPU data persistence. We aimed to speed up the general case where a Scene uses a lot of different Materials, but very few Shader variants.

Now, low-level render loops can make material data persistent in the GPU memory. If the Material content does not change, there is no need to set up and upload the buffer to the GPU. Plus, we use a dedicated code path to quickly update Built-in engine properties in a large GPU buffer. Now the new flow chart looks like:

 

24 评论

订阅评论

留下评论

您可以使用这些HTML标签和属性: <a href=""> <b> <code> <pre>

  1. Another weekend exploring new optimization solutions. Keep em coming Unity!

  2. The option doesn’t show on 2018.3.7 for me, what am I missing? I have installed the LWRP package (obviously)

  3. yeah, ok…. but please, remember to make public a tool when the tool is finished (not a preview), integrated, good documented (with examples of practique use and not just a “maybe you can use this in this way, understand it by yourself”), designed for a massive use and not only for some programmers, thanks.

    1. I disagree. The preview programme is very important. It allows us to give feedback about upcoming features while they’re still in development and vastly shortens the dev cycle. Why get the opinions of only a handful of developers in a room when you can get it from 10’s of thousands all over the world?

      1. Well, is my opinion, I want to made videogames, not to be a Unity tester.

        They changed and replaced a lot of stuff on Unity 2018.3 and 2019 with tools that are on development (like the nested prefabs that broken with all the previous prefab workflow, I hate that and we don´t have alternatives) and they are showing some of that un-finished tools (like the SRP) as the principal characteristics of the newer versions, that tools are undocumented, aren’t full tested and have a lot of instability. Great if that tools are on preview, but please don’t sell it like a finished tools. Take your time, finished the tool´s development and launch a real Unity update, not this.

  4. I see only half of article.

  5. In the per object variables section, you write: Please refer to the “Could be real4” column.
    However, this column does not exist in the table.

  6. John KP @ Mindshow

    三月 1, 2019 7:08 下午 回复

    The SRP Batch code path isn’t running for me when VR is enabled in my project. This was replicated in a clean project with just art and unmodifed code as well:

    2019.1 b4
    Unmodified version of LWRP
    VR Enabled (Single Pass Instanced)
    SRP Batching Enabled in Lightweight Render Pipeline Asset.
    Graphics Jobs Enabled
    Windows Standalone
    DX11
    All materials in scene are using the Lit shader provided by LWRP.

    Result:
    SRP Batching Profiler (and frame debugger) reveal that the SRP Batches aren’t happening.

    If VR is disabled (or if frame debugger is sampled while play mode is inactive in editor)
    SRP Batching works as expected.

    Is there something I’m overlooking?

  7. Great article!
    By the way, if I see this blog from japan,
    the url is redirected to “blogs.unity3d.com/jp/2019/02/28/srp-batcher-speed-up-your-rendering/” and the content looks broken.

  8. The SRP Batcher seems to break my Statistics and Frame Debugger windows. Stats shows 6 batches and 1k tris for a scene with 1k batches and 800k tris with it disabled. The frame debugger has no Depth Prepass or GBuffer at all with the batcher enabled.
    This is on Unity 2018.3.6f1 with HDRP 4.10.0.

  9. Very cool!
    Is Unity working on a similar render approach as Frostbite/Unreal? I got this from a post:
    “The new mesh processor works by uploading the entire scene data to gpu memory. Instead of setting uniform parameters per-drawcall, it just uploads everything to GPU buffers and then refers back to those though indices. This allows unreal to do a lot more multithreading in the renderer, even in DX11 or phones, and it also makes unreal able to automatically instance everything possible.”

    No idea how this is called. Maybe not the best place to ask but anyway, is Unity doing something similar or researching?

    1. Er, that is what is happening here. GPU data persistence.

      1. No, it’s not quite right (partially). Epic changed a big chunk of renderer using Data-Oriented design along with an automatic instancing.

        1. They are working on a ECS based renderer. So I think, they would be refactoring their mesh drawing pipeline.
          Also where did you get this “EPIC changed a big chunk of renderer using Data-Oriented design”. I know they refactored and removed the legacy mesh drawing system, but I dont think its DOD-based.

    2. You are well come. I’m a user, ex UDK. I think what you are looking for is this:

      [Unity ECS: https://unity.com/dots#burst-compiler%5D

      Unity is working on this since 2017 2018 (I think) and so there are tutorials on YouTube.

      Explanation: [https://www.youtube.com/watch?v=d9Z4EUZ5apo]

      Here there is a Unity example that they are working on:

      [https://unity.com/megacity]

      And a Unity tutorial:

      [https://unity3d.com/learn/tutorials/topics/scripting/introduction-ecs?_ga=2.87982238.788035148.1551051194-2090915164.1475000191]

      So is not a job system for the mesh. Is also for the engine itself. To do this Unity is migrating to a special C# now called HPC# to get the performance of C++ in multithreading and using this memory layout that gives to the GPU all mesh, textures, animation inline order. The slogan for Unity engine improvement is: performance by default.

      [https://unity.com/dots]

      That will be introduce in this 2019 probably at GDC now in march.

    3. Here in Unity, there are 4 or 5 rendering engines: a traditional Unity5, a Desktop HDRP unity high definition render pipeline, the lightweight render pipeline LWRP for movies, other for VR with low performance and a custom rendering pipeline SRP. This article refers to this last one. I think is for advanced users or industries that want to migrate to Unity (and I presume If you are an expert you can put Unreal rendering in it if you wish).

  10. Awesome post. Thanks !

    Does that mean that we have to stop using MaterialPropertyBlocks and actually set the changing property directly on the material ?
    Or you working on a new MPB ?

    Thanks !

  11. Awesome work as usual! Excited about all these great improvements being made these past few years, the future looks bright for Unity.

    > If you could play the video at 60hz you would feel the speed up when enabling SRP Batcher.

    This is a 60fps video though, so 99.9% of people should be able to see it at 60hz!

  12. Great work, is this available on the Vulkan/DX12 APIs as I think these API’s are also more threadable and could potentially have greater gains in performance?

  13. The images labelled “SRP Batcher rendering workflow” and “standard pipeline rendering workflow” are identical, which seems to be a mistake. Otherwise whats the point of differentiating when they are the same?

    1. Isaac, these definitely a mistake. I’m sure Arnaud will fix it soon

    2. Thanks for noticing, and sorry for the confusion, we’ve just fixed it!

      1. First video in the post dont work in Firefox. :)

        Batcher works for OpenGL ES 3.1+
        Is there plans to make Batcher work on OpenGL ES 3.0? if no what is best workflow to create game for gles 3.0 and gles 3.1 for best performance?