ttod_qzstudio

剖析虚幻渲染体系（14）- 延展篇：现代渲染引擎演变史Part 3（开花期一）

14.5 结果期（2016~2022）
- 14.5.1 图形API
  - 14.5.1.1 DirectX
  - 14.5.1.2 OpenGL
  - 14.5.1.3 Vulkan
  - 14.5.1.4 Metal
- 14.5.2 硬件架构
- 14.5.3 引擎演变
  - 14.5.3.1 综合演变
  - 14.5.3.2 光影技术
  - 14.5.3.3 移动*台
  - 14.5.3.4 并行技术
  - 14.5.3.5 特殊技术
- 14.5.4 渲染技术
  - 14.5.4.1 Visibility Buffer
  - 14.5.4.2 Filmic SMAA
  - 14.5.4.3 High Dynamic Range Imaging
  - 14.5.4.4 Texture Streaming
  - 14.5.4.5 Frame Graph
  - 14.5.4.6 Display Latency
  - 14.5.4.7 Mesh Shading
  - 14.5.4.8 Nanite
  - 14.5.4.9 Radiance Caching
  - 14.5.4.10 Surfels GI
- 14.5.5 结果期总结
14.6 本篇总结
- 14.6.1 游戏引擎的未来
- 14.6.2 结语
特别说明
参考文献

14.5 结果期（2016~2022）

时间晃荡一下来到了2016年之后，这时期的游戏引擎朝着影视级、更加物理、更高效的方向发展。且看后面分析。

14.5.1 图形API

14.5.1.1 DirectX

DirectX在2016年之后主要发力于DirectX 12及相关子本版的更新，包含ID3D12Device、Shading Model 6.x、光线追踪、VRS、根签名、资源、同步、调试、PSO、命令列表、HLSL等方面的新增或改进。具体可参见：DirectX - Wikipedia和What's new in Direct3D 12。

14.5.1.2 OpenGL

OpenGL在2016年之后发布了4.6版本，新增或改进了SPIR-V、Multi-draw indirect、顶点着色器获取数据、统计和转换反馈溢出查询、各向异性过滤、夹紧多边形偏移、创建不报错的OpenGL上下文、原子计数器的更多操作、避免不必要的发散着色器调用等特性。

而OpenGL ES在此期间几乎纹丝不动。

14.5.1.3 Vulkan

在2016年及之后，Vulkan发布的版本、时间和特性如下表：

版本	时间	特性
Vulkan 1.3	2022-01	查询给定物理设备可用的扩展、Vulkan Profiles工具解决方案、改进多线程应用程序的验证层性能、新的扩展。
Vulkan 1.2	2020-01	时间轴信号量、形式化内存模型、线程同步和内存操作语义、描述符索引、多个着色器重用描述符布局、HLSL着色器的深入支持。
Vulkan 1.1	2018-03	subgroup、渲染和显示无法访问或复制的资源、多视图渲染、多GPU、16位内存访问、HLSL内存布局、YCbCr颜色格式、SPIR-V 1.3。

14.5.1.4 Metal

Metal作为Apple的自家图形API，2017年6月5日，苹果在WWDC上发布了第二个版本的Metal，由macOS High Sierra、iOS 11和tvOS 11支持。Metal 2不是Metal的单独API，由相同的硬件支持。Metal 2能够在Xcode中实现更高效的评测和调试，加速机器学习，降低CPU工作负载，支持macOS上的虚拟现实，尤其是Apple A11 GPU的特性。

在2020年WWDC上，苹果宣布将Mac迁移到Apple Silicon。使用Apple Silicon的Mac将采用Apple GPU，其功能集结合了之前在macOS和iOS上可用的功能，并将能够利用针对Apple GPU基于分块的延迟渲染（TBDR）架构定制的功能。

Metal旨在提供对GPU的低开销访问，命令预先编码，然后提交给GPU进行异步执行。应用程序控制何时等待执行完成，从而允许应用程序开发人员在GPU上执行命令时通过编码其它命令来增加吞吐量，或者通过显式等待GPU执行完成来节省电源。此外，命令编码与CPU无关，因此应用程序可以独立地对每个CPU线程的命令进行编码。渲染状态是预计算的，允许GPU驱动程序在执行命令之前提前知道如何配置和优化渲染管线。

Metal为应用程序开发人员提供了创建资源（缓冲区、纹理）的灵活性。可以在CPU、GPU或两者上分配资源，并提供更新和同步已分配资源的功能。Metal还可以在命令编码器的生命周期内强制执行资源的状态。在macOS上，Metal可以让应用程序开发人员自行决定要执行哪个GPU，可以选择CPU的低功耗集成GPU、分离式GPU（在某些MacBook和Mac上）或通过Thunderbolt连接的外部GPU。应用程序开发人员还可以优先选择在哪个GPU上执行GPU命令，并提供某个命令在哪个GPU上执行效率最高的建议。

14.5.2 硬件架构

在2016年之后，Nvidia先后发布了Pascal、Volta、Turing等架构的GPU，其中Turing架构配备了名为RT Core的专用光线追踪处理器，能够以高达每秒10 Giga Rays的速度对光线和声音在3D环境中的传播进行加速计算。Turing架构将实时光线追踪运算加速至上一代Pascal 架构的25倍，并可以以高出CPU30多倍的速度进行电影效果的最终帧渲染。

Turing架构的SM结构图。包含了用于光线追踪的RT Core和用于AI的Tensor Core。

Multi Adapter Integrated + Discrete GPUs由Intel呈现，阐述了2020年适用于集成和分离GPU的多适配器技术，包含集成+分离的机会、D3D12多适配器背景、实用非对称多GPU等。

集成图形的机会：许多游戏PC既有集成的GPU，也有离散的GPU，集成电路通常是空闲的，集成图形需要大量计算！而且Intel有一个扩展，可以帮助提高性能。然而，D3D12多适配器有许多缺陷，对于一类算法，有一种方法可以利用集成的GPU，通过适度的工程努力获得更高的性能。

D3D12多适配器支持，D3D支持多GPU的两种方式：

链接显示适配器（LDA， Linked Display Adapter）。显示为带有多个节点的一个适配器（D3D设备），跨节点/在节点之间透明地复制或使用资源，通常是对称的，即同一个的GPU。
显式多适配器。跨适配器共享资源有很多限制，可能是不对称的，这正是Intel正在做的。

多适配器方法：

共享渲染：分割帧、交替帧、棋盘格，非对称GPU只有很低的投资回报率。
后处理：CMAA、SSAO、相机效果…需要跨PCI总线两次。
遮挡剔除、物理、人工智能。生产者-消费者，从渲染运行异步时效果更好。

集成图形存储器是系统存储器，iGPU可以使用跨适配器共享资源，几乎不受损害：

D3D12跨适配器的资源：资源由绑定到适配器的D3D设备分配，如何在适配器之间传输数据？共享的、跨适配器的资源，必须放置在跨适配器共享堆中。堆创建的步骤：调整数据大小，在任意设备上创建共享堆，创建句柄。

跨适配器资源创建：打开第二台设备上的句柄，对两个适配器都在跨适配器堆中创建放置的资源，使用相同的对齐方式和大小。

粒子案例中的异步计算：乒乓缓冲区保存源状态和目标状态，读取初始状态，计算下一个状态，呈现结果，通过在计算下一个状态时呈现前一个状态来并行化状态（异步计算），缓冲区计数与交换链长度匹配。

多适配器的添加复制阶段：想法是每个适配器都是乒乓缓冲区，形成并行管线：2个状态n的读取者，计算状态n+1，渲染状态n-1。

多适配器的Pong：每帧交换缓冲区。

资源分配：渲染缓冲区使用局部适配器堆（Default、Committed），适配器离散存储器，适配器首选布局。计算缓冲区使用跨适配器堆、放置的交叉适配器，CPU存储器、线性布局。

复制队列：关键想法是分离适配器上的复制队列，从系统内存复制到分离内存，集成内存是系统内存，所以这是一种逻辑安排，显式复制阶段松散的时序。

利用这种耦合+分离的多GPU架构，可以更加高效地处理资源创建、跨适配器同步、命令队列等操作。获得的结果在GpuView显示并行运行的阶段，两个例子，全屏应用，当3D占主导地位时，就有时间进行计算和复制，在某些情况下，复制可能占主导地位（帧时间>渲染+计算）：

在以下情况下，此技术最适用：渲染GPU已饱和，纯生产者-消费者（数据只通过总线一次），任务可以完全卸载（无需协作），渲染不等待（管线有呼吸空间），最好是允许计算>1帧，许多异步计算任务都符合这种模式。请注意PCIe带宽：Gen3 x16是16GB/s，400万个粒子，每个粒子float4：64MB，16GB/64MB=256Hz最大帧速率，一些GPU/Config是x8：半带宽，尽可能降低数据传输大小！按使用情况拆分数据缓冲区具有性能优势。这个方案不仅适用于粒子，还可以是物理、网格变形、人工智能、阴影，许多异步计算任务都符合这种模式，检查英特尔集成图形！

14.5.3 引擎演变

14.5.3.1 综合演变

2016年，Towards Cinematic Quality, Anti-aliasing in Quantum Break谈及了影视级的质量和抗锯齿技术，比如间接照明、参与介质、几何体锯齿和镜面锯齿。

Light pre-pass就像完全延迟一样，想法是将照明与几何体分离，但与完全延迟不同的是，几何图形绘制两次。第1个Pass写入照明所需的一切数据，第2个Pass读取光源，并添加其它材质。

Light pre-pass的优势是用于照明的几何缓冲区占用少，易于在第2个几何通道上添加材质变化，通常在第2个几何通道中与MSAA结合。第2个几何通道决定使用什么样的照明采样，常用的方法是将当前几何图形与以前的几何图形进行比较，绘制几何缓冲区并选择最接*的匹配。当有匹配时，效果非常好，当没有好的样本可供选择时，就会出现问题。在头发和树叶着色器中，可以使用在alpha测试输出中使用棋盘格模式，但alpha测试输出上的棋盘格图案难以控制，要么在半分辨率照明下运行，要么开始丢失样本。多层的alpha测试让问题变得更加困难。

保存相关样本是需要解决的关键问题，希望可以使用4xMSAA几何缓冲区，但直接照明开销太大。文中给出的MSAA解决方案是使用几何分簇（Geometry Clustering），将几何缓冲区渲染到4xMSAA目标，将样本从4xMSAA减少到非MSAA（从4个样本减少到1个样本），在减少的样本上运行昂贵的着色，接着重建为4x MSAA，更多的几何样本（成本相对较小），更少的光照样本（计算繁重）。具体过程如下：

构造亚像素偏移。
- 计算16个样本的哈希值。32位值，其中16位法线值、8位深度、8位材质ID。
- 选择初始的4个样本。首先在角落里选择四个样本，通过选择角落，最大限度地增加独特样本的数量。
- 重新分配样本。对于每个选定的样本，测试是否存在重复，如果存在，用未选择的值替换重复项，确保避免不必要的重组，与屏幕保持一致是有道理的。
- 保存亚像素偏移。每2x2像素区域有32位，每个MSAA样本有2位，提供最终2x2输出上的采样位置，像素着色器输出一半大小的360p图像。
下采样。
- 读取亚像素偏移。每个2x2的tile共享单个32位亚像素偏移，在普通像素着色器中运行全屏通道。输出是最终的几何缓冲区，将用于AO、SSR、GI和照明。
- 先写入或*均值。输出第一个匹配项，*均值给出的结果稍好一些。

几何分簇和非MSAA的效果对比：

在处理第2个几何通道时，亚像素偏移提供每个MSAA采样使用哪个光照样本，读取基于2位偏移的光照样本。无需计算当前样本的几何特性，以便与几何缓冲区进行比较。在像素着色器中使用样本覆盖率（HLSL中的SV_Coverage），使用覆盖样本的*均值可以提高质量，但成本要高得多，文中使用firstbitlow和采样一次。

几何分簇、非MSAA和TAA的效果对比：

文中还涉及了时间抗锯齿和上采样。具有亚像素相机偏移的4帧，使用旋转的网格偏移。每帧将前三帧变换为当前投影，以尽可能减小帧间的增量，在单个计算着色器通道中共享夹紧的数据。对于TAA的夹紧，在当前帧计算相邻像素的最小/最大值，扩大了速度小的范围，以抑制亚像素偏移相机引起的闪烁。夹紧xyY并只扩展亮度，以便均衡锯齿和鬼影。对于TAA的上采样，组合4帧的结果，之前的帧已被重投影和夹紧，由于帧之间的采样是交错的，因此是上采样的良好位置，线性采样的效果出人意料地好。

另外，还大量使用了周期性噪点，因为TAA是4个连续帧的*均值。噪点过大可能会导致邻域夹紧出现问题，使用累积缓冲器降低噪点，在序列噪点中效果良好。

总之，具有4x MSAA的几何缓冲区，为720p图像提供了370万个分布良好的几何体样本。在使用较少样本计算照明时，需要进行高质量的下采样，以保留相关数据，下采样产生的亚像素偏移可用于其它效果。MSAA仍然与几何体锯齿相关，拥有更多更好的分布样本非常有意义。存储和重投影N个历史帧，为TAA和高端提供了一个良好的框架，输入过多变化的TAA会破坏系统，每帧都需要足够稳定。TAA将锯齿转换为鬼影，更紧的夹紧边界可能会导致闪烁。

