如何在 UE4 移动端中实现 HZB?

作者:GWB-腾讯创意游戏合作计划
2020-09-28
3 3 0

Hierarchical Z-Buffering 分层 Z 缓冲(HZB)对遮挡剔除研究具有重要影响,是 GPU Driven Rendering Pipeline 的重要剔除手段。目前部分主流商业引擎可能因为某些原因导致该技术无法完全在 GPU 端工作,但依然是值得探讨的。本文先介绍 HZB 的基本原理以及 UE4 在 PC 端的实现方式,然后介绍如何移植到移动端并分析其性能和带来的价值,以及未来还可以做的工作。

文 | Youwei

腾讯互动娱乐 游戏客户端开发

HZB 的原理

一般来说,大多数基于 HZB 的遮挡剔除是这样的工作的:

1. 使用一些遮挡器生成一个完整的分层 Z-金字塔。

z-pyramid 的最低级别是一个标准的 z-buffer。在所有其他层,每个 z 值都是上一层对应的 2×2 像素中最远的 z

 

2. 要测试的对象是否被遮挡,可以将其包围体投射到屏幕空间,并在 z-pyramid 中估计 mip 级别。将对象的包围体投影到屏幕空间。最长的边 l(像素)用来计算 mip 等级λ。

边长越长,选取的 mip 等级越高。


3. 根据选定的 mip 测试遮挡。如果结果不明确,可以继续使用更细的 mip 级别进行测试。

这个选择的原因是它使成本可预测——最多需要读取和测试四个深度值。此外,这种测试可以被看作是“概率性的”,因为大对象比小对象更容易被看到,所以在这些情况下没有理由读取更多的深度值,即节省了带宽,也增加了 Cache 命中。

UE4 的实现

UE4 只在 PC 端进行了实现,过程大致一样,不同的是在构建层级 Z 缓冲上分为 ComputeShaderPixelShader 两种方式,然后最终剔除工作主要在 CPU 端进行,意味着需要回读 GPU 的测试结果。以下是 UE4 的工作流程:

  1. 使用 SceneDepth 作为数据源构建层级 Z 缓冲。Mip0 为第一级,大小为 1024*512,总共构建 10 级。分为两种方式,PixelShader 方式比较简单,一次构建一级,总共执行十次。ComputeShader 则稍微复杂一点,利用 GroupMemoryBarrierWithGroupSync,每次同时构建 4 级,总共只要执行 3 次,便完成构建。
  2. 场景中的物体经过视锥剔除以后,剩下的会被收集起来,存放在一个数组中,并且每个物体会保存自己在数组中的索引值。然后,创建 2RGBA32 格式的贴图,一张存放物体包围盒的质心坐标,一张存放物体包围盒的大小。每次从数组中取 64 个物体作为一组,保存到贴图的 64 个像素区域中。
  3. 采样第二步中的贴图,获取物体的质心坐标和包围盒大小,可以计算出物体包围盒的八个顶点的世界位置,对这八个顶点进行投影,选取其中最近的 Z 值。根据投影后的矩形区域,选取最长边长计算 mipmap 等级,然后在矩形区域内采样该 mipmap16 个像素,选取其中最远的 Z 值。如果包围盒最近的 Z 值比它还小,则物体不可见。将结果保存到一张格式为 RGBA8RenderTarget 中,作为下一帧读取。
  4. 当前帧读取上一帧的贴图数据到一个数组中。每个物体将上一帧保存的数组索引到该数据进行查询,查询结果决定了该物体在当前帧的可见性。

以上步骤看出,UE4 的 HZB 实现流程没有完全放在 GPU 端执行,在下一帧的时候需要回读上一帧的结果,然后进行查询以决定物体当前帧的可见性。另外,在第三步中,计算最远 Z 值时,采样了矩形区域内 16 个像素,而不是 4 个像素。 

移动端的实现

移动端的 HZB 方案大部分可以与 PC 端共用一套逻辑实现,然后针对移动端性能点进行优化。移动端需要解决的第一个首要问题就是 SceneDepth 的获取,因为它是构建层级 Z 缓冲的重要数据来源。

在移动端上,一般来说,如果存在后处理材质需要访问场景深度信息,UE4 会将场景线性深度值保存在 SceneColorAlpha 通道。而对于透明材质,如果使用了 DepthFade 材质节点,则会通过移动设备扩展 API 来直接提取 FrameBuffer 中的深度信息。

那我们如果想在移动端上直接访问深度纹理的话,需要怎么做了?可以通过设置 r.Mobile.ForceDepthResolve1 来始终保留移动端的深度信息。强制深度解析,为设备保留深度纹理。

移动端获取深度纹理

获取了深度纹理,就可以开始构建层级 Z 缓冲。考虑到移动设备的兼容性,这里只使用了 PixelShader 方式,依然构建了 10mipmap。为了保证深度值的精度,这里将每个深度值编码到 rgba8888 格式的贴图中。

移动端构建层级 Z 缓冲

构建完层级 Z 缓冲以后,接下来就是进行遮挡测试。算法沿用了 PC 端的方式,将结果保存在贴图中,下一帧回读。移动端上回读 GPU 贴图数据,需要注意的是,UE4 会默认处理上下翻转。因为这里只是存放遮挡结果的数据贴图,所以不需要做上下翻转。

最后一步遮挡查询,过程和 PC 端一样,每个物体用上一帧的数组索引去查询自己当前帧的可见性。 

优化读取性能

移动端回读 GPU 数据相当耗费性能,我们可以来看下 glReadPixels 分别在 oppo 手机型号为 r15 和 r17 上的测试结果:

r15 耗时 6~8ms

