2、渲染管线基础：图形渲染管线的各个阶段、CPU与GPU的协作模式
好，咱们进入正题。渲染管线，说白了就是显卡把一堆数据变成屏幕上像素的流水线。你想想看，一个3D场景从模型文件到最终画面，中间要经历多少道工序？我刚开始接触这玩意儿时，也觉得它像个黑盒子。但做多屏交互，不理解管线，你根本没法优化延迟。
今天我就带你拆开这个黑盒子，看看里面到底在忙什么。
2.1 图形渲染管线的四个核心阶段
渲染管线可以粗暴地分成四个大阶段：顶点处理、光栅化、片段处理、输出合并。嗯，这里要注意，不同API（比如OpenGL和DirectX）的划分细节略有不同，但核心逻辑是一样的。
2.1.1 顶点处理（Vertex Processing）
这是管线的第一站。CPU把模型的顶点数据（位置、颜色、法线、纹理坐标）一股脑丢给GPU。GPU的顶点着色器就开始干活了。
它主要做三件事：
- 坐标变换：把模型从自己的局部坐标系，一步步变换到世界坐标、视图坐标，最后到裁剪坐标。说白了，就是算清楚这个顶点在屏幕上的大概位置。
- 顶点着色：根据光照和材质，算出每个顶点的颜色。
- 图元组装：把顶点组装成三角形、线段或者点。这一步叫图元装配。
关键点：顶点处理是并行的。GPU里有成百上千个核心，可以同时处理成千上万个顶点。这也是GPU比CPU快得多的原因之一。
我个人习惯在项目初期就检查顶点数量。有一次，一个同事导入了超高精度的模型，顶点数直接爆了。结果呢？顶点处理阶段就卡死了，帧率掉到个位数。后来我们强制做了LOD（细节层次），才把性能救回来。
2.1.2 光栅化（Rasterization）
这一步最神奇。它把连续的几何图形，变成离散的像素点。
你想想看，一个三角形在数学上是连续的，但屏幕是由一个个像素格子组成的。光栅化就是判断：哪些像素点落在这个三角形内部？然后把这些像素点生成出来。
这里有个坑：光栅化本身不计算颜色。它只负责生成片段（Fragment）。一个片段，你可以理解为一个“待处理的像素候选者”。
避坑指南：我曾经在做一个多屏拼接项目时，发现屏幕边缘有锯齿。原因就是光栅化阶段没有做抗锯齿处理。后来我们开启了MSAA（多重采样抗锯齿），虽然增加了片段数量，但画面平滑多了。记住，光栅化阶段决定了画面的“几何精度”。
2.1.3 片段处理（Fragment Processing）
片段着色器上场了。这是最耗计算资源的阶段。
每个片段都要经过片段着色器处理。它要计算：
- 纹理采样：从纹理图片中取出对应位置的颜色。
- 光照计算：根据法线、光源方向、视角方向，算出最终颜色。
- 透明度处理：如果物体是透明的，还要混合背景颜色。
我建议你记住一个数字：一个1080p的屏幕，有约200万个像素。如果每个像素都经过复杂的片段着色器，那计算量是惊人的。所以，尽量在片段着色器里少做复杂计算。能放到顶点着色器里算的，就别放到片段里。
2.1.4 输出合并（Output Merging / Raster Operations）
这是管线的最后一站。它把片段着色器算出来的颜色，写入帧缓冲区。
但这里有个问题：多个片段可能对应同一个像素位置（比如半透明物体叠加）。输出合并阶段要解决：
- 深度测试：哪个片段离相机更近？近的覆盖远的。
- 模板测试：根据模板缓冲区的内容，决定是否写入。
- 混合：如果是半透明物体，把当前颜色和缓冲区里的颜色按比例混合。
小技巧：如果你发现画面出现“闪烁”或者“Z-fighting”（两个平面靠得太近，深度值打架），多半是深度测试精度不够。可以尝试调整近远裁剪面的距离，或者使用更高精度的深度缓冲区。
2.2 CPU与GPU的协作模式
CPU和GPU，就像一对配合默契但性格迥异的搭档。CPU擅长复杂逻辑和串行任务，GPU擅长简单重复的并行计算。
它们怎么协作呢？
2.2.1 命令缓冲区（Command Buffer）
CPU不会直接指挥GPU干活。它会把渲染指令（比如“画这个三角形”、“用这个纹理”）写到一个叫命令缓冲区的地方。GPU从缓冲区里取指令，然后执行。
这就像你给下属发邮件，而不是站在他旁边口述。好处是：CPU可以一口气发很多指令，然后去做别的事。GPU慢慢执行就行。
2.2.2 同步与异步
这里有个经典问题：CPU和GPU谁等谁？
如果CPU发指令太快，GPU跟不上，命令缓冲区会满。CPU就得停下来等GPU。这叫CPU受限。
如果GPU跑得太快，CPU发指令太慢，GPU就会空闲。这叫GPU受限。
我遇到过最头疼的情况是：CPU在忙着加载资源，GPU闲着没事干。结果画面卡顿，但GPU占用率只有30%。后来我们用了多线程渲染，把资源加载和指令提交分开，才把GPU喂饱。
核心原则：尽量让CPU和GPU都保持忙碌。不要让任何一方成为瓶颈。
2.2.3 数据传递的代价
CPU和GPU有各自的内存。CPU用系统内存，GPU用显存。它们之间传递数据，是通过PCIe总线。这个速度虽然快，但相比内存访问，还是慢得多。
所以，尽量减少CPU到GPU的数据传输。比如：
- 不要把每帧都上传顶点数据。一次上传，多次使用。
- 不要把纹理数据每帧都更新。除非是动态纹理。
- 使用持久映射缓冲区，让CPU和GPU共享一块内存区域，避免拷贝。
避坑指南：我曾经为了调试，每帧都从GPU读回一个像素的颜色。结果帧率直接掉到10帧。为什么？因为从GPU读回数据是同步操作，CPU必须等GPU算完才能读。这完全破坏了流水线并行。后来我改用异步查询，才解决问题。
2.3 多屏交互中的特殊考量
做多屏交互，渲染管线的挑战更大。因为你要同时渲染多个视口（Viewport），每个视口可能对应不同的屏幕。
我建议的做法是：
- 共享几何数据：多个屏幕如果显示同一个场景，顶点数据只需要上传一次。
- 独立视口变换：每个屏幕的视口矩阵不同，但可以在顶点着色器里用不同的uniform变量控制。
- 注意同步：多个屏幕的渲染要尽量同步，否则会出现画面撕裂或者延迟不一致。
嗯，这里有个小技巧：如果你用Vulkan或者DirectX 12，可以尝试多队列渲染。把不同屏幕的渲染指令提交到不同的命令队列，让GPU并行处理。但要注意，这需要硬件支持，而且调试起来比较麻烦。
2.4 总结
渲染管线，说白了就是一套流水线。顶点处理、光栅化、片段处理、输出合并，每一步都有它的职责和坑。CPU和GPU的协作，核心是异步、并行、减少数据传输。
我刚开始做多屏项目时，总觉得延迟高是网络问题。后来一查，发现是渲染管线里某个阶段太慢。所以，遇到延迟问题，先查渲染管线。用GPU profiling工具（比如NVIDIA Nsight、AMD GPU Profiler）看看，到底是哪个阶段在拖后腿。
下一章，我会讲垂直同步与帧率控制。到时候咱们聊聊，为什么有时候画面不卡，但就是感觉“不跟手”。
公众号:蓝海资料掘金营，微信deep3321