D3D12 & Vulkan: Lessons Learned在DX12和Vulkan发布的一年后呈现的演讲，阐述了基于新生代图形API的引擎架构演变以及带来的影响。D3D11驱动程序经过了很好的优化，利用掌握的知识可以超越D3D11驱动程序，发明D3D12并不是为了在上面编写遗留API驱动程序。若将游戏引擎比作火箭，则DirectX 12和Vulkan可视作助推器：

在没有DX12和Vulkan的图形API之前的游戏引擎可视作是0~0.5阶段，没有加速器：

若融入DX12和Vulkan之后，有了一定的加速器，此时升级到了1.0阶段：

但此时的渲染器和图形API之间耦合过多，不够高级别或低级别，只能看作是有限加速的2.0：

将图形API下移，抽离出更底层的图形抽象层之后，则可以升级到3.0，获得了更大的助力器：

当时的游戏引擎正在过渡以支持Vulkana和D3D12，仍然需要D3D11支持，大多数引擎处于第1阶段和第2阶段之间。要充分利用所有API，需要进行大量思考，多队列支持需要额外的工作，需要兼容到D3D11，建议以D3D12/Vulkana为目标，并在D3D11上运行。

面向未来的设计，本文将指出常见的设计问题，把引擎准备好，将知识转化为更好的表现。

屏障控制：屏障是D3D12/Vulkan中的一个新概念，悲哀的事实是每个人理解错了。两个失败案例：太多或太宽导致性能差，缺失的屏障导致损坏（Corruption）。D3D11驱动在引擎下完成了屏障的这项工作——而且做得很好。到底什么是屏障？

将目标渲染转换为纹理。可能需要解压（和缓存刷新），供应商和GPU次代之间会发生什么变化？可能是无操作，可能是等待空闲，可能是完全缓存刷新。
将UAV转换成资源。如果做得不好，则需要产生刷新或等待空闲，如果操作正确，这些转换可以是免费的。

缺失的屏障：格式问题——GPU/特定于驱动程序的损坏，同步问题——依赖时间的损坏。

子资源（Subresource）需要单独跟踪，如下采样、阴影图集。如果转换所有的子资源，应该使用D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES，而不是逐个转换。对于放置资源和初始状态，使用前必须清除作为放置资源等创建的渲染目标，直接进入清除状态，不要从一些随机状态和转换开始。下图存在“基本状态”或冗余转换，即转换到目标状态然后恢复回基本状态（没有实际使用，只是转换回来了）：

有意思的屏障：

ResourceBarrier(0, nullptr)，即没什么变化，表明状态追踪做了错误的事情。
前一状态等于下一状态。发生的事情比你想象的要多——说不就行了。
永远记住——驱动假设你做的是最佳的事情，而不是通过驱动自身的任何启发式！

不必追踪所有资源状态，99%的资源是不可变的——只读，找到过渡点——通道的结束时间，在此处批处理屏障，只转换必需的屏障。

屏障调试技巧：

有一个写/读位。
记录所有转换，Grep和spreadsheet是你的朋友，检查转换的数量和类型等。
转换的数量应按可写资源的数量排序，再说一遍，grep和log是你的朋友，如果屏障数量超过9000，就有些可疑了！
存在每件事都有一个屏障（barrier-everything）的模式，与前面描述的“最坏情况”模式相同，但仅供调试使用。
确保资源每帧至少处于已知状态一次，例如在帧结束/开始处，将所有事物转换为已知状态，从而解决TAA或阴影图集破坏等问题。

更好的是，给驱动一定时间处理转换，用D3D12中的“Split barrier”，Vulkan的vkCmdSetEvent+vkCmdWaitEvents。

屏障总结：确保转换所有需要的资源（但不是更多），进入能进入的最具体的状态，可以把不同的状态联合起来。

运行控制，如何为GPU喂食（feed，即发送任务），首先提交命令列表，每帧资源更新和跟踪时间。不要通过手动分配内核来限制并行性
，使用任务/作业系统，自动使用所有内核，需要特别注意高效的工作提交和资源同步。

上图发生了什么？疯狂的线程池，CPU任务在最后提交工作，任务边界成为CPU/GPU同步点，任务完成后控制命令列表。

上图：每个栅栏基本上都是在GPU上等待IDL（或多或少）。更好的做法：保护每帧资源，无论如何，都不太可能在命令列表的“中间帧”开启工作，，用一个栅栏保护多个资源。确保作业系统能做到这一点，尽可能多地批量提交，提前提交，使GPU始终处于繁忙状态。理想的提交如下：

使用多线程设计，恰当地了解工作量和调度：

渲染通道：为帧建立一个高层次的图，通过Vulkan的渲染通道和子渲染通道告诉渲染器，允许驱动选择最佳的调度。允许你很好地表达“don’t care”。

调试提示：可以选择在一次提交中提交所有命令列表，有助于解决时序问题，如果不可能，则需要帧内GPU/CPU的同步。可以选择等待任何命令列表，有助于上传/资源同步，有些资源被破坏了？更新前刷新GPU。

提交总结：以每帧粒度追踪资源，理解帧结构，线程化对于获得良好的CPU利用率至关重要。

Practical DirectX 12 - Programming Model and Hardware Capabilities主要阐述了DX12的最佳实践、硬件特性等内容。

DX12旨在实现最大的GPU和CPU性能，能够投入工程时间！引擎注意事项，需要IHV特定路径，如果做不到这一点，请使用DX11，应用程序替换部分驱动程序和运行时，不能指望同样的代码在计算机上运行良好，所有的控制台、PC都是一样的，考虑特定于架构的路径，注意英伟达和AMD的细节。

工作提交方式有多线程、命令列表、命令束（bundle）、命令队列等。

多线程处理在DX11驱动程序：渲染线程（生产者）、驱动程序线程（消费者），在DX12驱动程序：不会启动工作线程，通过CommandList接口直接构建命令缓冲区。确保引擎在所有的核心上都有扩展，任务图体系结构效果最好，一个提交命令列表的渲染线程，多个并行构建命令列表的工作线程。

命令列表可以在提交其它命令列表时构建命令列表，提交或呈现时不要闲着，允许重复使用命令列表，但应用程序负责停止并发使用。不要把工作分成太多的命令列表，目标是每帧15-30个命令列表、5-10个ExecuteCommandLists调用。每个ExecuteCommandLists都有固定的CPU开销，每个ExecuteCommandLists调用会触发一个刷新，所以，把命令列表批处理起来，尝试在每个ExecuteCommandList中放置至少200μs的GPU工作，最好是500μs，提交足够的工作以隐藏操作系统调度延迟，对ExecuteCommandLists的小调用完成得比OS调度器提交新调用的速度更快。例如下图：

高亮显示的ECL执行时间约20μs，操作系统需要约60μs来调度即将到来的工作，等于有40μs的空闲时间。

命令束（bundle）是在帧中尽早提交工作的好方法，GPU上的束本身没有更快的速度，需要明智地使用它们！从调用命令列表继承状态–充分利用优势，但协调继承状态可能会有CPU或GPU成本。可以获得很好的CPU提升的是NVIDIA：重复同样的5+draw/dispatche用一个bundle，AMD：只有在CPU方面遇到困难时才使用bundle。

硬件状态包含管线状态对象（PSO）和根签名表（RST）。PSO对未使用的字段使用合理且一致的默认值，不允许驱动程序执行PSO编译，使用工作线程生成PSO，编译可能需要几百毫秒。在同一线程上编译类似的PSO，如具有不同混合状态的相同VS/PS，如果状态不影响着色器，将重用着色器编译，同时编译相同着色器的工作线程将等待第一次编译的结果。RST需要尽量保持小，按频率排列。

内存管理方面，需要谨慎和合理使用命令分配器、资源、驻留等操作。另外，还需要谨慎处理栅栏、屏障内同步操作。

GDC2017: D3D12 & Vulkan: Lessons learned是GDC2017上分享的DX12和Vulkan的学习课程。文中提到了引擎使用任务图的变革图例：

在屏障方面，手动操作不再有效，需要更高层次的抽象图，从第一天开始在Vulkan提供原生支持。着色器方面，着色器排列越来越少，Doom只有几百个，更多的游戏正在改变创作流程，以便更早地删减着色器变体，更多的高级工作（围绕编译器）正在进行。

引擎向更高级别的渲染发展，API的改进使其更易于使用，游戏受益！开放游戏/可伸缩性，可伸缩性还没有解决，游戏支持所有设置的新旧API，移动*台越来越重要，新的API似乎只是前进的道路。图形API的一种新方法需要ISV、IHV和标准机构之间的紧密合作，API随着游戏引擎的发展而发展，自发布以来，大量的变化让开发人员更轻松！

DirectX 12 Case Studies由NVidia呈现，讲述了DirectX12的相关技术和应用案例，文中涉及DX12的技术包含异步队列、内存管理、管线状态对象、着色器模型5.1资源绑定、多线程及其它。

对于异步队列，计算队列可以很好的跨供应商加速，*均5%的提升，异步工作负载主要与分辨率无关（针对1080p进行了调整），随着分辨率的增加，收益递减。

引擎使用3个复制队列，多个复制队列简化了引擎线程同步：

SM 5.1和/all_resources_bound着色器编译器标志将性能提高约1.0到1.5%，无需更改着色器代码，为纹理访问启用不太保守的代码生成。

Ubisoft的Anvil Next引擎：重新设计以充分利用DX12，最大限度地减少和批处理资源屏障，充分利用并行CMD列表录制，使用预编译渲染状态以最小化运行时工作，最小化内存占用，利用几个GPU队列。

Anvil Next引擎分组屏障图例。

Hitman渲染器处理完全动态的场景，例外情况是在水*负载期间产生反射和环境探针。使用分块延迟照明，前向光源使用单独的通道，用于剔除照明的门/室（入口/单元）系统。阴影用4个VSM级联，第4个是静态的，4~8个额外的阴影贴图。

对于CPU性能，代码可以像引擎代码一样进行分析和修复，设置了太多多余的描述符，确保只设置实际使用的描述符。次优的合批：最终批量处理资源转换和命令列表提交，最终通过多线程与最快的驱动程序相匹配。

当时的DX12内存管理也存在问题，DX12视频内存消耗过高（与DX11相比），DX11驱动程序非常擅长在视频内存之间移动内存。最终实现了一个分页（逐出）资源的系统，使用非常简单的LRU模型，很多工作都是出乎意料的，仍然不理想，因为有MakeResident的卡顿，在DX12上的性能更差，尤其是在低显存的GPU卡上。已实现的渲染目标内存重用系统（放置的资源），引入静态资源的子分配，为所有内容创建提交的资源将占用大量内存，PC上的内存节省不如控制台上的高，资源层（Resource tier）防止所有内存被用于各种资源。

DX12资源分配和围栏：需要一个超级快速的分配器来实现帧资源的无锁分配，在一个帧中有大量动态资源分配，如描述符、上传堆等。栅栏开销也很大，尝试将它们用于资源的细粒度重用，最终使用一个信号栅栏来同步所有的资源重用。

DX12状态管理：使用像素着色器对象存储PSO和其它状态，绝大多数像素着色器只有少量排列，可通过哈希访问的排列，已从状态管理中删除采样器状态对象，决定使用16个固定采样器状态。

为每个状态创建唯一的状态哈希，将所有状态块放入具有唯一ID的池中，状态块包括光栅化器状态、着色器等，使用块ID作为位来构造状态哈希。

DX12资源转换：实现了简化的资源转换系统，假定读取/SRV为默认状态，仅支持转换到RTV、UAV、DSV和转回，仅UAV屏障需要额外的转换。主渲染线程提交所有转换，主渲染线程还可以记录命令列表，并执行所有多线程同步，大大简化了代码。

3A游戏”的DX12内存管理：显式内存管理是实现出色且一致性能的关键，LRU资源管理战略有很长的路要走，在上次使用资源后，将其保存在内存中一段时间，只有当它被驱逐时才带进回收堆里。支持资源绑定tier 2，不使用时，表中的CB描述符必须解除绑定（设置为0），Nvidia驱动程序现在支持未清除的描述符，将CBV移动到根签名中以跳过解除绑定，当用作根CBV时，CBV只是一个GPU地址，无需调用CreateConstantBufferView()。确保对所有RST条目使用最佳着色器可见性标志，尽可能避免Avoid SHADER_VISIBILITY_ALL标记，在CPU内存中缓存RST状态以跳过冗余绑定，从而提高CPU性能。结果证明，应最小化RST的变化，使用整个帧的两种布局。对于屏障，最初的DX12路径有冗余屏障，屏障隐藏在抽象层中（自动触发），大部分时间都有效，对于特殊情况，引擎将切换到显式屏障管理，延迟屏障用于跳过进一步的冗余和合批屏障，将屏障添加到待处理列表中，等到最后一刻刷新列表，过滤掉冗余。

调试GPU：根据API（CPU）的错误代码检测到崩溃，在最后N帧命令中发生了崩溃…CPU调用堆栈很可能是个麻烦。

NVIDIA AFTERMATH可以提高GPU崩溃位置的准确性，使用命令流内联用户定义的标记，一旦到达每个标记，GPU就会发出信号，最后到达的标记表示GPU崩溃位置。

