Optimization using batching

简介

游戏引擎必须向GPU发送一组指令,以告诉GPU要画什么和在哪里画。这些指令是使用称为 :abbr:`APIs(Application Programming Interfaces)`的通用指令发送的。图形API的例子有OpenGL、OpenGL ES和Vulkan。

不同的API在绘制对象时产生的成本不同。OpenGL在GPU驱动中为用户处理了很多工作,但代价是要付出更昂贵的绘制调用。因此,通常可以通过减少绘制调用的次数来加快应用程序的速度。

注解

2D batching is currently only supported when using the GLES2 renderer.

Draw calls

在2D中,我们需要告诉GPU渲染一系列基本单元(矩形、线条、多边形等)。最明显的技术是告诉GPU一次渲染一个基本单元,告诉它一些信息,如使用的纹理、材质、位置、大小等,然后说 "Draw!"(这叫做绘制调用)。

虽然从引擎方面来看,这在概念上很简单,但以这种方式使用时,GPU的运行速度非常慢。如果你告诉GPU在一次绘制调用中全部绘制一些类似的基本单元,GPU的工作效率要高得多,我们称之为 "批处理"。

事实证明,这样使用时,它们不仅仅是工作速度快一点,而是工作速度 快许多

由于 Godot 被设计为通用引擎,进入 Godot 渲染器的基本单元可以以任何顺序排列,有时相似,有时不同。为了使Godot的通用性与GPU的批处理偏好相匹配,Godot具有一个中间层,它可以在可能的情况下自动将基本单元分组,并将这些批处理发送到GPU上。这可以提高渲染性能,同时只需要对您的Godot项目进行少量(如果有的话)更改。

它的运作方式

指令以一系列项目的形式从游戏中进入渲染器,每个项目可以包含一个或多个命令。这些项目对应场景树中的节点,而命令则对应矩形或多边形等基本单元。有些项(如 TileMaps 和文本)可以包含大量命令(如图块和字形)。其他项目,如精灵,可能只包含一个命令(一个矩形)。

批处量使用两种主要技术将基本单元分组:

  • 连续的项目可以连接到一起。

  • 一个项目中的连续命令可以连接成一个批次。

Breaking batching

只有当项目或命令足够相似,可以在一次绘制调用中呈现时,才能进行批处理。某些变化或技术,在必要时,阻止形成一个连续的批次,被称为"打破批次"。

批处理将被下列事项打破(其中包括):

  • 纹理的变化。

  • 材质的变化。

  • 改变基本单元类型(比如从矩形到线条)。

注解

例如,如果你绘制一系列的精灵,每个精灵都有不同的纹理,那么就没有办法将它们进行批处理。

确定渲染顺序

问题来了,如果只有相似的物品才能批量绘制在一起,那我们为什么不把一个场景中的所有物品都浏览一遍,把所有相似的物品都分组,然后绘制在一起呢?

在3D中,这往往正是引擎的工作方式。然而,在Godot的2D渲染器中,项目是按照 "绘制顺序",从后到前绘制的。这确保了当前面的项目重叠时,它们会被绘制在前面的项目之上。

这也就意味着,如果我们试图在每个纹理的基础上绘制对象,那么绘制的顺序可能会被打破,对象将以错误的顺序绘制。

在Godot,这种从后到前的顺序由以下因素确定的:

  • The order of objects in the scene tree.

  • 对象的Z索引。

  • Canvas Layers(画布层)。

  • YSort 节点。

注解

您可以将类似的对象分组,以便于进行批处理。虽然这样做并不是您的必须,但可以将其视为一种可选的方法,在某些情况下以提高性能。请参阅 :ref:`doc_batching_diagnostics`一节来帮助做出选择。

A trick

现在,来点小技巧。尽管绘制顺序的概念是物体从后到前渲染,但考虑三个物体 ABC ,它们包含两种不同的纹理:草和木头。

../../_images/overlap1.png

按照绘画者的排列顺序如下:

A - wood
B - grass
C - wood

由于纹理的变化,它们不能被批量化,将在3次绘制调用中呈现。

然而,绘制的顺序只是在假设它们将被绘制在 之上 的前提下才需要。如果我们放宽这个假设,即如果这3个对象都不重叠,就 不需要 保留绘制顺序。渲染的结果将是一样的。如果能利用这一点呢?

