共计 3615 个字符，预计需要花费 10 分钟才能阅读完成。
混合渲染
混合渲染（Hybrid Rendering）从字面意思就是非繁多办法的渲染机制。这也就使得这个词，没有一个齐全规范且惟一精确的定义。首先大家须要明确，渲染的最终目标是出现画面，不论是图片，视频，还是实时交互的场景。
那为了这个最终的出现后果，如果渲染过程中采纳了很多种计划来混合实现，就能够说它是混合渲染。
咱们从不同的角度，总结了一些混合渲染的模式。依然不探讨具体的技术实现细节，只是为了不便大家了解概念。
基于管线的混合渲染，指的是一条渲染管线中，会用到不同的计算承载形式，最终来实现渲染工作。目前的计算承载形式包含：光栅化（Rasterization，蕴含 Vertex Shader 和 Fragment Shader），计算着色器（Compute Shader），光线追踪着色器（Ray Tracing Shaders）。
渲染管线中，最根本的计算承载形式就是光栅化。原则上，光栅化是为了输入渲染内容的一整个渲染流程，同时也能够利用流程中的 Vertex Shader 和 Fragment Shader 进行一些计算的解决，然而光栅化过程中是产生在 Render Pass 中，其中有很多 Fix Function，比方剔除，深度测试，颜色混合等，所以用光栅化来进行计算，其实是“不专一”的，效率会绝对低下。
光栅化对于一些光线不是很简单的场景依然是能够胜任的。然而如果光线一旦简单，它就没有方法很好地胜任简单的光线算法了，因而渲染成果也就不尽人意。
目前 WebGL 只具备光栅化须要的 Vertex Shader 和 Fragment Shader（Extension 版本除外），计算能力无限且不够灵便，渲染成果也不会特地优良。
WebGL 为了实现比拟好的渲染成果，都是通过预烘焙的办法，将成果附加到贴图自身，以动态的形式进行展现，从而失去了对简单光线变换的实时应答能力。
为了解决光栅化的计算效率低下问题，古代图形 API 都提供了计算着色器，即 Compute Shader。
WebGPU 也利用了古代图形 API 的设计准则，同样反对 Compute Shader。Compute Shader 实质是一种通用计算的能力（GPGPU），齐全使用在 Compute Pass 中的，是“专一”的计算单元，很相似于 CUDA（不过 CUDA 能够通过英伟达的显卡做到硬件芯片级别的减速，因而计算性能更高）。
有了这种通用计算能力，就不再是光栅化中的“模仿”计算了，而是专业级的计算能力。比方咱们用光栅化中的 Fragment Shader 模仿一些算法，只能限度在二维的立体坐标系中，而 Computer Shader 没有这种限度，也更加的灵便，速度更快。
光线追踪 Ray Tracing 是一项几十年前就有的技术，然而因为计算量太大，而无奈实现实时渲染。因为 RTX 显卡的呈现，让实时光线追踪这个概念再次失去了关注。
光线追踪是门路追踪的一种简略模式，然而这两个概念实质上都是一种数学算法。光线追踪着色器（Ray Tracing Shaders）就是特意为光线追踪这种数学算法而设计的，它由很多非凡着色器模块的组合而成。下图是 RTX 光线追踪的架构图：
既然光线追踪只是一种数学算法，那么任何语言和编程环境都能够对这个数学算法进行实现。
如果只看图形畛域，咱们能够用 CUDA, Fragment Shader（OpenGL, WebGL），Computer Shader（WebGPU，Vulkan，Metal，DX11/DX12，OpenGL Extension），RXT（DX12/DXR, Vulkan）来实现光线追踪算法。
既然光线追踪算法用下面的形式都能够实现，为什么 RXT 会再次引爆这个概念呢？起因就是它能够实时地实现光线追踪算法。
RTX 显卡针对光线追踪这一个十分重要且非凡的渲染算法，独自做了硬件级别的减速。通过硬件芯片能够间接运行下面提到的光线追踪过程中的各种着色器模块（能够了解成把 CUDA 的通用计算芯片从新设计，优化成更适宜运行光线追踪算法的芯片），这样就能够在 3D 场景中实时的实现光线追踪的运算后果，渲染更加优质的 3D 画面。
目前苹果的 M1 芯片还临时不反对对光线追踪算法的硬件加速，所以 Metal 还是通过相似于 Compute Shader（Metal Performance Shaders）的办法来优化光线追踪算法。WebGPU 也会在将来的版本中，退出对于 RTX 的反对，咱们一起期待！
三种计算承载形式：光栅化，计算着色器和光线追踪着色器都曾经介绍完了。它们之间并不是谁要代替谁，也没有一种完满的办法。
而对于不同的场景，使用不同的办法。所以，对于混合渲染的概念，置信大家也更加清晰了。只有混合应用了不同渲染办法的渲染管线，我都能够了解成是混合渲染的一种体现。
基于数据的混合渲染，指的就是对一个 3D 场景中的不同 3D 资源（模型，场景等）进行分类，相当于对 3D 资产数据进行拆分，把不同类别的 3D 数据放到不同的渲染节点进行渲染，最初通过网络通信技术，把数据合并到一个须要显示输入的节点上，进行最终的出现。
个别提到这种基于数据的混合渲染，都会和上一期咱们聊到的云渲染有些关联。因为这种数据拆分的模式能够让咱们人造地想到，把一些复杂度高，计算要求大的工作放到并行计算能力更强的云端，利用渲染集群进行计算。
而咱们的集体终端，只渲染计算量绝对较小的工作。云端渲染的后果，最终不论是以视频或图片的模式传给客户端，还是只把简单计算的后果返回给客户端，再由客户端进行最终的出现，都会大大降低客户端的开销。
在 5G 通信技术的疾速倒退下，更加多样灵便的渲染架构，例如边，端，云协同渲染也失去了更多的尝试和验证。
这种渲染形式，能够充分利用终端及终端左近的边缘节点的计算能力，防止了全云端渲染可能会遇到的“卡顿”问题。
而且，也是一种“进可攻退可守”的架构设计，通过渲染工作的解耦设计，能够在全终端渲染和全云端渲染之间灵便切换和调配，进而适应更简单的渲染需要。
基于管线的混合渲染
同济大学贾金元老师提出的协同混合渲染的网络架构
基于硬件的混合渲染
基于硬件的混合渲染，指的就是 CPU 和 GPU 能够同时参加渲染工作的一种混合渲染模式。这里咱们参考 V -ray 的混合渲染模式。首先要阐明的是，单纯的 GPU 渲染有两个问题：
1）很难进行 Debug：GPU 的程序如果出错根本都会返回一个 kernel dump（就是内核挂掉了），不会有相应的报错信息提醒。
2）无奈充分利用 CPU 的性能：之前的渲染工作根本都是交给 GPU 来进行计算的，CPU 把工作提交给 GPU 之后，CPU 自身其实会处于一段时间的闲暇状态，等于白白浪费了计算能力。
为了解决这两个问题，V-ray 提出的混合渲染就是能够让 CUDA 同时运行在 CPU 和 GPU 上，这样能够充分利用 CPU 提交工作给 GPU 之后，自身的闲暇工夫，同样能够进行渲染的计算工作。
通过测试，V-ray 的混合渲染比单纯的 GPU 渲染，实现工夫均匀缩短了约 20% 左右。这里须要强调下，这种 CPU 和 GPU 同时进行的混合渲染模式，在 WebGL 的规范下是无奈实现的，因为它采纳的是全局状态机模式，CPU 必须要期待 GPU 的运行后果，能力持续做下一个工作，简略说就是同步机制。
而 WebGPU 采纳了古代图形 API 的办法，齐全遵循异步模式，这样才具备实现这种混合渲染的根底能力。
基于框架的混合渲染
基于框架的混合渲染，指的是渲染过程能够从之前的框架转移到另外一个全新的框架上实现。
2019 年，Unity 提出 Data-Oriented Technology Stack（DOTS）技术，并通过 Hybrid Renderer 来实现。DOTS 的外围就是 ECS（Entities, Components, Systems）的架构设计，也标记着 ECS 框架在游戏引擎中的利用（对于 ECS 的细节和优劣势咱们这里就不做探讨了）。
Unity 的 Hybrid Renderer 带来的混合渲染，其实指的是能够让渲染过程从之前的 OOP 模式（Object-oriented Programming）转换到 DOP 模式（Data-oriented Programming），是把 GameObjects 转换成 ECS 中的 Entities。
最终的目标就是利用 ECS 的数据间断内存存储特色，进步缓存命中率，同时引入多核并行计算的劣势，放慢渲染过程。
讲到这里，咱们把一些常见的混合渲染的模式都曾经介绍完了。总结下就是，混合渲染没有一个固定的定义，只有把“渲染”混合应用，都能够叫混合渲染。
目前，咱们曾经介绍了离线渲染、实时渲染、云渲染、混合渲染。要强调的是，它们之间所用到的技术和场景，有很多都是互相交叠在一起的，并没有一个规范惟一的准则。
咱们心愿的是，大家如果在再次遇到这些概念，或者一些 3D 渲染引擎产品的时候，能够依照这些渲染分类，去疾速的进行定位和剖析，更好的帮忙咱们了解和学习，解决咱们遇到的问题，这样就曾经足够好啦！
起源：Orillusion