NVIDIA AFTERMATH帮助诊断GPU崩溃的新工具（标头+DLL），非常灵活/简单的API，当前与兼容DX11和DX12 UWP和/或Windows。它的局限性是需要NVIDIA GeForce驱动程序版本378.xx及以上，与D3D调试层不兼容。

Advanced Graphics Tech: Moving to DirectX 12: Lessons Learned也详细地阐述了育碧的Anvil Next引擎移植到DirectX12的具体过程、优化、技术、策略、经验教训等内容，诸如生产者消费者系统、调度图系统、屏障转换和优化、资源管理、资源依赖、内存重叠、资源同步、着色器、PSO等等内容。

总之，利用高级渲染过程知识优化API使用，高级生成系统节省了大量渲染工程师调试时间，粒度更小、基于blob的渲染接口，最大化CPU性能增益，避免重复工作，架构工作将使其它*台/API受益。利用DX12可获得约5%的GPU提升，15%~30%的CPU提升。

实现与DX11性能的对等是一项艰苦的工作，不要将性能视为最终目标，将努力视为通往：解锁异步计算、mGPU、SM6等功能，比以往任何时候都更接*与控制台的功能对等，改善引擎架构的机会，之后移植到其它等效的API要容易得多。

更多关于DX12和Vulkan的知识可参阅：剖析虚幻渲染体系（13）- RHI补充篇：现代图形API之奥义与指南。

Developing The Northlight Engine: Lessons Learned说明了Northlight引擎开发的DX12移植的过程和经验教训。Northlight引擎的渲染管线：

G缓冲、速度、阴影通道（多线程）。
全屏阴影。
全屏照明。
主要、透明通道（多线程）。
后处理。

DX12特性清单包含描述符表、动态资源、管线状态对象、命令列表/分配器、资源转换、暂存资源、小型资源、mipmap生成、空资源、计数/追加缓冲区、查询等。下面对它们进行阐述。

描述符表：是一个表包含任何着色器阶段可能使用的所有资源的描述符，每个draw调用都需要一个表，一旦在GPU上完成draw，就可以重复使用。
动态资源：DX12中没有这种东西，需要自己管理版本控制/重命名/轮换，写一次（CPU），读一次（GPU）使用上传堆环缓冲区。
PSO：创建是有问题的部分，理想情况下，在出口管线中输出，在游戏开始时加载，在第一次接触它们时就创建了它们，CS PSO可以在CS加载下生成，约500个单独的图形PSO需要约200毫秒才能生成。包含根签名（资源布局）、着色器代码、顶点着色器输入布局（不是顶点/索引缓冲区）、基本类型、混合、光栅状态、MSAA模式、渲染目标和深度模板格式等。
命令列表/分配器：DX11中的即时/延迟上下文，分配器拥有内存。
资源转换：驱动不再跟踪使用情况，使用前必须手动转换至正确状态：着色器资源、渲染/深度目标、复制源/目的地、UAV、呈现等。
暂存资源/更新子资源：没有动态资源，更频繁地使用暂存资源，按需从环形缓冲区或持久缓冲区，无更新子资源，不能依赖模拟的d3dx12.h的版本，无过渡纹理，通过过渡缓冲区进行模拟。
小型资源：CreateCommittedResource以64kB的页面进行分配，不会为少量资源而运行，理想情况下，在碎片整理堆中对所有资源进行子分配，或特殊情况下的小型资源。
GenerateMips：DX12中没有这种东西，为其编写一个计算着色器，发现手动实现的性能优于DX11，但需要处理许多不同的情况（2D/3D/数组/颜色空间）。
空资源：不能再绑定nullptr了，需要1D/2D/3D纹理、缓冲区、UAV纹理/缓冲区、CBV、采样器的空资源，可能需要将空绑定提升到抽象中更高的位置才能了解类型。
计数/追加缓冲区：DX12中没有这种东西，有一个单独的计数缓冲区，可以原子增加。
查询：另一个需要注意的容易忘记的方面，管理/轮询查询堆，合并解析（即合批在一起，避免多个调用），在完整的堆中回读。

从DX11移植至DX12，你现在是驱动了（成为真正的老司机），注意内存使用和性能，将优化重点放在瓶颈上，在单独的CPU和GPU时间线中思考。Northlight在移植过程中，对不同的对象操作如下：

资源屏障。在主线程中自动执行资源转换：绑定RT时、在描述符表中设置资源、复制，其它异步渲染线程不允许转换，在执行命令列表之前，手动确保资源（主要是RT）处于正确的状态。不必要地滥用它们可能会扼杀GPU性能，但取决于硬件，仅在必要时使用UAV屏障，它们会迫使GPU在调度之间闲置（DX11样式）。
绘制。遍历绘制，捕捉DX11样式集的调用，跟踪之前的值，如果PSO发生了变化，请将其标记为脏，如果已脏，在绘图时进行哈希，从映射表中获取PSO。仅在更改时设置索引/顶点缓冲区、RT/DS和描述符堆，集合在CPU上很便宜，但会导致硬件上下文滚动。PSO是只读、绑定和遗忘的，每次draw调用时旋转到空闲（GPU）描述符表中，在GPU上执行命令列表后重用描述符表。
线程。没有区分即使/延迟上下文，在任何线程上记录命令列表，从一个线程提交。
- 在池中保存描述符表管理器（处理表的旋转）、描述符表管理器GPU栅栏（让你知道何时可以重用表）、命令列表（在GPU完成执行后可以重用）、命令分配器（可用于多个命令列表）
- 初始化线程时获取描述符管理器、描述符管理器栅栏、命令分配器、命令列表。
- 结束线程时释放CPU可重复使用的描述符管理器、命令分配器。
- 执行命令列表之后释放GPU可重用的描述符管理器栅栏、命令列表。

总之，GPU性能：做正确的事情，匹配DX11，在所有架构上都很重要，搞砸GPU内存管理可能代价高昂。CPU性能：轻松超越DX11，但是，真的受到API开销的限制吗？实例化、LOD、良好的剔除使得驱动程序不会被绘制调用淹没。

Rendering 'Rainbow Six | Siege'是游戏《彩虹六号|围城》基于当前新一代渲染引擎的首次迭代，文献将重点介绍利用当前一代硬件才可能实现的计算的架构优化，以及新的棋盘渲染技术，该技术可以在不造成质量损失的情况下将渲染速度提高50%。

Siege的GPU帧的层次视图：几何体渲染*均花费5毫秒，大量使用剔除，缓存阴影，*均5毫秒用于照明（包括SSR），棋盘渲染相助，SSAO和SSR射线追踪以异步方式完成，后处理/其它全屏处理*均花费4ms。

CPU关键路径的层次视图：关键路径*均10毫秒，所有通道和任务都能够分叉和连接，以最小化关键路径，缓存阴影，不透明通道的最大线性长度为4ms，基于材质的绘制调用系统！

不透明物体的渲染管线如下：

阴影渲染：所有阴影都是基于缓存的，使用缓存的Hi Z进行剔除。太阳阴影以全分辨率完成，分离通道以释放VGPR压力，使用缓存阴影贴图的Hi Z表示法来减少每像素的工作量。局部光源以四分之一的分辨率进行解析，解析的结果存储在纹理数组中，光照积累时VGPR使用率较低，双边上采样。对于太阳、月亮的阴影，包含加载时生成的所有静态对象的阴影贴图。

通过混合级联和静态贴图来缩放阴影成本的能力，静态Hi Z阴影贴图始终用于动态对象剔除。在Xbox One上：第一级级联是完全动态的（6K分辨率不够），第二级和第三级级联仅渲染动态对象，并与静态阴影贴图混合，第四级由静态阴影贴图替代。

对于局部光源投影，最多处理8个可见阴影局部光源，流程如下：

在光照方面，在frustum上使用分簇结构：基于32x32像素的分块，Z指数分布，分层剔除光源体积以填充结构，被视为光源的局部立方体图，阴影、立方体图和遮挡板（gobo）位于纹理阵列中，延迟使用预先解析的阴影纹理数组，前向使用阴影深度缓冲区数组。

统一缓冲区（UNIFIED BUFFER）：彩虹六号中的许多资源都位于某种统一缓冲区中，如统一顶点缓冲区、统一索引缓冲区、统一常数缓冲区、...。结构化缓冲区构建在自动生成代码的原始缓冲区之上：使用C++数据描述符处理GPU统一数据，传递给指定访问模式的元数据。统一常数缓冲区示例代码：

统一缓冲区的好处：完全控制数据布局，可以很容易地尝试不同的数据类型访问（AOS、SOA、u32数组的结构、…），自定义打包和对新数据类型的支持，高级API支持广播值，代码自动生成允许我们轻松地迁移到新的访问模式。

基于材质的绘制调用：几何和常数是统一的，然后绘制调用由以下内容定义：着色器、非统一资源（纹理等）、渲染状态（采样器状态、光栅状态），共享上述内容的元素被批处理在一起，不使用资源和状态子集的通道将进一步批处理在一起。

收集绘制调用：初始化时，每个子网格实例映射到3个批次：普通、阴影和可见性，批处理类型用于屏蔽非必要的数据，每个批次将对应一个MultiDrawIndexedIndirect命令。

每个子网格实例都有一个全局唯一的索引：用于获取所有数据的索引，需要多个间接寻址。

对于每个通道收集子网格实例索引到动态缓冲区：每个通道只映射到一个批次类型，多线程作业中的缓冲区填充（1.5ms线性）。添加了执行剔除的额外数据：MultiDrawIndexedIndirect条目、新索引缓冲区偏移量、附加剔除标志。

使用了性能剔除，定义了多种类型的剔除：级别1——子网格实例剔除，级别2：子网格块（chunck）剔除，级别3：子网格三角形剔除。

结果：

非核批的DC数量（共总）	合批的DC数量（VIS + GBUFFER + DECALS）	合批的DC数量（阴影）	裁剪效率
10537	412	64	73%

接下来聊棋盘渲染。

棋盘渲染的基本思想解决了锯齿问题，在一系列图像上进行实验，首先测试质量，对于大多数图像，使用棋盘模式时PSNR更好：视觉效果也更令人愉悦，从一开始，使用MSAA 2X的想法就开始流行起来。

上排是线性邻域插值，下排是棋盘邻域插值。

棋盘渲染实现：

渲染到1/4大小（1/2宽 x 1/2高）分辨率，使用MSAA 2X，最终得到全分辨率图像的一半样本。
D3D MSAA 2x标准模式：2个颜色和Z样本。
采样修饰符或SV_SampleIndex输入以强制渲染所有样本。
每个样本都落在全屏渲染目标的精确像素中心。

棋盘渲染额外的好处：粒子效果可以很容易地按像素而不是按样本进行评估，可以在ESRAM中获得更多的东西！无需在着色器中修正渐变。

通过在每一帧中再次偏移投影矩阵可以改变模式，并不总是可以在PC上更改样本的位置。

填补空白处：为了重建下图未知像素P和Q的颜色，采样当前帧直接邻域线性Z、当前帧直接相邻颜色、历史颜色与Z。

历史颜色/Z：选择一个邻居作为运动速度：离相机最*的一个，以保持轮廓，使用运动速度，对之前解析的颜色进行采样。这样可以使用过滤，但会引入累积误差！用B、E、F为Q夹紧重投影的颜色，使用之前从运动计算的深度，计算一个信赖的值，用于向未夹紧的值混合。解析颜色：已有历史颜色、直接邻域的插值颜色，使用两个附加的权重计算最终的颜色：A、B、E、F与Q之间的最小差值和速度的大小。

完整的流程图如下，解决相当复杂的问题，内容有很多调整！消耗1.4ms，减少了8到10ms。

TAA可以和棋盘渲染集成，可以在同一个resolve着色器上运行，在子样本级别上完成，MSAA 4X风格在棋盘格图案顶部抖动，重投影颜色权重使用类似的逻辑，额外的信息（Unteething）可用于删除不良的棋盘模式。

分辨率会在图像中引入明显的锯齿图案，应用过滤来消除它们，该过滤可在5个水*或垂直相邻的像素上工作，将阈值d和二进制像素分别设置为0或1，如果它们在[0, d]或[1-d, 1]范围内，我们检测到01010或10101模式。

Optimizing the Graphics Pipeline With Compute由DICE的Frostbite引擎团队成员呈现，使用计算着色器优化图形管线，更具体地说，如何通过不渲染那么多三角形来快速渲染三角形。文中涉及的各种概念如下表：

概念	全称	翻译
VGT	Vertex Grouper \ Tessellator	顶点分组器、曲面细分器
PA	Primitive Assembly	图元装配
CP	Command Processor	命令处理器
IA	Input Assembly	输入装配
SE	Shader Engine	着色器引擎
CU	Compute Unit	计算单元
LDS	Local Data Share	局部数据共享
HTILE	Hi-Z Depth Compression	层级深度压缩
GCN	Graphics Core Next	AMD的图形核心称号
SGPR	Scalar General-Purpose Register	标量通用寄存器
VGPR	Vector General-Purpose Register	向量通用寄存器
ALU	Arithmetic Logic Unit	算术逻辑单元
SPI	Shader Processor Interpolator	着色处理插值器

当时的Frostbite引擎面临绘制调用过多（1000+）、图元填充率过高等问题。解决的机会有：

