Unity 开发中 SRP Batches API调用的实际情况
目的: 使用RenderDoc查看SRP Batches和在Unity FrameDebugger中没有的信息以便正确认识SRP Batches。修改了Universal Render Pipeline/Lit为LitMoreProperty,加入了一个变量(包含在CBUFFER中的_MoreProperty)为了测试在2个Material设置不同值。
[*]使用这个Shader创建了2个Material,然后设置其中一个Albedo纹理(如图所示),另一个不做设置。
2._MoreProperty设置成不同值
3.使用了很多不同的模型。
测试用例
Material1,设置Albedo,调整MoreProperty
Material2,不设置
那么Unity Frame Debugger会是什么情况呢?
注意只有一个SRP Batch
Unity FrameDebugger的信息相对较少, 接下来看看RenderDoc有什么样的信息可以获取
第一次DrawCall
其实它一个DrawCall都没少,但是从FragmentShader那里可以看到它使用到了2个缓冲区数据UnityPerDraw和UnityPerMaterial
第二个DrawCall
第二个DrawCall看到有切换模型和调整缓冲区(UnityPerDraw)范围
第3个DrawCall
调用的API出奇的少只有调整缓冲区和绘制
第4个DrawCall
和第二个DrawCall很相近，设置模型和调整缓冲区范围，另外设置了一次纹理, 还有一次Buffer871(就是因为_MoreProperty值的不同所以设置了一次新的数据缓冲区)。
从RenderDoc的信心可以看到,SRP Batches确实没有减少DrawCall, 但是在后续DrawCall中也省下了很多命令调用, 并且在不同的Material之间也可以省下很多命令的调用。
<hr/>接下来当我调整勾选项Specular Highlights使2个Material不同时，SRP Batches变成了2个
2次SRP Batch, 注意Keywords位置
那么可以确定SRP Batch在Keywords不同的情况下是不能合批的。
不能合批的情况下通过RenderDoc可以看到什么呢?
第一次SRP Batches情况下的第一个DrawCall
第一次SRP Batches情况下的某个DrawCall
第二次SRP Batch的第一个DrawCall
第二次SRP Batch的第一个DrawCall那么就是一个完全新的DrawCall了和第一次SRP Batch一样。
第二次SRP Batch的某个DrawCall
结论:
[*]同一个Shader基础下的不同Material修改纹理,模型,参数也还是可以合批的，但是这些设置不同会在接下来的DrawCall中调整设置。
[*]Keywords不同就不能SRP Batch。
3. 想让SRP Batch发挥更好的效果, 那么需要尽可能让那些 相同的纹理,模型,参数的物件依次渲染, 以此避开API的调用。
4. SRP Batch很强大，但不能单独依靠它，也需要其他优化。
知包：Unity 开发中 Dynamic Batches 在Opengl和Vulkan中API调用的实际情况
知包：Unity 开发中 GPUInstancing在Opengl和Vulkan中API调用的实际情况
页:
[1]