项目重新排序

../../_images/overlap2.png

事实证明,我们可以对项目进行重新排序。但是,只有在物品满足重叠测试的条件下才能做到这一点,以确保最终的结果和没有重新排序一样。重叠测试在性能上非常廉价,但并不是绝对免费的,所以,提前查看项目决定是否可以重新排序是有一点成本的。为了平衡项目中的成本和收益,可以在项目设置中设置提前查看重排序的项目数量(见下图)。

A - wood
C - wood
B - grass

由于纹理只变化一次,所以我们只需要2次绘制调用就可以呈现上面的内容。

灯光

虽然批处理系统的工作通常很简单,但当使用 2D 灯光时,它就变得复杂很多。这是因为灯光是通过额外的通道绘制,每个影响基本单元的灯光都有一个通道。考虑2个精灵 AB ,具有相同的纹理和材质。在没有灯光的情况下,它们将被分批在一起,并在一次绘制调用中绘制。但如果有3个灯光,它们将按如下方式绘制,每条线都是一个绘制调用:

../../_images/lights_overlap.png
A
A - light 1
A - light 2
A - light 3
B
B - light 1
B - light 2
B - light 3

那是很多绘制调用。仅仅是2个精灵就需要8次调用,考虑到要绘制1000个精灵,绘制调用的次数很快就会变成天文数字,性能也会受到影响。这也是为什么灯光有可能大大降低2D渲染速度的部分原因。

不过,如果你还记得我们的魔术师在物品重新排序时的技巧,也可以用同样的技巧来绕过绘制对灯光的排序!

如果 AB 不重合,可以将它们一起批量渲染,绘制过程如下:

../../_images/lights_separate.png
AB
AB - light 1
AB - light 2
AB - light 3

也就是只有4个绘制调用。还不错,因为减少了2倍。然而,考虑到在真实的游戏中,可能会绘制接近1000个精灵。

  • 之前: 1000 × 4 = 4,000 绘制调用。

  • 之后:1 × 4 = 4 绘制调用。

这就减少了1000倍的绘制调用,应该会给性能带来巨大的提升。

Overlap test

然而,与项目重新排序一样,事情并不那么简单。必须首先执行重叠测试,以确定是否可以加入这些基本单元。这种重叠测试的成本很小。同样,您可以在重叠测试中选择要提前查看的基本单元数量,以平衡收益与成本。对于灯光,收益通常远远大于成本。

此外,根据视图中基本单元的排列,重叠测试有时会失败(因为基本单元重叠,因此不应连接)。在实践中,绘制调用的减少可能不如在完全没有重叠的完美情况下那么显著。但是,性能通常远高于没有这种照明优化的情况。

Light scissoring

批处理会使剔除不受光线影响或部分影响的物体变得更加困难。这可能会增加不少填充率要求,并减慢渲染速度。 填充率 是指像素被着色的速度。这是另一个与绘制调用无关的潜在瓶颈。

为了解决这个问题(并在总体上加快光照速度),批处理引入了光线裁剪。使用OpenGL命令 glScissor() ,它可以识别一个区域,在这个区域之外,GPU不会渲染任何像素。我们可以通过识别光线和基本单元之间的交叉区域,并将光线渲染限制在 该区域 ,从而大大优化填充率。

光线裁剪是通过 scissor_area_threshold 项目设置来控制的。这个值在1.0和0.0之间,1.0为关闭(不裁剪),0.0为在任何情况下都裁剪。设置的原因是,在某些硬件上进行裁剪操作可能会有一些小成本。也就是说,当你在使用2D照明时,裁剪通常应该会带来性能的提升。

阈值与裁剪操作是否发生之间的联系并不总是直接的。一般来说,它代表了裁剪操作可能 "保存" 的像素区域(即保存的填充率)。在1.0时,整个屏幕的像素都需要被保存,而这种情况很少发生,所以它被关闭。在实践中,有用的值接近于0.0,因为只有一小部分像素需要被保存,操作才是有用的。

具体关系可能不需要用户操心,但出于兴趣,将其列入附录: Light scissoring threshold calculation

Light scissoring example diagram