在CPU上粗糙剔除，在GPU上精细剔除。
CPU和GPU之间的延迟会阻止优化。
GPU提交！
- 深度感知剔除。缩小阴影边界\样本分布阴影贴图，剔除没有贡献的阴影投射者，从颜色通道中剔除隐藏物体。
- VR的late-latch剔除。CPU提交保守的视锥体，GPU细化。
- 三角形与分簇剔除。
直接映射到图形管线。卸载外壳着色器工作，卸载整个细分管线！程序顶点动画（风、布料等），在多个过程和帧之间重用结果。
间接映射到图形管线。边界体积生成，预处理蒙皮，顶点动画（Blend Shape），从GPU生成GPU工作，场景和能见度测定。
将绘制当做数据！预构建，缓存和重用，在GPU上生成。

裁剪概览图：

左上：如图所示的场景，包含网格集合、特定视图、摄像机、灯等。右上：场景中的可配置网格子集，共享着色器和三角形带（顶点/索引）的批次内的网格，与DirectX 12 PSO的比例接*1:1（管线状态对象）。左下：代表一个索引的绘制调用（三角列表），有自己的顶点缓冲区、索引缓冲区、图元数量等。右下：波前处理的最佳三角形数，AMD GCN每个波前有64个线程，每个剔除线程处理1个三角形，工作项处理256个三角形。

剔除概览如下：

大致的过程和技术点包含将网格ID映射到多绘制ID、使用非交错顶点缓冲区、分簇剔除、绘制压缩、三角形剔除、朝向剔除、小图元剔除、视锥体剔除、深度剔除（深度分块、深度金字塔、HTILE、软光栅Z等）。

最终的剔除性能和效果如下：

The Rendering of INSIDE: Low Complexity, High Fidelity分享了当年爆火的一款解密探索类游戏Inside的渲染技术，包含用于实现大气外观的各种效果，例如局部阴影体积测量和强大的水渲染系统。通过对每个像素进行微调，将照明设计为完全独立的漫反射、镜面反射和反弹光实体，同时关注艺术家可接*的工具，意味着利用分析基于图元的环境光遮挡和屏幕空间反射。此外，还详细阐述如何通过适当使用抖动来消除分散注意力的瑕疵，避免艺术品的细微细节淹没在色带中。

Inside是一款暗黑解谜类游戏，可运行于安卓、ios等移动*台，是当年令笔者沉迷的一款游戏。笔者曾对它给予了很高的评价，有图为证：

该文涉及的内容比较多，包含雾与体积度量、HDR泛光、色带和抖动、投影贴花（定制照明、解析环境遮挡、屏幕空间反射）、水渲染、效果分解（吸引眼球）等。其中Inside使用了Light Prepass渲染，一帧概览如下：

雾原来是Inside艺术风格的核心，游戏中的许多初始场景实际上只是雾+剪影。以下是雾的组合效果：

从上到下：没有雾、线性雾、线性雾+发光。

作为大气散射的发光是非常宽的光晕，半个屏幕，向下采样，然后是多个模糊，因为只需要大范围的模糊。HDR发光是第二个发光通道，只对明亮发光的物体，遮罩对象的窄辉光仅发射材质（写入alpha通道）遮罩值将RGB重新映射为非线性强度，中间HDR值用\(x/(x+1)\)编码为[0:1]的定点数。

采样模式使用了发光过滤器[JIMENEZI4]，下采样时13个样本模糊，上采样时9个样本模糊。后处理设置步骤和流程如下：

接下来聊体积光照。

体积照明用raymarch的相机光线，阴影贴图投影空间中背景深度的步长，每一步计算光照贡献：采样阴影图、cookie、衰减等。

使用了逐像素3个抖动的样本，蓝色噪声提供了良好的采样，而在采样不足的区域，回到噪声中寻找失真可以获得更少的样本。

半分辨率用于低频效果，是上采样时的深度感知模糊。步骤如下：

清理前深度缓冲为零。
通道1，半分辨率。正面深度。
通道2，半分辨率。射线步进体积雾，输出光源强度（8位）+最大深度（24位）。
通道3，全分辨率。对半透明对象排序，深度感知解析、上采样和模糊。

通道3的具体过程如下：

另外，使用方差尺寸模糊、4样本、深度感知样本等影响TAA、下采样，让TAA随着时间的推移进行集成。以下是几种不同抖动方法的对比：

在基础颜色通道，存在非常明显的颜色条带（色阶）的瑕疵：

为了解决上述问题，分别对光照进行抖动、最终通道引入完全均匀的噪点、半透明未引入噪点但使用特殊的混合模式，解决方案在每个通道后都会抖动，手动将所有中间渲染目标转换为srgb（pow2，没什么特别的），在较低的分辨率下抖动（用于模糊）会导致大于1像素的噪声，但幸好结果却不可见。

抖动和噪点不仅仅可用于颜色，还可用于法线！！

在定制光照方面，新增了反弹光照、AO贴花、阴影贴花等效果。反弹光被用于全局照明，几乎只是一个普通的兰伯特点光源，除了没有使用香草点积，而是使用滑块使其褪色，它被称为lambert扭曲（lambert wrap）或半lambert（half lambert），提供方向性更小、更*滑的结果。

de14.png)

不同强度的反弹光。

因为它们不是静态的，所以经常用它们来打开窗户和移动手电筒。Inside没有使用常规方法（制作一系列点来覆盖走廊或一个数组来填充房间），而是使用完整的变换矩阵，以获得非均匀的形状，更适合使用拉伸的药片和压扁按钮的盒子，而且更低开销，因为过绘制和重叠更少。

文中还涉及了AO贴花和阴影贴图。

从上到下：点AO、球体AO、盒子AO效果及实现方法。

从上到下：无阴影贴花、有阴影贴花、阴影贴花可视化。

对于SSR，采用了特殊的屏幕空间追踪方式：

从左到右：屏幕空间向上发射射线、让射线移动到包围盒最*的水*出口、继续向上追踪。

// SSR方向计算（常规版）
// GPU的片元着色器
sDirProj = mul(projection, vec4(vDir + vPos, 1.0));
SDir = normalize(sDirProj.xyz / sDirProj.w - sPos);

// SSR方向计算（改进版）
// CPU计算投影空间的方向，并设置成uniform变量
_DirProject = vec(viewportSize, nearClip / (nearClip - fraClip));
// GPU的片元着色器
sDir = vec3(vDir.xy - vRay.xy * vDir.z, vDir.z * rcpDepth) * _DirProject;

为了避免阶梯式瑕疵，使用了随机采样（蓝色噪点 + TRAA）。

水体（水面和水下）使用了分层渲染，包含体积雾、半透明、折射、反射等效果：

水面的分层组合后的效果。

水下也和水面一样，具有相同的分层渲染，还增加位移边缘、外部或正面面、内部或背面面等层：

Inside的特效方也非常讲究，使用了很多技术和优化技巧。

在世界空间中将粒子纹理投射到粒子上，每个粒子上都有一个随机偏移，并向一个方向滚动。图中示例是向下的，因为是从盒子里出来的方向。

镜头眩光的采样方式。

各种水面效果的模拟。

Temporal Reprojection Anti-Aliasing in INSIDE也涉及了Inside，但专注点在TAA的应用和优化。

首先是一些基本的直觉，表面片元的局部区域可以在多个帧中保持可见，若观察者和被摄体之间的关系每一帧都发生变化，那个么光栅化也会发生变化，如果在时间上后退一步，那么可以使用这种变化来优化当前帧。

要将当前帧片段与前一帧的片元关联起来，可以在空间上进行，并进行重投影，依赖深度缓冲区信息，仅限于最接*的表面片元，但不总是可行，有时候数据根本就不存在。片元在任何时候都可能被遮挡或不被遮挡，因此很难准确后退，如果观看者和被摄者之间的关系从未改变，那么退一步就不会获得额外的信息…

第一步：抖动视锥。已经确定如果摄像机是静态的，然后就失去了信息，因此，渲染前的每一帧：从样本分布中获取texel偏移量，使用“偏移”计算投影偏移，使用“投影偏移”剪切*截头体。

第二步：对于每一个片元执行以下步骤：

静态场景的重投影：

