【渲染管线】现在游戏引擎都必须多线程渲染么？

CPU 和 GPU 之间的关系是 client-server 关系，线程是 CPU 的概念，GPU 有并行但没有线程概念。现代引擎考虑 low-overhead，要从平衡 CPU 和 GPU 的并行效率来考虑，和线程这个 CPU 侧的概念有相关性但没有必然的固定关系。

比如说，CPU 可以从一个线程顺序发给 GPU 几个 render-pass 的指令。这几个 render-pass 在 GPU 侧可能是并行处理的。但 CPU 没有必要开多个线程去处理这些指令，因为指令的 encoding 可能比指令的执行短的多。

反过来，理论上来说，如果 encoding 花的时间太多，或者为 encoding 准备数据需要大量 CPU 算法，那就要支持多线程 encoding。

所以，这个问题本身是有问题的。因为如果你考虑多线程，那么严格来说就只是 render-pass command encoding，而不是 render。如果你说 render，那就已经和线程概念不相关了。

从实际来说，目前的趋势是大量的处理移到 GPU 侧完成，所以 encoding 花的时间应该在降低。从这个趋势来说，多线程 encoding 可能并不是广泛的需求。

需求是没有「必须」的，都是按实际情况而厘定的，这些因素包括硬件、操作系统、图形API、游戏类型、向前兼容等。如问题描述所说，手机引擎还要兼顾性能和耗电，不过耗电不在于切换，而是使用多核需要消耗更多电能。

所谓多线程渲染有不同的做法，最基本的是指开一个线程与图形API交互，但这并不是无缺点的，一般会为了增加吞吐量（throughput，这里指游戏帧率）而同时增加延时（latency，这里指玩家输入至屏幕输出反馈的时间）。有一些引擎可能还会把一些渲染工作（可见性判断、动态光源与物体的相交判断、渲染状态排序、图元提交等）打包成job／task，调度至多个线性并行处理。另外，D3D11、Metal等API可以把多个图形命令在不同线程中生成，最后才提交，达至多线程的渲染优化。

基于当前帧的多线程实时渲染（multi-thread realtime rendering），性能提升仅限于当前帧。意在解决单线程CPU以for轮询的方式向GPU端提交 render command的瓶颈问题。

这种性能的提升是基于高显低U(高性能显卡搭配低主频多核处理器)的情况下，把多线程中N个渲染指令，均摊到数个线程中，实现并行command-line提交。

但，这也仅限于当前帧的性能提升，在cpu-gpu性能均衡时，也不会带来明显的性能提升。而且，操作不慎还会出逻辑触发顺序问题，况且多线程争夺gpu端共享的context会涉及到数据同步的问题，极端情况下也会产生不必要的阻塞。

DX9 时代 DRAW CALL 效率低，所以经常把游戏逻辑放一个 CPU 线程，渲染递交 DRAW CALL 放一个 CPU 线程。

DX11 DRAW CALL 有所缓解，所以游戏逻辑和渲染放一个 CPU 也不是不可以。比如 TRIALS 系列渲染都是和游戏逻辑放一起的，每帧 2 - 3 万多个 OBJECT，两次 geometry pass，锁定 PS4 1080P 60 fps，X1 900P 60 fps。

DX12 、VULKAN 概念不同了：

1. 一方面 D3D CONTEXT 不再规定只能放一个线程，所以 CPU 端递交 DRAW CALL 可以多线程递交。

2. 另一方面有了 ASYNC COMPUTE，GPU 端也可以做手动的并行处理，比如在做 geometry pass 的同时还可以用 compute shader 搞些后处理。而以往 GPU 端的并行处理是怎么做的完全是黑箱操作。

多核CPU情况下使用多线程渲染是有优势的，可以用一个线程作为gpu service和GPU DEVICE通信，然后把渲染场景每一个模块开一个gpu client线程渲染，client把命令发送给service，client之间共享资源，同步可以放在service端。

这样的优势是可以充分的使用CPU多核，移动soc上面单纯讨论耗电其实意义不大，应该把性能和功耗整体考虑，况且soc的调度策略影响也很大。