r17 耗时 16~20ms

直接调用 glReadPixels 相当慢,不过,好在目前大多数移动设备的 opengles 已经达到 3.0 以上,所以,可以考虑使用 PBO 的方式进行优化,使用 glMapBufferRang 进行读取。过程大致如下:

  1. 初始化 2 个 buffer
  2. buffer1 用于异步 glReadPixels 读取,buffer2 用于 glMapBufferRange 读取。
  3. 下一帧交换 bufferbuffer1 用于 glMapBufferRangebuffer2 用于 glReadPixels

再来看下,优化后的测试结果:

优化后,r15 耗时 0.9ms

优化后,r17 耗时 4~6ms

硬件遮挡查询 和 HZB 在 oppo r15 上的性能对比

经过初步优化,我们来看下,硬件遮挡查询和 HZB 各自在手机上的性能对比。测试分为静态物体和动态物体。新建一个场景,场景内随机生成 10000 个物体。在分别只开启硬件查询和只开启 HZB 的情况下,对帧率和被遮挡物数量的影响。UE4 针对硬件查询做了 Batch 优化,这样可以大大降低硬件查询带来的 DC 开销,不过 Batch 只对静态物体有效。所以,需要分开测试。

动态物体:

如图,只开启了硬件查询,因为动态物体无法 Batch,Occlusion queries 相当高,达到 987,而 draw call 数量达到了 1450。被遮挡物体为 579,可见物体为 411。帧率只有 18。由此可见,对于大量动态物体,硬件查询本身带来了巨大的 DC 开销。

如图,只开启了 HZB,硬件查询的 DC 开销已经没有了,被遮挡物体为 570,可见物体为 420。Draw call 为 467,帧率为 30

结论:对于大量动态物体查询的场景,从被遮挡物体数量和可见物体数量两个数据指标来看,硬件查询和 HZB 不相上下。性能上,HZB 优势明显。 

静态物体:

如图,只开启硬件查询,因为静态物体的原因,硬件查询发挥了 Batch 的优势,Occlusion queries 只有 58,draw call 只有 511,帧率达到 35

如图,只开启了 HZB,硬件查询 Batch 带来的 DC 也没有了,所以 draw call 略有下降。帧率为 33

结论:对于大量静态物体查询的场景,HZB 仍适用,性能与硬件查询 Batch 相当。

硬件遮挡查询 和 HZB 在 oppo r17 上的性能对比

同样分别测试动态物体和静态物体,r17 和 r15 表现了完全的不一样的结果,之前在优化读取时也发现,r17 依然有 4~6ms 的开销,这是为什么了?这跟 r15 和 r17 在硬件上不同有关。

R15 硬件参数

R17 硬件参数

另外,值得一提的是,UE4 针对高通设备,做了硬件查询的上限限制。最大 510 次查询,而其他设备默认是最大 4000 次查询。

这导致了 R17 在大量动态物体场景下,即便没有做 Batch,也只有不超过 250 的 Occlusion queries 数量。这并不是什么优化,而是 UE4 直接放弃了超过该数量的硬件查询,再加上依然存在的回读耗时,这样使得 HZB 的优势就不那么明显了。

如图,R17 上,开启硬件查询,关闭 HZB。

如图,R17 上,关闭硬件查询,开启 HZB。

结论:基于以上原因,在大量动态物体和静态物体场景下,HZB 在 R17 上都表现不佳。 

其他性能开销

移动端除了回读耗时以外,在 HZB 构建以及遮挡测试阶段,性能消耗也不能忽视,特别是采样 16 次贴图的操作。如下分别是在 R15 和 R17 上的测试结果:

R15 在构建和测试阶段分别耗时 2.6ms 和 1.6ms。回读耗时 0.9ms

R17 在构建和测试阶段分别耗时 0.48ms 和 0.41ms。回读耗时 5.2ms

通过对比发现,R15 回读快,而构建慢。R17 回读慢,而构建快。不同的硬件架构带来的性能差异很大,关于移动硬件分析已经不属于本文探讨范畴了,在这里就不展开讲了。

总结

关于 UE 硬件查询的 Batch 结论:

  1. 动态物体不会做 Batch,全部一个一个去查询,带来巨大的 DC 开销。
  2. 静态物体在被遮挡的情况下会做 batch 查询,DC 显著减少。
  3. 高通手机最大查询次数为 510,其他为 4000,而实际推荐最佳查询次数是 2502000(分别除了 2)。

移动端 HZB 结论:

大量动态物体查询,HZB 适用于非高通移动设备上。

大量静态物体查询,HZB 仍适用于非高通移动设备上,性能与硬件查询 Batch 相当。 

针对移动端未来可以做的优化方案:

  1. 将物体数据由质心坐标+包围盒范围改为质心坐标+包围球半径,可节省一张 RGBA32 贴图。
  2. 16 次采样改为采样包围球表面最近点和包围盒四个顶点,可减少 11 次采样。甚至更保守点,直接将包围球面最近点作为采样点进行比较。
  3. 高通设备可以考虑使用 vulkan 图形 API 进行数据回读。
  4. 高通设备在构建 HZB 的时候可以考虑使用 ComputeShader

近期点赞的会员

 分享这篇文章

GWB-腾讯创意游戏合作计划 

腾讯游戏学院 · 游戏扶持业务致力于为创意游戏团队提供研发指导、技术支持、资金对接和发行推广等全方位服务,帮助团队打磨游戏品质,打造精品游戏! 

您可能还会对这些文章感兴趣

参与此文章的讨论

暂无关于此文章的评论。

您需要登录或者注册后才能发表评论

登录/注册