从当前片段p_uv开始。
使用当前帧的深度和*截体参数重建世界空间p，lerp角射线，按线性深度缩放。
将p重新投射到前一帧中：q_cs = mul(VP_prev’, p)，q_uv = 0.5 * ( q_cs.xy / q_cs.w ) + 0.5。
采样历史：c_hist = sample( buf_history, q_uv。

动态场景的重投影：

对于动态场景，需要一个速度缓冲区
- 在处理TAA之前需要专门的pass。
- 使用静态重投影初始化摄像机运动：v = p_uv - q_uv。
- 在顶部渲染动态对象：v = compute_ssvel(p, q, VP, VP_prev’)。
重投影步骤变为读取和减法：v = sample(buf_velocity, p_uv)，q_uv = p_uv - v。

在TAA过程还需要处理重投影与边缘运动、约束历史样本、邻域夹紧等细节，最终融合，用约束的历史加权。

Inside的TAA 2.0将运动模糊添加到混合中：

带运动模糊回退的最终混合步骤：

像以前一样更新历史缓冲区：rt _history = c _feedback。
对于输出目标，与运动模糊输入混合。
- c _motion = sample_motion ( buf _color , unjitter( p _uv ), v)
- rt _output = lerp( c _motion , c _feedback , k_trust)
- k_trust = invlerp( 15, 2, |v| )
强制过渡到运动模糊（无历史记录！）寻找快速移动的片元。

关于选择一个好的样本分布，大量的尝试和错误，采取了实用的方法，头部靠*屏幕，放大高对比度区域，希望在收敛的质量和速度之间找到良好的*衡，启发式：侧滚游戏。

测试的一些序列：

实现总结：用halton(2, 3)的前16个样本抖动视锥，生成速度缓冲，摄像头运动+动态（手动标记），基于最*的（深度）片元的速度重投影，使用中心剪辑到RGB最小最大圆形3x3区域的邻域夹紧，运动模糊回退，当||v||大于2时生效，15时完全生效，但不适用于历史。

Temporal Antialiasing In Uncharted 4也分享了神秘海域4的时间抗锯齿。本文的焦点在于提供更详细的实现细节。

对于静态图片，设置输入和输出，运行全屏幕着色器，在历史和当前渲染纹理之间插值：

float3 currColor = currBuffer.Load(pos);
float3 historyColor = historyBuffer.Load(pos);
return lerp(historyColor, currColor, 0.05f);

对于运动图像，不能在同一位置采样历史缓冲区，找出上一帧中当前帧像素的位置（如果有），需要处理屏幕外的像素和被遮挡的像素。需要先在GBuffer通道中生成全屏运动向量缓冲区（fp rg16）：

// GBuffer VS
posProj = posObj * matWvp;
posLastProj = posLastObj * matLastWvp;

// GBuffer PS
posNdc -= g_projOffset;
posLastNdc -= g_projOffsetLast;
float2 motionVector = (posLastNdc - posNdc) * float2(0.5f, -0.5f);

对于程序化的动画对象（植物、毛发、水顶点运动等），需要对当前帧和最后帧执行两次，需要确定性，输入最后一帧的时间，产生完全相同的顶点位置，在纹理上滚动uv，即在表面uv空间（deltaU，deltaV）中滚动会导致屏幕空间（deltaX，deltaY）发生多少变化：

deltaU = ddx(U) * deltaX + ddy(U) * deltaY;
deltaV = ddx(V) * deltaX + ddy(V) * deltaY;

已解析的deltaX和deltaY以屏幕像素为单位，将它们转换为运动向量单位。对于反射，无法使用镜像的运动矢量，因为镜像像素在上一帧中通常反射不相同的东西。这个问题不难，但涉及很多步骤，仅适应于*面反射。一切都应该有运动矢量，但还有一些不受支持的：复杂纹理动画，如粒子烟、水流、云运动等；透明对象，如艺术家控制运动矢量不透明度。为什么不在TAA之后绘制呢？绘图顺序并不总是允许，任何跳过TAA的东西都会抖动，删除抖动还不够，因为使用了抖动深度缓冲进行测试。在TAA之后摆脱了问题：雨滴，弹痕，火花…除此之外，没有其它东西摆脱，一旦使用了TAA，就得一路走下去。将运动矢量缓冲区作为输入添加到TAA，使用运动矢量采样历史缓冲区：

float2 uvLast = uv + motionVectorBuffer.Sample(point, uv);
float3 historyColor = historyBuffer.Sample(linear, uvLast);

使用线性采样器的重要事项：点采样可能会落在不相关的像素上，线性采样不会完全丢失，但会导致模糊（稍后讨论）。

历史和当前颜色可能不匹配，由于遮挡/屏幕外而不存在、灯光变化、在边缘的不同侧面（投影抖动）等。需要夹紧历史颜色，使用Dust 514的夹紧方法，以当前帧像素为中心采样3x3邻域，计算每个rgb通道的最小/最大邻域：

float3 neighborMin, neighborMax;
// calculate neighborMin, neighborMax by
// iterating through 9 pixels in neighborhood
historyColor = clamp(historyColor, neighborMin, neighborMax);

对于不存在和灯光变化的情况，夹紧掉太不相同的历史颜色，3x3邻域确保夹紧不会影响边缘AA，对于边缘像素，边缘另一侧的历史不会被夹紧。是时候再次混合历史和当前颜色，这一次支持运动图像：

return lerp(historyColor, currColor, blendFactor /*0.05f*/);

需要动态的blendFactor来*衡模糊和抖动。基于UE4方法：局部对比度较低时增加，当像素运动达到亚像素时减少，当历史接*夹紧时减少，结果还是有点模糊。为了解决模糊，需要一个全屏幕通道使用以下的邻域权重进行处理：

\[\begin{vmatrix} 0 & -1 & 0\\ -1 & 4 & -1\\ 0 & -1 & 0 \end{vmatrix} \]

return saturate(center + 4*center - up - down - left - right);

TAA仍然存在一个问题：鬼影，夹紧应该可以防止它，但在某些领域似乎不起作用。鬼影发生的原因是包含高频和高强度的颜色变化，如多棱茂密的草、黑暗中被强光照亮的凹凸不*的表面。邻域最小/最大值变得巨大，使夹紧失效：

historyColor = clamp(historyColor, neighborMin, neighborMax);

// 将上面的原有代码改成以下代码
uint currStencil = stencilBuffer.Sample(point, uv);
uint lastStencil = lastStencilBuffer.Sample(point, uvLast);
blendFactor = (lastStencil & 0x18) == (currStencil & 0x18) ? blendFactor : 1.f;

鬼影消失了，但新显示的像素看起来格外锐利和锯齿：

当blendFactor为1时返回高斯模糊颜色：

blendFactor = (lastStencil & 0x18) == (currStencil & 0x18) ? blendFactor : 1.0f;

float3 blurredCurrColor;
// Gaussian blur currColor with 3x3 neighborhood 
if (blendFactor == 1.0f)
    return blurredCurrColor;

其中高斯权重如下：

\[\begin{vmatrix} \cfrac{1}{16} & \cfrac{1}{8} & \cfrac{1}{16}\\ \cfrac{1}{8} & \cfrac{1}{4} & \cfrac{1}{8}\\ \cfrac{1}{16} & \cfrac{1}{8} & \cfrac{1}{16} \end{vmatrix} \]

在模板修复后，仍然有1像素厚的鬼影：

颜色历史是线性采样的，而模板历史是点采样的，边缘不匹配，解决方案是使模板缓冲区中的对象轮廓扩大1个像素。使用当前帧深度和模板缓冲作为输入创建全屏着色器，每个像素（p）将其深度与4个邻域像素（左上、右上、左下、右下）进行比较，忽视其它邻域像素。输出最接*深度的像素模板，将扩大的模板缓冲区添加到TAA输入，上一帧的模板应来自扩大版本，使用扩大版本进行模板测试，边缘检测使用未扩大版本。修复了模板标记对象边缘周围的轻微抖动，避免给草之类的东西标记，手动标记的一个原因，运动模糊也会隐藏鬼影。

对于屏幕外的像素，像素历史记录可能在上一帧离开屏幕，在着色器中检测并将blendFactor设置为1，与新发现的情况一致：没有历史，使用高斯模糊的当前颜色。

在1080p的PS4 GPU上，主着色器低于0.8ms，许多其它相关成本：运动矢量计算、锐化着色器（0.15毫秒）、扩大模板着色器（0.4ms）。TAA的其它收益：每像素采集多个样本的图形功能，将计算扩展到多个帧，使用TAA进行合并，将显示一个样本，但在多个样本中使用。

该文还谈及了将TAA用于RSM（Reflective Shadow Map，反射阴影图）的思想。将场景从手电筒透视渲染到256x256缓冲区，每个像素都被视为一个VPL（虚拟点光源），运行全屏着色器，其中每个像素由所有（65536）VPL照亮，但算法复杂度是O(n*m)，成本太高了！神秘海域4将VPL缓冲区下采样至16x16，1/4宽x 1/4高的全屏着色器，但由此产生的结果过于模糊和模糊，VPL（256）不足导致失真。需要一个不那么暴力的解决方案，渲染分辨率无法承担，每像素随机采样16个VPL，相邻像素采样不同的16个VPL，每个64x64屏幕空间tile可以覆盖所有64k的VPL。使用PBR手册中描述的低差异序列，确保64x64的tile中没有两个像素使用相同的VPL，在64k中采样16次具有巨大的差异，导致严重的噪点。因此可引入时间采样，每个像素每帧采样不同的16个VPL，实际上有超过16个VPL，TAA将帧收敛到稳定图像，最佳部分–无需更改TAA着色器。

TAA还可用于屏幕空间反射、阴影模糊、屏幕空间环境遮挡、*相机透明度、LOD转换、一些头发透明。未解决的问题：不受支持的运动矢量，一些颗粒/水在没有TAA的情况下看起来更好；下采样和模糊不友好，无法让SSR在半分辨率内工作；TAA在较高的帧速率下工作得更好，收敛速度更快，瑕疵不那么明显。

Mixed Resolution Rendering in 'Skylanders: SuperChargers'讲述了游戏Skylanders: SuperChargers所使用的混合分辨率渲染的技术。首次尝试使用了单通道的混合分辨率，场景深度被下采样，然后根据低分辨率缓冲区进行光栅化，使用双边上采样对低分辨率渲染进行上采样，然后最终合成到场景缓冲区。

双边上采样的代码：

float4 vBilinearWeights = GetBilinearweights(vTexcoord); 

float4 vSampleDepths = GetLowResolutionDepths(vrexcoord); 
float vPixelDepth = GetHighResolutionDepth(vTexcoord); 
float4 vDepthWeights = GetDepthsimilarity( vPixelDepth, vSampleDepths); 

return vDepthWeights * vBilinearWeights;

深度下采样时把最小值和最大值结合起来，因为它们处理的像素几乎是互斥的。事实证明，简单的事情有时也能奏效，只需在棋盘模式中交替使用最小值和最大值，这将为整个4x4像素块提供良好的深度表示。

Texture2D SourceDepthTexture;
SamplerState PointSampler;

float main(float2 vTexcoord : TEXCOORD0, float2 vWindowPos : SV_Position) : SV_Target
{
    // Gather the 4 depth taps from the high resolution texture that cover this texel SourceDepthTexture. 
    float4 fDepthTaps = GatherRed(PointSampler, vTexcoord, 0);
    
    // Identify the min and max depth out of the 4 taps  
    // NOTE:  It doesn't matter if your depth is negative or positive here  
    float fMaxDepth = max4( fDepthTaps.x, fDepthTaps.y, fDepthTaps.z, fDepthTaps.w);
    float fMinDepth = min4( fDepthTaps.x, fDepthTaps.y, fDepthTaps.z, fDepthTaps.w);
    
    // Classify the low resolution texel as either a max texel or min texel based on the window pos  
    return checkerboard( vWindowPos) > 0.5f ? fMaxDepth : fMinDepth;
}

由此产生的深度缓冲将高频深度不连续转化为棋盘格图案，正如从下图的拱门下的草叶中看到的那样。因此，需要一种评估它们的方法。

几种不同的深度下采样方法的像素误差值如下，可知min/max 方法误差最小：

原始参考和min/max的渲染对比：

双边上采样的模式如下：

然而第二次尝试有时结果看起来比决心更糟糕，样本是否有问题？是否使用点采样更佳？事实证明，在某些情况下，当将结果与一个简单的线性滤波进行比较时，如果没有深度权重，结果会出现一些奇怪的伪影，就可以判断出发生了什么。那么为什么会发生下图这种情况（双边过滤明显的锯齿）呢？这与双边上采样以及如何计算深度相似性有关。

深度相似度一般由下面的代码计算：

float4 GetDepthSimilarity( float fCenterDepth, float4 vSampleDepths)
{
    // fThreshold控制着深度相似度的强度
    loat fScale = 1.0f / fThreshold; 
    float4 vDepthDifferences = abs(vSampleDepths - fCenterDepth); 
    return min(1.0f / (fScale * vDepthDifferences + fEpsilon) , 1.0f);
}

通常，通过确定高分辨率和低分辨率像素的深度差来计算深度相似性。该数字与阈值（fThreshold）一起用于确定深度是否相似。所以，如果选择一个小的阈值，最终会检测到假边缘（下图左）。类似地，如果阈值太大，则会丢失靠*的边（下图右）。

这是因为对双边加权使用了固定的深度偏差值。问题在于，随着表面逐渐退到屏幕中，单个像素步所代表的单位数增加了。因此，应该根据深度设置阈值。

文中改成使用*面被推回进场景的模型作为确定阈值的基础。给出单个像素的角度差和*面的斜率作为输入，以确保在前面保持线性混合。从而变成了一个简单的三角问题，可以得到结果，此外，还缩放该值以补偿这样一个事实——下采样时深度值可能来自2个像素之外。

改进后的阈值的效果和采样结果如下两图：

但是，下面是使用目标坡度阈值前后另一个问题的示例，图左所示得到的是水*过滤，而不是垂直过滤。

因此，第三次尝试有些影响看起来仍然很糟糕，有很多锯齿，透明模型更糟糕。为了减少边缘锯齿，采用了双通道方法方法：

对深度和颜色的边缘的检测采样了以下方法：

部分上采样步骤：

第1个Pass：
- 裁减边缘。
- 在通道中设置模板位。
第2个Pass：
- 配置高分辨率模板（hi-stencil）。
- 绘制全屏矩形以重新加载高分辨率模板。

第四次尝试得到的效果达到了发布水*，在360上运行的性能如下：

由于在游戏中使用了抖动衰减，在下图可以看到最小/最大缓冲区清楚地保持了正在淡出的树的抖动特性。

优势是有助于游戏的内容，屏幕外的渲染目标非常有用，性能可扩展。劣势是预乘的渲染目标，有限的混合模式，依赖高分辨率模板，最坏情况下的成本更高，高开销。

How we rethought driver abstraction谈及了如何更好地抽象和封装图形API。文中的抽象最初是基于DX9的轻量层，更新后与DX10匹配，抽象方法/调用，不是渲染过程本身。旧的渲染管线如下：

工作项（work item）是描述单个渲染工作所需的最少数据，如输入、输出、程序等，尽可能通用，不一定是GPU工作，完全独立。

资源可以是任何东西，是客户端代码的黑盒，可以在不同*台甚至不同运行有不同的实现，可能有实例，生命周期长，不一定存在于整个生命周期的内存中，资源的典型代表是纹理、着色器、模型等。实例是一种资源，是临时的，在客户端代码是黑盒，由与资源相同的代码处理，例如在当前帧中渲染的模型实例。句柄有设置（colour_handle, colour::red）、获取（colour_handle）等接口，在内部句柄是实例内存的偏移量，客户端访问资源和实例的唯一方法，如果给定实例或资源没有请求的参数，则为NOP，调试中有类型检测。

新的管线如下，增加了资源管理器，隔离开高级和低级渲染层，从而达到更好的解耦，并获得优化的机会：

总之，尽可能多地为底层代码提供上下文，不要在高层做出任何假设，保留所有选项，在不影响性能的情况下，不要害怕概括和抽象事物，API上的轻量级封装不再是最佳选择。

From Pixels to Reality – Thoughts on Next Game Engine谈及了2016年的游戏引擎的现状以及未来的趋势。2016年，主流游戏引擎的特点是多线程、多*台、现代图形API、延迟渲染、PBR、全局照明、动态环境及60FPS@1080P，当时不够好的点有锯齿、阴影、透明度、动画、加载时间、性能、内容制作等，新兴的技术包含基于社区的游戏、用户创建内容、移动端、VR/AR、电子竞技、广播等。电影和游戏的区别见下表：

电影	游戏
Reyes/Ray Tracing	Direct 3D / OpenGL
物体空间着色	屏幕空间着色
大量可见性样本	少量可见性样本
照片级质量	吞吐量

在当时，REYES/Ray Tracing用于游戏的时机还不够成熟，因为基于GPU的REYES面临小三角形、场景复杂度、不够快等问题，而实时光追面临分辨率、多显示器、不够快等问题。更好的方法是借鉴和结合的思想。对象空间中的阴影=固有稳定，将可见性采样与着色分离=多速率，可见性缓冲区=减少内存和带宽。可能的渲染管线如下：

多速率可进一步地扩展到可见性样本、着色样本、照明样品、物理、人工智能、输入、光源传输更新等。在锯齿方面，镜面锯齿可用Lean Mapping[OlanoBaker 2010]，阴影锯齿可用Frustum Traced Raster Shadows[WymanHoeltzleinLefohn15]，半透明可用OIT。加载时间可用比zlib好2倍的压缩技术、程序化合成的Substance、Wang Tiles [Wang61] [Stam97] [Liyi04]。

云可支持巨大的世界、成千上万的玩家、微型客户端、内容制作、盒子里的工作室。亚马逊的云渲染GameLift架构图如下：

2018年的游戏引擎几乎没有锯齿、正确的空间、正确的频率、正确的位置、感知引导的“重要性”、程序化内容、云连接等。研究热点有程序化合成、压缩、三维扫描、感知科学、多速率渲染、动画、分布式的物理/人工智能/渲染等。

Building a Low-Fragmentation Memory System for 64-bit Games分享了游戏内的低碎片化的内存管理系统。旧的内存系统从PS3中移植而来，具有固定大小的内存池，模拟VRAM。存在的问题是浪费了很多内存，每个内存池都能应付最坏的情况，小型分配的开销，碎片化，无法支持纹理流。内存碎片是在小的非连续块中碎片化的堆，即使内存足够，分配也可能失败，由混合分配生命周期引起。

设计目标是低碎片、高利用率、简单配置、支持PlayStation®4操作系统和PC、支持高效的纹理流、全面的调试支持。

虚拟内存是在进程使用虚拟地址，是映射到物理地址的虚拟地址，CPU查找物理地址，需要操作系统和硬件支持。

虚拟内存可以减少内存碎片，碎片就是地址碎片，使用虚拟地址，虚拟地址空间大于物理地址空间，连续的虚拟内存在物理内存中不连续。内存页（Memory Page）在页面中映射，x64支持4kB和2MB页面，PlayStation4操作系统使用16kB（4x4kB）和2MB，GPU有更多的尺寸。2MB页面最快，16kB页面占用的内存更少，文中使用64kB（4x16kB页面），64kB是PlayStation 4 GPU的最小最佳尺寸，特殊情况也使用16kB。

洋葱总线（Onion Bus）和大蒜总线（Garlic Bus）都可以倍CPU和GPU访问，但它们的带宽不同，洋葱=快速CPU访问，大蒜=快速GPU访问。

文中的内存系统分割整个虚拟地址空间，按需映射物理内存，分配器模块管理自己的空间，每个模块都是专门的，分配器对象是系统的接口。

class Allocator
{
public:
    virtual void* Allocate(size_t size, size_t align) = 0;
    virtual void Deallocate(void* pMemory) = 0;
    virtual size_t GetSize(void* pMemory) { return 0; }
    
    const char* GetName(void) const;
};

// 示例
void* GeneralAllocator::Allocate(size_t size, size_t align)
{
    if (SmallAllocator::Belongs(size, align))
        return SmallAllocator::Allocate(size, align);
    else if (m_mediumAllocator.Belongs(size, align))
        return m_mediumAllocator.Allocate(size, align);
    else if (LargeAllocator::Belongs(size, align))
        return LargeAllocator::Allocate(size, m_mappingFlags);
    else if (GiantAllocator::Belongs(size, align))
        return GiantAllocator::Allocate(size, m_mappingFlags);
    
    return nullptr;
}

虚拟地址空间：

小型分配模块：大多数分配小于等于64字节，约25万个分配，约25M。打包以防止碎片，大小相同的16kB页面，没有头信息。

小型分配模块的利弊，+轻量实现，+非常低的浪费，+利用灵活的内存，+快速，-难以检测的内存瓶颈。

大型分配模块保留巨大的虚拟地址空间（160GB），每个表被分成大小相等的插槽，按需映射和取消映射64kB页面，保证连续内存。

纹理流预留大的分配槽，四舍五入到最*的2的N次方，加载最小mip和64kB的最大值，按需映射和取消映射页面，无需复制或整理碎片。大型分配模块的利弊，+没有头信息，+简单的实现（大约200行代码），+没有碎片，-大小四舍五入到页面大小，-映射和取消映射内核调用相对较慢。

中型分配模块应对中等尺寸的分配，无头信息，除了大型和小型之外其它尺寸都在这里分配，非连续虚拟页，增长和收缩，传统的带头信息的双链表，不适合大蒜（GPU）的内存（与数据一起存储的头），Pow2自由列表。

无头分配模块（Headerless Allocation Module）用于GPU分配，中小型分配，哈希表查找。

分配器类型包含GeneralAllocator、VramAllocator、MappedAllocator、GpuScratchAllocator、FrameAllocator等。GPU暂存分配器（GpuScratchAllocator）是渲染器用于每帧分配，双缓冲，不需要释放分配，受原子保护。GpuScratchAllocator的优缺点：+没有头或账单，+没有碎片，+快速，-固定尺寸，-最糟糕的情况是对齐浪费空间。帧分配器（FrameAllocator），帧被推入和弹出，不需要释放内存，每个线程都是唯一的，适用于临时工作缓冲区。

#include 

struct Elem
{
    …
};
    
void ProcessElements(size_t numElements)
{
    ls::ScratchMem frame;
    Elem* pElements = (Elem*)MM_ALLOC_P(&frame, sizeof(Elem) * numElements);
}

FrameAllocator的优缺点：+没有头或账单，+没有碎片，+没有同步，+快速，-小心指针传递！

线程安全：最低级别的互斥体，分配器实例不受保护，帧分配器没有锁，又好又简单。

性能不是重点，但仍然很重要，映射/取消映射速度慢，没有明显的区别，游戏期间不要太多分配，文件加载是一个瓶颈。内存的清理值有以下几种（memset的字节值，保持可读可记）：

0xFA: Flexible memory allocated
0xFF: Flexible memory free
0xDA: Direct memory allocated
0xDF: Direction memoryfree
0xA1: Memory allocated
0xDE: Memory deallocated

统计信息，追踪一切可能的事情，实时图表可用，通过自动测试记录。内存头保护，中型分配头中的空闲字节，检测内存瓶颈，但往往为时已晚。内存块哨兵，绕过正常分配器，每个分配都在自己的页面中，前后未映射的页面，写得太多/太少时崩溃。

总结：现代控制台具有丰富的虚拟内存支持，虚拟内存提供了许多选项，围绕分配模式设计内存系统，分析很重要，小型分配是一个良好的开端，模块化分配器使定制变得容易！调试功能非常重要！

The devil is in the details: idTech 666讲述了idTech引擎的渲染管线的渲染技术和性能优化。当时的idTech的渲染管线流程和性能数据如下：

其分簇光照系统衍生自“Clustered Deferred and Forward Shading” [Olson12]和“Practical Clustered Shading” [Person13]，可工作于透明表面，不需要额外的通道或工作，独立于深度缓冲区，深度不连续处无误报。分簇光照步骤如下：

体素化/光栅化处理。在CPU上完成，每个深度片1个作业。
对数深度分布。扩大**面和远*面：\(\text{ZSlice}=\text{Near}_z\times \Big(\cfrac{\text{Far}_z}{\text{Near}_z}\Big)^\frac{\text{slice}}{\text{numSlices}}\)。
对每个项目进行体素化，项目可以是灯光、环境探针或贴花，项目形状是OBB或*截体（投影者），由屏幕空间\(\min_{xy}\)、\(\max_{xy}\)和深度边界的光栅化来界定。
在剪辑空间中进行细化。剪辑空间中的单元格是AABB，N个*面和单元格AABB，OBB是6个*面，*截体是5个*面，所有体积的代码都相同，使用SIMD。
```
//Pseudo-code - 1 job per depth slice ( if any item )
for (y=MinY; y
```

 
  细节化世界的技术：虚拟纹理更新；反照率、镜面反射、*滑度、法线、HDR光照贴图，硬件sRGB支持，将Toksvig烘焙成*滑度，用于镜面抗锯齿；直接将UAV输出回读至最终分辨率；异步计算转码，成本几乎无关紧要；设计缺陷依然存在，例如反应性纹理流=纹理弹出；嵌入几何栅格化的贴花；实时替换到Mega纹理的压印（Stamping），更快的工作流程/更少的磁盘存储；法线贴图混合、所有通道的线性正确混合、mipmap/各向异性、透明度、排序、0个绘制调用、使用BC7的8k x 8k贴花图集；还有盒子投影、索引到贴花图集，由艺术家手工放置，包括混合设置，“混合层”的推广；每个视锥视图限制为4k，通常1k或更少可见；LOD化，艺术设置最大视距，玩家质量设置也会影响观看距离；研究动态不可变形几何体，将对象变换应用于贴花。 
  在光照方面，使用单一/统一照明代码路径，对于不透明通道、延迟、透明和解耦粒子照明，没有着色器排列，现在静态/连贯分支非常好——尽情使用它！对所有静态几何体使用相同的着色器，减少上下文切换。光照组件包含：漫反射间接照明——用于静态几何体的光照贴图，用于动态的辐照度体积，镜面间接照明——反射（环境探针、SSR、镜面遮挡），用于动态的灯光和阴影。 
  // Pseudocode
ComputeLighting( inputs, outputs ) 
{
    Read & Pack base textures

    for each decal in cell 
    {
        early out fragment check
        Read textures
        Blend results
    }
    
    for each light in cell 
    {
        early out fragment check
        Compute BRDF / Apply Shadows
        Accumulate lighting
    }
}
 
  阴影被缓存/打包到图集中，PC用32位的8k x 8k的图集（高规格），控制台用16位的8k x 4k，基于距离的可变分辨率，时间切片也基于距离，静态几何优化网格。如果光源不移动，缓存静态几何体阴影贴图，如果frustum内部没有更新则跳过，如果没有更新，用缓存结果组合动态几何体，仍然可以使用动画（例如闪烁），艺术设置/质量设置会影响以上所有内容。索引到阴影截锥投影矩阵，所有灯光类型的PCF查找代码相同，减少VGPR压力，包括*行光级联，级联之间使用抖动，单级级联查找，尝试VSM及其导数，有一些瑕疵，从概念上讲，对前向渲染有很好的发展潜力，例如将过滤频率与光栅化分离。 
  光照时，注意VGPR压力，打包寿命长的数据，例如float4表示HDR颜色 <--> RGBE编码的uint，最小化寄存器生命周期，最小化嵌套循环/最坏情况路径，最小化分支，控制台上56个VGRS（PS4），由于编译器效率低下，在PC上更高（@AMD编译器团队，漂亮的plz修复程序-抛出性能）。未来使用半精度支持将有所帮助，Nvidia：使用UBOs/常量缓冲区（所需的分区缓冲区=更多/丑陋的代码），AMD：优先SSBO/UAV。 
  粗糙玻璃*似：最高mip为半分辨率，总共4个mip，高斯核（*似GGX瓣），基于表面*滑度的混合mips，折射传输限制为每帧2次，以提高性能，通过贴花实现表面参数化/变化。 
   
  对于后处理，通过以下方法优化了数据读取：非分歧运算的GCN标量单位，非常适合加速数据获取，节省VGRP，一致性分支，指令更少（SMEM:64字节，VMEM:16字节）。分簇着色用例，每个像素从其所属单元获取灯光/贴花，本质上是不同的，但值得分析。 
   
  大多数wavefront只能进入一个cell，附*的cell共享大部分内容，线程主要获取相同的数据。每线程单元数据获取不是最优的，不利用这种数据融合。合并单元格内容上可能的标量迭代，不要让所有线程独立地获取完全相同的数据。 
  利用访问模式：对于数据，每个单元格的项目（灯光/贴花）ID排序数组，同样的结构适用于灯光和贴花处理，每个线程可能访问不同的节点，每个线程在这些数组上独立迭代。标量加载用序列化迭代，计算所有线程中的最小项目ID值，ds_swizzle_b32/小型位置不一致，与所选索引匹配的线程的进程项，统一索引->标量指令，匹配的线程移动到下一个索引。 
   
  特殊路径：如果只接触一个单元格，则为快速路径，避免计算最小的物品ID，在GCN1和2上不便宜，一些额外的（次要的）标量获取和操作，序列化假定线程之间存在局部性，如果接触过多的单元格，速度会明显减慢，禁用粒子照明图集生成。 
  动态分辨率缩放：基于GPU负载的自适应分辨率，PS4上的比例大多为100%，Xbox上的比例更大，在同一目标中渲染，调整视口大小
 侵入式：需要额外的着色器代码，OpenGL上的唯一选项。未来：重叠多个渲染目标，可能在控制台和Vulkan上，TAA可以收集不同分辨率的样本，异步计算中的上采样。 
  异步后处理：阴影和深度过程几乎不使用计算单位，固定的图形管线繁重。不透明通道也不是100%忙，可以与后处理重叠，在特效队列上的预乘Alpha的缓冲区中渲染GUI，计算队列上处理后处理/AA/upsample/compose UI，与第N+1帧的阴影/深度/不透明重叠，从计算队列中显示（如果可用），潜在更低的延迟。 
  此外，文中还涉及了GCN架构上的特定优化。未来的工作是解构频率的消耗以获得收益，改进纹理质量、全局照明、整体细节、工作流程等。 
   
  [Top five technologies to watch: 2017 to 2021](Top five technologies to watch: 2017 to 2021Top five technologies to watch%3A 2017 to,commonplace%2C while VR will remains niche. More)阐述了2017到2021的技术趋势和新兴的技术。五项技术将帮助我们获得洞察力： 
   
  最重要的是人工智能与认知技术。以下五大技术支持快速互联： 
   
  包含移动边缘计算、cloudlets、fog计算、工业互联网、SDN和OpenNFV。Edge computing将全面帮助人们，但需要更高层次的技术。 
  The Latest Graphics Technology in Remedy's Northlight Engine讨论了Remedy的Northlight引擎中渲染技术的引擎内实现和一些最新进展的结果，包含DirectX光线追踪、区域阴影、环境遮挡、反射、间接漫反射等。 
  实时光线追踪中的基于可见性的算法图例如下： 
   
  在AO上，SSAO和光追AO的对比如下： 
   
  而光追AO在不同的rpp上，效果也有所不同： 
   
  反射上，SSR和光追反射也有明显的区别： 
   
  对于间接漫反射，与AO类似，许多非相干光线，GI存储在稀疏网格体积中。基于静态几何图形和静态灯光集计算的辐照度，动态几何体可以接收光，但不影响计算的辐照度，动态几何没有贡献，三线性采样创建阶梯样式，薄几何体会导致光照泄漏，通过采样余弦分布上的辐射来收集照明，考虑丢失的几何图形。 
   
  我们还可以在几何体交点上采样照明，最终的光追各分量和组合效果如下： 
   
   
  总之，通过DXR轻松访问最先进的GPU光线跟踪，性能正在达到目标，易于不适合光栅化的原型化算法，可与现有低频结构相结合。 
   
  Advanced Graphics Techniques Tutorial: GPU-Based Clay Simulation and Ray-Tracing Tech in 'Claybook'阐述了Second Order公司的第一款游戏《Claybook》包含了大量创新技术，包括基于GPU的粘土和流体模拟器、完全可变形的世界和角色、有向距离场建模和光线跟踪视觉效果。并讨论这项技术的产生、优化和技巧才能在当前一代游戏机上用游戏的光线跟踪视觉效果和模拟达到60 fps，以及他们的非标准渲染器和模拟技术是如何集成在虚幻引擎4之上的。 
  有向距离场（SDF）：SDF(P)=到P处最*表面的有符号距离，有解析距离函数和体积纹理两种形式。解析距离函数在场景demo中流行，巨大的着色器，很多数学知识，没有数据。体积纹理存储距离函数，三线性滤波器，Claybook将体积纹理与mip贴图结合使用。Claybook的世界SDF的分辨率=1024x1024x512，格式=8位有符号，大小=586 MB（5 mip级别），[-4，+4]体素的距离，256个值/8个体素，1/32体素精度，每mip级别最大步进（世界空间）翻倍。 
  在GPU上生成世界SDF的步骤： 
   
    生成SDF笔刷网格。64x64x32的dispatch，4x4x4的线程组。 
     
     在分块中心T处采样刷子体积。如果SDF>光栅分块边界+4个体素，则剔除。如果接受，原子添加+存储到GSM。 
     通过GSM中的笔刷循环。细胞中心C处的样本[i]，如果接受，存储到网格（线性），局部+全局原子压缩。 
    
  
    生成调度坐标。64x64x32的调度，4x4x4的线程组。 
     
     读取刷子网格单元。 
     如果不是空的：原子加法（L+G）得到写索引，将单元格坐标写入缓冲区。 
    
  
    生成Mip掩码。4x调度（mips），4x4x4的线程组。 
     
     分组：加载1个更宽的体素网格L-1邻域，下采样1=0掩码并存储到GSM。 
     将掩码放大1个体素（3x3x3）。 
     掩码=0则写入网格单元坐标。 
     
    在8x8x8的tile中生成0级（稀疏）。间接调度，8x8的线程组。 
     
     分组：读取网格单元坐标（SV_GroupId）。 
     从网格读取笔刷并存储到GSM。 
     通过GSM中的笔刷循环，采样[i]，执行exp*滑最小/最大操作。 
     将体素写入WorldSDF的级别0。 
     
    生成mips（稀疏）。4倍间接调度（mips），8x8的线程组。 
     
     分组：加载更宽的L-1邻域的4个体素。2x2x2下采样（*均值）并在GSM中存储为\(12^3\)，+-4体素带变成+-2体素阶（band）。 
     分组：在GSM中运行3步eikonal方程（下图），扩展阶：2个体素变成4个体素。 
     存储8x8x8邻域的中心。 
     
   
    
   
  球体追踪算法： 
   
   D = SDF(P)。 
   P += ray * D。 
   if (D < epsilon) break。 
   
   
  多层体纹理跟踪： 
  Loop
    D = volume.SampleLevel(origin + ray*t, mip)
    t += worldDistance(D, mip)
    
    IF D == 1.0 -> mip += 2
    IF D <= 0.25 -> mip -= 2; D -= halfVoxel
    IF D < pixelConeWidth * t -> BREAK
// 如果曲面位于像素内边界圆锥体内，则中断，获得完美的LOD！
 
  最后一步：球体追踪需要无限步才能收敛，假设我们碰到一个*面，三线性过滤=分段线性曲面，几何级数，使用最后两个样本，\(Step = D/(1-(D-D_{-1}))\)。 
   
  锥体追踪解析解： 
   
  粗糙锥体追踪Prepass： 
   
  光线追踪结果：锥形追踪跳过大面积的空白空间，大幅缩短步长，体积采样更多缓存局部性。Mip映射改善缓存的局部性，Log8数据缩放：100%、12.5%、1.6%、0.2%、...测量（1080p渲染），访问8MB数据（512MB），99.85%的缓存命中率。存在的问题有：过步进（Overstepping）、加载*衡等，它们有各自的缓解方案。 
  对于AO，在表面法线方向构造圆锥体，加上随机变化+时间累积，AO射线使用低SDF mip，更好的GPU缓存位置和更少的带宽，软远程AO。Claybook也使用UE4 SSAO，小规模（*）的环境遮挡。 
   
  上：SSAO；下：SSAO + RTAO。 
  软阴影球体跟踪：柔和的半影扩大阴影，沿光线步进SDF*似最大圆锥体覆盖率，Demoscene圆锥体覆盖*似： 
  c = min(c, light_size * SDF(P) / time);
 
   
  Claybook对软阴影的改进：三角测量最*距离，Demoscene=单个样本（最小），三角测量cur和prev样本，更少条带。抖动阴影光线，UE4时间累积，隐藏剩余的带状瑕疵，较宽的内半影。 
   
  改进前后对比： 
   
  光追的各项时间消耗： 
   
  SDF到网格的转换：双通道*似，多个三角形指向同一个粒子，首先需要生成粒子。输出用于PBD模拟器的线性粒子数组（表面）和三角形渲染的索引缓冲区。使用单个间接绘制调用绘制的所有网格。转成粒子使用64x64x64的dispatch、4x4x4的线程组，过程如下： 
   
   分组：将\(6^3\)个SDF邻域加载到GSM。 
   读取\(2^3\) GSM的邻域，如果在边缘内/外找到： 
     
     将P移动到表面（梯度下降）。 
     分配粒子id（L+G原子）。 
     将P写入数组[id]。 
     将粒子id写入\(64^3\)网格。 
     
   
  转成三角形使用64x64x64的dispatch、4x4x4的线程组，过程如下： 
   
   分组：将\(6^3\)个SDF邻域加载到GSM。 
   读取\(2^3\) GSM的邻域，如果找到XYZ边缘： 
     
     每个XYZ边分配2倍三角形（L+G原子）。 
     从\(64^3\)的id网格读取3倍的粒子id。 
     将三角形写入索引缓冲区（3倍的粒子id）。 
     
   
  异步计算： 
   
   将帧拆分为3个异步段。 
     
     重叠UE4的GBuffer和阴影级联。 
     重叠UE4的速度渲染和深度解压缩。 
     重叠UE4的照明和后处理。 
     
   工作立即提交。 
     
     计算队列等待栅栏启动（x3）。 
     主队列等待栅栏继续（x3）。 
     
   
   
  异步计算可以让fps提升19%+。 
  集成到UE4渲染器： 
   
   GBuffer组合。 
     
     全屏PS组合光线追踪数据。 
     采样材质贴图（自定义gather4过滤）。 
     写入UE4的GBuffer+深度缓冲区（SV_Depth）。 
     
   阴影遮蔽（shadow mask）组合。 
     
     全屏PS到球体追踪阴影。 
     写入UE4阴影遮罩缓冲区（使用alpha混合）。 
     
   
  UE4 RHI定制： 
   
   在不进行隐式同步的情况下设置渲染目标。 
     
     可以对重叠深度/颜色进行解压缩。 
     可以将绘制重叠到多个RT（下图）。 
     
   清除RT/buffer而不进行隐式同步。 
   缺少异步计算功能。 
     
     缓冲区/纹理复制并清除。 
     
   计算着色器索引缓冲区写入。 
   
   
  UE4 RHI定制（额外）：GPU->CPU缓冲区回读，UE4仅支持2d纹理回读而不停顿，其它readback API会让整个GPU陷入停顿，缓冲区可以有原始视图和类型化视图，宽原始写入=高效填充窄类型缓冲区。 
  UE4优化：允许间接分派/提取的重叠，允许清除和复制操作重叠，允许不同RT的绘制重叠，减少GPU缓存刷新和停顿（下图），优化的暂存缓冲区，快速清晰的改进。优化屏障和栅栏，优化纹理数组子资源屏障，更好的3d纹理GPU分块模式，改进的部分2d/3d纹理更新，5倍更快的直方图+眼睛适应着色器，4倍更快的离线CPU SDF生成器（烘焙）。 
   
  实现说明：物理数据存储在一个大的原始缓冲区中，宽加载4/Store4指令（16字节），位压缩：粒子位置：16位范数、粒子速度：fp16、粒子标志（活动、碰撞等）的位字段，基准工具：https://github.com/sebbbi/perftest。Groupshared内存是一个巨大的性能利器，SDF生成、网格生成、物理，重复加载相同数据时使用。标量加载是AMD在性能上的一大胜利，用例：常量索引原始缓冲区加载，用例：基于SV_GroupID的原始缓冲区加载，存储到SGPR的负载获得更好的占用率。 
  Entity-Component Systems & Data Oriented Design In Unity分享了Unity的ECS和面向数据设计的技术，包含面向对象设计、面向数据的设计、实体组件系统、实践案例等。OO的典型实现：类层次结构，虚拟函数，封装经常被违反，因为东西需要知道，“一次只做一件事”的方法，迟来的决定。简单OO组件系统： 
  // Component base class. Knows about the parent game object, and has some virtual methods.
class Component
{
public:
    Component() : m_GameObject(nullptr) {}
    virtual ~Component() {}
    virtual void Start() {}
    virtual void Update(double time, float deltaTime) {}
    const GameObject& GetGameObject() const { return *m_GameObject; }
    GameObject& GetGameObject() { return *m_GameObject; }
    void SetGameObject(GameObject& go) { m_GameObject = &go; }
private:
    GameObject* m_GameObject;
};

class GameObject
{
public:
    GameObject(const std::string&& name) : m_Name(name) { }
    ~GameObject() 
    { 
        for (auto c : m_Components) 
            delete c; 
    }
    // get a component of type T, or null if it does not exist on this game object
    template T* GetComponent()
    {
        for (auto i : m_Components) 
        { 
            T* c = dynamic_cast(i); 
            if (c != nullptr) 
                return c; 
        }
        return nullptr;
    }
    // add a new component to this game object
    void AddComponent(Component* c)
    {
        c->SetGameObject(*this); 
        m_Components.emplace_back(c);
    }
    void Start() 
    { 
        for (auto c : m_Components) 
            c->Start(); 
    }
    void Update(double time, float deltaTime) 
    { 
        for (auto c : m_Components) 
            c->Update(time, deltaTime); 
    }
    
private:
    std::string m_Name;
    ComponentVector m_Components;
};

// Utilities
// Finds all components of given type in the whole scene
template
static ComponentVector FindAllComponentsOfType()
{
    ComponentVector res;
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent();
        if (c != nullptr) res.emplace_back(c);
    }
    return res;
}
// Find one component of given type in the scene (returns first found one)
template
static T* FindOfType()
{
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent();
        if (c != nullptr) return c;
    }
    return nullptr;
}