右下角是一盏灯,红色区域是裁剪操作保存的像素,只有交叉点需要渲染。

Vertex baking

GPU着色器主要通过2种方式接收到需要画什么的指令:

  • 着色器统一(例如,调整颜色、项目变换)。

  • 顶点属性(顶点颜色,局部变换)。

然而,在一个单一的绘制调用(批处理)中,我们不能改变uniforms。这意味着,我们不能将改变 final_modulate 或一个项目变换或命令批处理在一起。不幸的是,这在很多情况下都会发生。例如,精灵通常是单独的节点,有自己的项目变换,它们也可能有自己的颜色调制。

为了解决这个问题,批处理可以将部分uniforms "烘焙" 到顶点属性中。

  • 项目变换可以与局部变换相结合,并以顶点属性发送。

  • 最后的调制颜色可以与顶点颜色相结合,并以顶点属性发送。

在大多数情况下,这都能正常工作,但如果着色器希望这些值单独可用,而不是组合在一起,这个快捷方式就会失效,这可能发生在自定义着色器中。

自定义着色器

由于上述限制,自定义着色器中的某些操作将阻止顶点烘烤,因此减少了批量化的可能性。虽然我们正在努力减少这些情况,但目前适用以下注意事项:

  • 读取或写入``COLOR`` or ``MODULATE``禁用顶点颜色烘焙。

  • 读取``VERTEX`` 禁用顶点位置烘焙.

Project Settings

为了微调批处理,有许多项目设置可用。在开发过程中,您通常可以将这些设置保持为默认状态,但最好进行试验,以确保获得最大的性能。花一点时间调整参数,往往可以用很少的精力获得可观的性能提升。更多信息请参见项目设置中悬停时工具提示。

rendering/batching/options

  • use_batching - Turns batching on or off.

  • use_batching_in_editor 在Godot编辑器中开启或关闭批处理。这个设置不会以任何方式影响正在运行的项目。

  • single_rect_fallback --这是一种更快的绘制不可批处理矩形的方式。然而,它可能会导致某些硬件上的闪烁,所以不推荐使用。

rendering/batching/parameters

  • max_join_item_commands - 实现批处理的最重要方法之一是将合适的相邻项目(节点)连接在一起,然而只有当它们所包含的命令兼容时,才能被连接。因此,系统必须对一个项中的命令做提前查看,以确定它是否可以被加入。这样做每个命令的成本很小,而命令数量多的项目不值得加入,所以最佳价值可能取决于项目。

  • colored_vertex_format_threshold - 将颜色烘焙到顶点中会导致顶点格式更大。除非在加入的项目中有大量的颜色变化,否则不一定值得。这个参数表示包含颜色变化的命令和总命令的比例,超过这个比例就会切换到烘焙颜色。

  • batch_buffer_size--这决定了一个批次的最大大小,它对性能的影响不大,但如果内存很重要的话,那么就值得将其降低。

  • item_reordering_lookahead - 项目重新排序可以帮助,特别是使用不同纹理的交错精灵。重叠测试的提前查看的成本很小,所以每个项目的最佳值可能会改变。

rendering/batching/lights

  • scissor_area_threshold- 请参考灯光剪裁。

  • max_join_items - 在照明前加入项目可以显著提高性能。这需要进行重叠测试,成本较小,因此成本和收益可能取决于项目,因此这里使用的代价最高。

rendering/batching/debug

  • flash_batching - 这纯粹是一个调试功能,用于识别批处理和遗留渲染器之间的回归。当它被打开时,批处理和遗留渲染器会在每一帧中交替使用。这将会降低性能,不应该用于最终的输出,而只是用于测试。

  • diagnose_frame - 这将定期打印诊断批处理日志到Godot IDE/控制台。

rendering/batching/precision

  • uv_contract - 在某些硬件上(尤其是某些Android设备),有报告称图块贴图的绘制略微超出其UV范围,导致边缘伪影,如图块周围的线条。如果你看到这个问题,请尝试启用uv收缩。这将使UV坐标小幅收缩,以补偿设备上的精度误差。

  • uv_contract_amount--希望默认的数量能够解决大多数设备上的伪装问题,但这个值仍然可以调整,以防万一。

Diagnostics

