部落格版本：http://dorgon.horizon-studio.net/zh/archives/1768 发现大家蛮喜欢看这种演讲笔记的，因此花了一些时间把EpicGameChina关於Mobile Deferred Render的演讲看完并做了一些笔记 ，分享给大家，也推荐大家去看影片，我是觉得收获蛮多的。 影片在此：https://www.youtube.com/watch?v=GQoSjEii4nk 1. Mobile Deferred Render直到5.1才算比较成熟 2. Deferred的优势在於可以减少shader permutation，因为在base pass不用算lighting ，因此相关的permutation就可以从model material直接decouple出来，省下大量的 shader数量。 3. mobile deferred vs mobile forward在关掉static lighting的比较： a. Mobile Deferred只需要建出LMP_NO_LIGHTMAP一种caseb. Mobile Forward则 需要建出LMP_NO_LIGHTMAP跟LMP_MOBILE_DIRECTIONAL_LIGHT_CSM搭上 bEnableLocalLights开关，总共有四种case。 c. Mobile Deferred的shader总量是Mobile Forward的1/4。 d. LMP指的是LightingMapPolicy，所有的Type参数ELightMapPolicyType这个 enum 4. mobile deferred vs mobile forward在打开static lighting後大约是原本的1/5大 小 5. 减少Shader大小代表我们打包出来的pak变小，而且也能降低记忆体的使用量，另外 也可以减少因为run-time compiling shader所造成的卡顿。 a. 注：run-time compiling shader的卡顿可以使用PSO Caching的机制解决， 只不过这个方法会要求团队在打包之前先跑一次版本以记录用到的材质。 6. Deferred Render因为base pass没有复杂的光照计算，因此这阶段的开销比forward 减少很多，而且光照只在可见的pixel上做计算，不会浪费GPU在不可见的pixel上，理论 上对於减少GPU压力是有帮助的。 a. 不过现在的晶片大多内建了减少OverDraw的技术，例如PowerVR GPU的 Hidden Surface Removal，以及Arm GPU的Forward pixel kill，即便如此，在某些 device上还是能有明显的收益的。 7. Deferred Render可以把原本Foward要保留给光照用的Sampler让出来给美术使用，最 多能多出6~7个Sampler。大致上的数量如下 a. Reflection capture可以减少1到2个 b. Shadow texture减少1个 c. Planar reflection 1个 d. Light grid data减少3个。 8. 虽然Deferred Render需要创建多张G-Buffer，但我们可以利用tile-based GPU的特 性，把GBuffer分配在Tile Memory上，这样就可以不需要用到System memory，从而减少 传输成本。只不过这招会让我们无法在PostProcess存取到GBuffer的资料，这也就是为什 麽目前mobile不支援screen space reflection的原因之一。 9. 以下功能是Deferred Render才有的功能： a. Lit deferred decal：forward的decal是无光照的，而deferred render因为 有了GBuffer，可以靠上面的资料来计算光照效果。 b. IES Profile c. Light Function d. Better EnvBRDF：Deferred的效果上会更阅近PC，不需要real-time计算，只 需要做一次贴图采样就行了，因此性能更好；而foward因为要省下一个sampler，因此采 用的是近似的版本在real-time做计算。 10. Deferred Render在Android手机上有遇到一些兼容性问题，因此在设计系统时会考 虑以下几个限制。 a. 对於OpenGLES的支援：由於Mali不支援MRT(Multiple Render Targets)的 FrameBufferFetch，因此使用了Pixel Local Storage的技术，但用了这个技术的限制是 ，它只有128 bit。 b. 对於Vulkan的支援：调查了市面上的Android手机，发现有16%左右的机器只 支援4个Input Attachment。 11. 由於GBuffer和SceneDepth都会算在InputAttachment上，为了支援16%只有4个 Input Attachment的机器，引擎只能把GBuffer的数量控制在3个，再加上一个SceneDepth 就到了4个上限。不像PC可以创出5张或更多的GBuffer来支援一些效果。 12. 每个平台都会有以下几个Buffer：SceneColor、SceneDepth以及GBufferA、 GBufferB、GBufferC。其中SceneDepth如果PP用不到就不需存下来以节省频宽。 13. 在Android Mali OpenGLES上我们是把GBuffer利用Pixel Local Storage存在Tiled Memory上，再加上32bit的SceneColor，刚好占满Pixel Local Storage的128 bit。 14. Vulkan或Qualcommon的GLES手机，我们是用Memoryless的方式把GBuffer建立在 TileMemory上。 a. 注：Memoryless代表该份资料只会存在於TileMemory而不会回存到System Memory，这也就代表PostProcess存取不到GBuffer上的资料。 15. 在IOS或其他PowerVR的Android GLES手机：因为GPU不支持DepthBufferFech，只能 用MRT的FrameBufferFetch，所以只能新申请一张32bit的DepthAux来存Depth。DepthAux 跟GBuffer一样是memoryless，所以不占回写到System Memory的频宽，只是需要处理一下 shader fetch depth的逻辑。 16. 在UE4中不支援shading model只能支援defaultLit，要支援shading model的话，就 要必须要有至少4个通道来存储custom data，最好每个通道都有8 bit，不然精度不太足 。正常情况下我们可以多申请GBuffer来达成这件事，但是因为硬体的限制只能有4个 Input Attachment，所以我们只能想办法挖东墙补西墙。 17. 前提是，在Mobile Deferred Render上我们我们只有GBufferA、GBufferB、 GBufferC，每张Buffer都有32 bit，里面各别存了下面资料： a. GBufferA： Encoded Normal.xy：由於normal的z可以靠cross product算出来，因此只 需要xy二个通道就行了，但由於normal在某些情况下需要比较高的精度，例如在一些反射 比较好的效果下，如果只用8 bit可能会看到一些瑕疵，因此xy各别用10 bit保存，共20 bit。 ShadingModelID：占用4 bit。 PerObject Data：在Mobile中没有使用 b. GBufferB：Metallic、Specular、Roughness以及Indirect Irradiance，各 别占用8 bit。 c. GBufferC：BaseColor.RGB占用24 bit、Precomputed Shade 8 bit。 18. 以上资料有一些东西可以省下来让给CustomData用 a. GBufferA：PerObject Data有8 bit在Mobile中没有使用，可以拿出来。 b. GBufferB中的Metallic在很多ShadingMode中没有用到，可以拿出来。 c. GBufferB跟GBufferC中的Indirect Irradiance只在静态光照下用到，限制只 能开动态光的话就能拿出来给CustomData用。 d. 以上共4个通道可以在只有动态光条件下空出来给CustomData 19. 影片上有详细讲解Buffer Layout里面各别存了什麽东西的细节，建议大家去看。 20. 目前UE5.1中在关掉静态光的情况下已经可以支援所有的Shading Model 21. Eye shading model有一点特殊，它用到了subsurface profile shading model，所 以在Mobile上它用了5个custom data，所以我们就只能把其中二个custom data压缩到一 个通道里。所会如果看到结果感觉到精度不足，很有可能就是这个原因。 22. 由於GBuffer已经把Tiled Memory都占用了，因此不能使用MSAA，因此目前引擎只支 援FXAA跟TAA跟5.1新增由AMD研发的FSR技术。虽然FSR的效率上比不上有硬体支援的MSAA ，不过效果不差。 23. 补充FSR：由官网的资料看来，他是个可以用在全平台的技术，不像NVDIA的DLSS需要 用到GeForce RTX上专门的Tensor核心。 24. 关於lighting跟shadow的支援状况： a. Directional light pass：支援Light function material、Clustered local light(runtime toggle：r.Mobile.UseClusteredDeferredShading)、planar reflection、CSM and distance field shadow以及Reflection。 b. Reflection and sky pass：如果只有一个方向光就会合并到Directional light pass里一起做(inline)，不然为了避重覆计算会统一在这个pass做。 c. Local Light pass：Light area masked with stencil、support movable spot light shadow、support IES Profile、Support light function。Local light是 分二次绘制的，第一次是用stencil 报标记灯光所覆盖的区域，第二次是在这个区域的像 素里去着色，也是为了性能优化。 d. Simple light pass：这个是粒子里创建的简单光源，通常它是在clustered local light阶段绘制的，如果没有开启clustered local light，才会有自己的pass。它 的过程和local light的pass类似。 25. 在UE5.1中，mobile上也支持了Deferred render lighting channel，不过我们的方 式跟PC上的不太一样，因为PC上是把Lighting channel写到stencil buffer里，然後在 shader里面去读取，这个对於mobile device来说有点困难。因为OpenGLES不支持 TextureView的扩展，所以我们在硬体上就是直接在stencil test上做。 26. 在硬体上就是直接在stencil test上做的方法如下：我们只遍历所有的灯光，只做一 次lighting channel的stencil test。但由於每一盏灯只支持一个lighting channel，如 果有多个lighting channel的话就会出错。这也是美术上需要留意的地方。 27. 关於优化，我们主要是做了以下二个优化 a. 只在必须的情况下才去把数据存下来，比如DepthAux，我们直接申明成 memory less，又因为我们不支持MSAA，所以GBuffe也可以弄成memory less。还有就是 SceneDepth，只在需要的时候才用到，如果PP阶段没有用到Depth的讯息我们就可以不用 存下来。 b. 另外我们发现开启deferred rendering之後，半透明阶段的渲染耗时比以前 高，後来是发现是因为半透明阶段，默认也开了Clustered local light和Clustered reflection，这个对性能有比较明显的影响。然後我们本身对於半透明的光照和反射效果 的需求并没有那麽高，所以我们在半透明阶段关掉这些计算，这样半透明的效率就和 forward持平了。 28. fornite在season 22会开启，有做了初步的测试，发现，如果用vulkan的话性能会 有普遍改善、卡顿变少，不过OpenGLES测下来发现性能会变差，後来发现是因为DXC转译 Shader有点问题导致性能下降，并不是因为deferred rendering的问题，後续会修覆之後 再针对openGLES打开 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 122.116.111.188 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1662197538.A.783.html