// various components

// 2D position: just x,y coordinates
struct PositionComponent : public Component
{
    float x, y;
};
// Sprite: color, sprite index (in the sprite atlas), and scale for rendering it
struct SpriteComponent : public Component
{
    float colorR, colorG, colorB;
    int spriteIndex;
    float scale;
};

// Move around with constant velocity. When reached world bounds, reflect back from them.
struct MoveComponent : public Component
{
    float velx, vely;
    WorldBoundsComponent* bounds;
    MoveComponent(float minSpeed, float maxSpeed)
    {
        /* … */
    }
    virtual void Start() override
    {
        bounds = FindOfType();
    }
    virtual void Update(double time, float deltaTime) override
    {
        /* … */
    }
};

// components logic
virtual void Update(double time, float deltaTime) override
{
    // get Position component on our game object
    PositionComponent* pos = GetGameObject().GetComponent();
    // update position based on movement velocity & delta time
    pos->x += velx * deltaTime;
    pos->y += vely * deltaTime;
    // check against world bounds; put back onto bounds and mirror
    // the velocity component to "bounce" back
    if (pos->x < bounds->xMin) { velx = -velx; pos->x = bounds->xMin; }
    if (pos->x > bounds->xMax) { velx = -velx; pos->x = bounds->xMax; }
    if (pos->y < bounds->yMin) { vely = -vely; pos->y = bounds->yMin; }
    if (pos->y > bounds->yMax) { vely = -vely; pos->y = bounds->yMax; }
}