虽然你可以改变参数并检查对帧率的影响,但这可能会让人感觉像盲目地工作,不知道下面发生了什么。为了帮助解决这个问题,批处理提供了一个诊断模式,它将定期打印出(到IDE或控制台)正在处理的批处理列表。这可以帮助确定批处理没有按照预期发生的情况,并帮助你修复这些情况以获得最佳性能。

Reading a diagnostic

canvas_begin FRAME 2604
items
    joined_item 1 refs
            batch D 0-0
            batch D 0-2 n n
            batch R 0-1 [0 - 0] {255 255 255 255 }
    joined_item 1 refs
            batch D 0-0
            batch R 0-1 [0 - 146] {255 255 255 255 }
            batch D 0-0
            batch R 0-1 [0 - 146] {255 255 255 255 }
    joined_item 1 refs
            batch D 0-0
            batch R 0-2560 [0 - 144] {158 193 0 104 } MULTI
            batch D 0-0
            batch R 0-2560 [0 - 144] {158 193 0 104 } MULTI
            batch D 0-0
            batch R 0-2560 [0 - 144] {158 193 0 104 } MULTI
canvas_end

这是一个典型的诊断方法。

  • **joined_item:**一个joined项可以包含1个或多个项(节点)的引用。一般来说,包含多个引用的jianed_items比包含单个引用的许多jianed_items要好。项目是否能被加入,将由其内容和与前一个项目的兼容性决定。

  • **batch R:**一个包含矩形的批次。第二个数字是矩形的数量。方括号内的第二个数字是Godot纹理ID,大括号内的数字是颜色。如果批次中包含多个矩形,则会在行中添加``MULTI``,以便于识别。看到``MULTI``是好的,因为它表示批处理成功。

  • **batch D:**一个默认的批次,包含其他一切当前没有批次的东西。

Default batches

默认批次后面的第二个数字是该批次中的命令数,后面是内容的简单摘要:

l - line
PL - polyline
r - rect
n - ninepatch
PR - primitive
p - polygon
m - mesh
MM - multimesh
PA - particles
c - circle
t - transform
CI - clip_ignore

您可能会看到包含无命令的 "虚拟 "默认批次,您可以忽略这些。

常见问题

I don't get a large performance increase when enabling batching.

  • 试着诊断一下,看看发生了多少批处理的情况,是否可以改进

  • Try changing batching parameters in the Project Settings.

  • 考虑到批处理可能不是你的瓶颈(见瓶颈)。

使用批处理会降低性能。

  • 尝试上述步骤来增加批处理的机会。

  • Try enabling single_rect_fallback.

  • 单一矩形回退法是在不进行批处理的情况下使用的默认方法,它的速度大约是原来的两倍。然而,它可能会导致某些硬件上的闪烁,因此不鼓励使用它。

  • 在尝试了上面的方法后,如果你的场景表现仍然较差,可以考虑关闭批处理。

我使用了自定义着色器,但项目没有批量化。

  • 自定义着色器在批处理时可能会出现问题,请参阅自定义着色器部分

我看到线程出现在某些计算机硬件上。

  • See the uv_contract project setting which can be used to solve this problem.

我使用了大量的纹理,所以很少有项目被批量化。

  • 考虑使用纹理图集。除了允许批处理外,这些图集还减少了与改变纹理相关的状态变化的需求。

Appendix

Light scissoring threshold calculation

实际用作阈值的屏幕像素面积比例是:ref:`scissor_area_threshold <class_ProjectSettings_property_rendering/batching/lights/scissor_area_threshold>`值的4次方。

例如,在1920×1080的屏幕尺寸上,有2,073,600个像素。

在1,000像素的阈值下,该比例将是:

1000 / 2073600 = 0.00048225
0.00048225 ^ (1/4) = 0.14819

所以:ref:`scissor_area_threshold <class_ProjectSettings_property_rendering/batching/lights/scissor_area_threshold>```0.15````是一个合理的尝试值。

另辟蹊径,比如用:ref:scissor_area_threshold <class_ProjectSettings_property_rendering/batching/lights/scissor_area_threshold>``为``0.5`:

0.5 ^ 4 = 0.0625
0.0625 * 2073600 = 129600 pixels

如果保存的像素数大于该阈值,则剪刀被激活。