// game update loop
void GameUpdate(sprite_data_t* data, double time, float deltaTime)
{
    // go through all objects
    for (auto go : s_Objects)
    {
        // Update all their components
        go->Update(time, deltaTime);
        // For objects that have a Position & Sprite on them: write out
        // their data into destination buffer that will be rendered later on.
        PositionComponent* pos = go->GetComponent();
        SpriteComponent* sprite = go->GetComponent();
        if (pos != nullptr && sprite != nullptr)
        {
            /* … emit data for sprite rendering … */
        }
    }
}
 
  OO设计的问题：将代码放在哪里？游戏中的许多系统不属于“一个对象”，例如碰撞、损坏、AI：在2+个物体上工作。游戏中的“精灵避免泡泡”：把回避逻辑放在回避某事的事情上？把回避逻辑放在应该避免的事情上？其它地方？许多语言都是“单一分派”，有一些对象和方法可以使用它们，但我们需要的是“多次派遣”，回避系统对两组物体起作用。 
  OO设计的问题：很难知道什么是什么。有没有开过Unity项目并试图弄清楚它是如何工作的？ “游戏逻辑”分散在数百万个组件中，没有概述。 
  OO设计的问题：“凌乱的基类”问题： 
  EntityType entityType() const override;

void init(World* world, EntityId entityId, EntityMode mode) override;
void uninit() override;

Vec2F position() const override;
Vec2F velocity() const override;

Vec2F mouthPosition() const override;
Vec2F mouthOffset() const;
Vec2F feetOffset() const;
Vec2F headArmorOffset() const;
Vec2F chestArmorOffset() const;
Vec2F legsArmorOffset() const;
Vec2F backArmorOffset() const;

// relative to current position
RectF metaBoundBox() const override;

// relative to current position
RectF collisionArea() const override;

void hitOther(EntityId targetEntityId, DamageRequest const& damageRequest) override;
void damagedOther(DamageNotification const& damage) override;

List damageSources() const override;

bool shouldDestroy() const override;
void destroy(RenderCallback* renderCallback) override;

Maybe loungingIn() const override;
bool lounge(EntityId loungeableEntityId, size_t anchorIndex);
void stopLounging();

float health() const override;
float maxHealth() const override;
DamageBarType damageBar() const override;
float healthPercentage() const;

float energy() const override;
float maxEnergy() const;
float energyPercentage() const;
float energyRegenBlockPercent() const;

bool energyLocked() const override;
bool fullEnergy() const override;
bool consumeEnergy(float energy) override;

float foodPercentage() const;

float breath() const;
float maxBreath() const;

void playEmote(HumanoidEmote emote) override;

bool canUseTool() const;

void beginPrimaryFire();
void beginAltFire();

void endPrimaryFire();
void endAltFire();

void beginTrigger();
void endTrigger();

ItemPtr primaryHandItem() const;
ItemPtr altHandItem() const;

// … etc.
 
  OO设计的问题：性能。100万个精灵，20个泡泡：330ms游戏更新，470ms启动时间，分散在内存中的数据，虚拟函数调用。 
  OO设计的问题：内存使用。100万个精灵，20个泡泡：310MB内存使用率，每个组件都有指向游戏对象的指针，但很少有人需要它，每个组件都有一个指向虚拟函数表的指针，每个游戏对象/组件都是单独分配的。典型内存视图： 
   
  OO设计的问题：可优化。如何多线程化？如何跑在GPU？在很多OO设计中非常难，没有清晰的谁读取什么数据和写入什么数据。 
  OO设计的问题：可测试性。将如何为此编写测试？OO设计通常需要大量的设置/模拟/伪造来进行测试，创建对象层次结构、管理器、适配器、单例… 
  CPU性能趋势： 
   
  CPU-内存性能差距： 
   
  计算机中的延迟数据： 
   
   从CPU一级缓存读取：0.5ns。 
   分支预测失败：5ns。 
   从CPU二级缓存读取：7ns。 
   从RAM读取：100ns。 
   从SSD读取：150000ns。 
   从RAM读取1MB：250000ns。 
   发送网络数据包CA->NL->CA：150000000ns。 
   
  代码和数据需要结合在一起吗？典型的OO将代码和数据放在一个类中，为什么呢？回忆“代码放在哪里”的问题： 
  // this?
class ThingThatAvoids
{
    void AvoidOtherThing(ThingToAvoid* thing);
};
// or this?
class ThingToAvoid
{
    void MakeAvoidMe(ThingThatAvoids* who);
};

// why not this instead? does not even need to be in a class
void DoAvoidStuff(ThingThatAvoids* who, ThingToAvoid* whom);
 
  数据优先：“所有程序及其所有部分的目的都是将数据从一种形式转换为另一种形式”，“如果你不了解数据，你就不了解问题所在”——迈克·阿克顿。这是尼克劳斯·沃思1976年的一本经典著作。有人可能会说，“数据结构”也许应该是第一位的，请注意，它根本不谈论“对象”！ 
  有一个，就有很多。你多久吃一次某样东西？在游戏中，最常见的情况是：有几件事，任何代码都可以在这里使用，事情太多了，必须小心性能。 
  virtual void Update(double time, float deltaTime) override
{
    /* move one thing */
}

// 将上面的改成下面

void UpdateAllMoves(size_t n, GameObject* objects, double time, float deltaTime)
{
    /* move all of them */
}
 
  面向数据的设计（DOD）：理解数据解决这个问题所需的理想数据是什么？它是怎么布置的？谁读什么，谁写什么？数据中的模式是什么？常见情况下的设计，很少有“一”的东西，为什么你的代码一次只处理一件事？DOD相关资源： 
   
   Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP) blog post, Noel Llopis 
   Practical Examples in Data Oriented Design slides, Niklas Gray 
   Data-Oriented Design and C++ video, Mike Acton 
   Typical C++ Bullshit slide gallery, Mike Acton 
   Data-Oriented Design blog post & links, Adam Sawicki 
   
  传统的Unity GO/组件设置是ECS吗？传统的Unity设置使用组件，但不使用ECS。组件解决了“来自地狱的基类”问题的一部分，但不能解决其它问题：逻辑、数据和代码流难以推理，一次只对一件事执行逻辑（更新等），在一个类型/类中（“代码放在哪里”问题），内存/数据局部性不是很好，一堆虚调用和指针。 
  实体组件系统（ECS）：实体只是一个标识符，有点像数据库中的“主键”？是的。组件就是数据。系统是在具有特定组件集的实体上工作的代码。 
  ECS/DOD样例：回忆一下简单的“游戏”：400行代码，100万个精灵，20个泡泡：330毫秒更新时间，470ms启动时间，310MB内存占用。 
   
  第1步：纠正愚蠢。GetComponent在GO each和每一次中搜索组件，我们可以找到一次并保存它！330毫秒→ 309ms。 
   
  GetComponent在Avoid组件的内部循环中，也缓存它。309ms → 78ms。 
   
  现在时间花在哪里？使用探查器（Mac上是Xcode Instruments）： 
   
  让我们做一些系统：AvoidanceSystem，避免和避免现在这些组件几乎只是数据，系统知道它将操作的所有东西。 
  struct AvoidThisComponent : public Component
{
    float distance;
};
// Objects with this component "avoid" objects with AvoidThis component.
struct AvoidComponent : public Component
{
    virtual void Start() override;
};

// "Avoidance system" works out interactions between objects that have AvoidThis and Avoid
// components. Objects with Avoid component:
// - when they get closer to AvoidThis than AvoidThis::distance, they bounce back,
// - also they take sprite color from the object they just bumped into
struct AvoidanceSystem
{
    // things to be avoided: distances to them, and their position components
    std::vector avoidDistanceList;
    std::vector avoidPositionList;
    // objects that avoid: their position components
    std::vector objectList;
    
    void UpdateSystem(double time, float deltaTime)
    {
        // go through all the objects
        for (size_t io = 0, no = objectList.size(); io != no; ++io)
        {
            PositionComponent* myposition = objectList[io];
            // check each thing in avoid list
            for (size_t ia = 0, na = avoidPositionList.size(); ia != na; ++ia)
            {
                float avDistance = avoidDistanceList[ia];
                PositionComponent* avoidposition = avoidPositionList[ia];
                // is our position closer to "thing to avoid" position than the avoid distance?
                if (DistanceSq(myposition, avoidposition) < avDistance * avDistance)
                {
                       /* … */
                }
            }
        }
    }
};
 
  以上是系统的逻辑代码。78ms → 69ms。类似的，让我们做一个移动系统：MoveSystem。 
  // Move around with constant velocity. When reached world bounds, reflect back from them.
struct MoveComponent : public Component
{
    float velx, vely;
};

struct MoveSystem
{
    WorldBoundsComponent* bounds;
    std::vector positionList;
    std::vector moveList;
    
    void UpdateSystem(double time, float deltaTime)
    {
        // go through all the objects
        for (size_t io = 0, no = positionList.size(); io != no; ++io)
        {
            PositionComponent* pos = positionList[io];
            MoveComponent* move = moveList[io];
            // update position based on movement velocity & delta time
            pos->x += move->velx * deltaTime;
            pos->y += move->vely * deltaTime;
            // check against world bounds; put back onto bounds and mirror the velocity component to "bounce" back
            if (pos->x < bounds->xMin) { move->velx = -move->velx; pos->x = bounds->xMin; }
            if (pos->x > bounds->xMax) { move->velx = -move->velx; pos->x = bounds->xMax; }
            if (pos->y < bounds->yMin) { move->vely = -move->vely; pos->y = bounds->yMin; }
            if (pos->y > bounds->yMax) { move->vely = -move->vely; pos->y = bounds->yMax; }
    }
};
 
  以上是移动系统的逻辑，69ms→ 83ms， 什么！！！？？？再次分析之： 
   
  迄今为止的经验教训：由于意想不到的原因，优化一个地方可能会让事情变得更慢，乱序的CPU、缓存、预取等等。C++RTTI（dynamic_cast）可以非常慢，我们在GameObject::GetComponent中使用它。 
  // get a component of type T, or null if it does not exist on this game object
template T* GetComponent()
{
    for (auto i : m_Components) 
    { 
        T* c = dynamic_cast(i); 
        if (c != nullptr) 
            return c; 
    }
    return nullptr;
}
 
  那就停止使用C++RTTI吧。如果有一个“类型”枚举，并且每个组件都存储了类型…83毫秒→ 54毫秒！！ 
  enum ComponentType
{
    kCompPosition,
    kCompSprite,
    kCompWorldBounds,
    kCompMove,
    kCompAvoid,
    kCompAvoidThis,
};
// ...
ComponentType m_Type;

// was: T* c = dynamic_cast(i); if (c != nullptr) return c;
if (c->GetType() == T::kTypeId) return (T*)c;
 
  到目前为止，更新性能：提高6倍（330毫秒）→54毫秒）！内存使用：增加310MB→363MB，组件指针缓存，在每个组件中键入ID…代码行：400多行→500，让我们试着移除一些东西！ 
  Avoid和AvoidThis组件，谁需要它们？没错，没有人，直接用AvoidanceSystem注册对象即可。54毫秒→ 46ms，363MB→325MB，500→455行。 
   
  实际上，谁需要组件层次结构？只需在GameObject中包含组件字段。46毫秒→43ms更新，398→112ms启动时间，325MB→218MB，455→350行。 
  // each object has data for all possible components,
// as well as flags indicating which ones are actually present.
struct GameObject
{
    GameObject(const std::string&& name)
        : m_Name(name), m_HasPosition(0), m_HasSprite(0), m_HasWorldBounds(0), m_HasMove(0) { }
    ~GameObject() {}
    
    std::string m_Name;
    // data for all components
    PositionComponent m_Position;
    SpriteComponent m_Sprite;
    WorldBoundsComponent m_WorldBounds;
    MoveComponent m_Move;
    // flags for every component, indicating whether this object "has it"
    int m_HasPosition : 1;
    int m_HasSprite : 1;
    int m_HasWorldBounds : 1;
    int m_HasMove : 1;
};
 
  停止分配单个游戏对象，vector → vector，43ms更新，112→99ms启动，218MB→203MB。 
   
  典型布局是结构数组（AoS）：一些对象，以及它们的数组。易于理解和管理，太好了…如果我们需要每个物体的所有数据。 
  // structure
struct Object
{
    string name;
    Vector3 position;
    Quaternion rotation;
    float speed;
    float health;
};
// array of structures
vector

AGAA Pass	Render Target	Video Memory Bytes
AGAA Clustering	AGAA MetaData	WxHx1 R16_UINT
AGAA Lighting & Reflections	Per-Aggregate Lit Colors	WxHx2 R11G11B10F
Merge Emissive	Per-Pixel Lit Color + Emissive	WxHx4 R11G11B10F
		Total VRAM overhead: 26 bytes / pixel

阶段	4xSSAA	4xAGAA	4xAGAA / 4xSSAA
Z PrePass	0.13	0.13	1.0x
GBuffer Fill	1.26	1.26	1.0x
Lighting	4.71	2.85	1.65x
PostProcessing	0.55	0.55	1.0x
Frame	6.65	4.79	1.39x

CDLOD	CDClipmap
欧几里得距离	出租车（Taxicab ）距离
四叉树	最小化CPU
裙子几何？	裙子几何
无形状连接	形状连接

剖析虚幻渲染体系（14）- 延展篇：现代渲染引擎演变史Part 3（开花期一）

14.5 结果期（2016~2022）

14.5.1 图形API

14.5.1.1 DirectX

14.5.1.2 OpenGL

14.5.1.3 Vulkan

14.5.1.4 Metal

14.5.2 硬件架构

14.5.3 引擎演变

14.5.3.1 综合演变

14.5.3.2 光影技术

**14.5.3.3 移动*台**

14.5.3.4 并行技术

14.5.3.5 特殊技术

你可能感兴趣的:(深入UE,虚幻,UE5)