绘制三角形这件事，听起来像是图形学入门的“Hello World”，但等我真的把一个三角形从顶点数据一路“画”到屏幕上，我才意识到自己对 Graphics pipeline（图形管线）和 Render Pass 的理解有多浅。前两年我在做一个跨平台渲染框架的极小内核，目标很简单：同一份绘制代码能在桌面和移动端跑通，而挑选的第一个验收场景就是渲染一个三角形；当时我以为只要把三个顶点丢给 GPU、再写两个简单的着色器就行，结果光是 Render Pass 的配置就让我愣了好几天。现在回头看，画三角形的过程恰恰是理解现代图形 API 最经典的路径：顶点数据如何变成字节流、着色器如何在可编程阶段处理几何、光栅化如何在像素层面做插值、以及渲染通道如何把清除、绘制、呈现这一步一步串起来。这篇文章就是我当时完整梳理过的笔记，加上实际调试中遇到的那些坑，适合刚接触现代图形接口、对“管线”和“Render Pass”两个词只有模糊概念的人来读。
1. 从画三角形看图形管线的三种“拆解”方式
1.1 我这次入手的方式：先画三角形，再谈框架
我最初的想法是直接封装一套渲染器，但很快发现一个尴尬的问题：渲染器的接口设计取决于你对底层流程的理解程度，如果我连一个三角形都说不清楚，后面加纹理、加光照、加后期处理都会变成空中楼阁。于是我把目标收敛成一行话：“在窗口里画出一个静态彩色三角形。”所有工程结构、代码模块、资源管理都围绕这个最小目标展开。
三角形的不可替代性在于它是最小的“面”。点没有面积，线没有填充语义，只有三角形能让顶点着色器、光栅化、片段着色器和子通道机制完整地走一遍。而且从三角形扩展到任意模型，只需要把顶点数量变多、顶点属性变复杂，管线的骨架完全不用换。我当时还把验收标准定得很死：窗口可以改大小，三角形跟随窗口变化不变形；清屏颜色可调；三角形颜色由顶点颜色插值而来。这三个标准看起来不起眼，却逼着我把视口、归一化设备坐标、顶点插值这些基础概念全部落实。
1.2 图形 API 里的“管线”到底是什么：从裁剪空间到屏幕像素
先解决一个最容易被绕晕的问题：大家说的 Graphics pipeline 到底指什么？它有两个层面。一个是 GPU 内部的硬件流程，包括顶点拾取、图元装配、光栅化、片段着色、像素输出；另一个是现代图形接口要求你显式描述出的“管线对象”。两者相似，但后者是把各类状态打包好的一次性配置，目的就是降低运行期间的重复校验开销。
我用一个后厨的例子来类比：你的菜品是三菜一汤，食材是几何数据，厨师是着色器，传菜通道就是管线。传统做法是每个人各管一段，你随时可以临时改做法；现代图形接口的做法是，你提前把“今天这道菜从切配到装盘每一步怎么做”写成一份流水线手册，后厨按手册执行。对于三角形来说，这份手册包含顶点数据布局、顶点着色器、图元装配规则、光栅化状态、片段着色器、混合与输出格式。任何一个环节没写清楚，三角形都上不了桌。
在现代图形接口里，创建这条管线通常是一次相对昂贵的操作，所以实践上都是先创建、反复复用，而不是每帧重配。这也是为什么很多新手在第一个三角形里感觉到“配置量很大”——不是事情变难了，而是原本隐式的状态被要求显式地说清楚。
1.3 可编程阶段和固定阶段的边界：哪些是你写，哪些是 GPU 管
理解管线时要牢牢记住一个划分：可编程阶段由你写的着色器代码负责，固定阶段由硬件和驱动负责。绘制三角形的完整流程里，顶点着色器和片段着色器是两个可编程阶段，而光栅化、深度测试、混合这些通常属于固定功能阶段。
可编程和固定的边界会直接影响渲染策略。比如你希望三角形边缘平滑，可以在片段着色器里算像素覆盖率；希望做顶点动画，就把位移计算放在顶点着色器；而光栅化阶段决定“哪些像素属于这个三角形”，你无法直接写代码干预它，只能通过图元装配状态、视口和光栅化模式间接控制。我第一次画三角形时，总想“在某个阶段里直接拿到像素坐标”，后来才明白那属于光栅化已经完成之后的事，应该在片段着色器里拿插值结果。
把这层关系理清楚之后，再看 Render Pass 就自然了。渲染通道不是一个着色阶段，而是比“着色”更高一层的调度概念，它规定了整个绘制过程中，各种输出缓冲（颜色、深度、模板）怎么被加载、清除、保存。把顶点数据和着色器放在一起能画出三角形，但只有加上 Render Pass，整个绘制过程才算有头有尾。
2. 顶点数据准备：GPU 拿到手之前的最后一公里
2.1 三角形的“几何学”定义与顶点列表
画一个三角形，第一步是定义三个顶点。但这里有个必须掌握的坐标约定：现代图形接口通常在归一化设备坐标（NDC）里给出顶点位置，也就是 x、y 范围在 [-1, 1] 之间，z 范围在 [0, 1] 或 [-1, 1] 之间，具体要看接口约定。NDC 的好处是把设备差异提前抹平，你不需要关心用户屏幕是横屏还是竖屏、分辨率是 1080p 还是 2K。
一个最简单的彩色三角形可以这样定义：
位置： (-0.5, -0.5, 0.0) 颜色： (1.0, 0.0, 0.0) // 左下，红色 位置： ( 0.5, -0.5, 0.0) 颜色： (0.0, 1.0, 0.0) // 右下，绿色 位置： ( 0.0, 0.5, 0.0) 颜色： (0.0, 0.0, 1.0) // 上方，蓝色这三个点的数据最后会连续地塞进一个字节缓冲里，交给 GPU。严格说，三角形在图元装配时才真正“闭合”，但数据层面至少要给出三个顶点。如果你想画一个四边形，可以拆成两个三角形；如果想画一个立方体，那就需要更多顶点和索引组织方式。不过最核心的复习点还是同一个：几何数据只是一堆数字，GPU 需要借助顶点布局说明才知道数字代表什么。
2.2 顶点属性布局：CPU 与 GPU 之间的“翻译说明书”
把顶点数据喂给 GPU，不能像写文件一样直接把数组丢过去。GPU 读取一段字节流时，并不知道第 0 个字节是 x 还是 r，所以你必须告诉它每个属性从哪里开始、每隔多少字节取下一个。这个说明就是顶点属性布局，有些接口叫“顶点输入描述”，有些叫“顶点缓冲布局”。
以刚才的三角形为例，每个顶点有 6 个 float：3 个位置 + 3 个颜色。如果不做任何紧凑处理的浮点数组，一个顶点大概就是 24 字节。布局表通常长这样：
| 属性 | 格式 | 偏移量 | 含义 |
|---|---|---|---|
| 位置 | vec3（float×3） | 0 | 裁剪坐标里 xy 用于屏幕位置 |
| 颜色 | vec3（float×3） | 12 | RGB 颜色 |
这里的偏移量非常容易出错。我第一次写布局时把颜色偏移写成了 16，结果整个三角形呈现完全错乱的颜色，因为 GPU 把位置数据的一部分当作颜色读走了。这类错误编译器不会提醒，只能靠肉眼排查。实践上建议在结构体里使用标准的 4 字节对齐，让位置和颜色各占 12 字节；如果需要更紧凑的布局，也可以打包成 BGRA、RGB10A2 等格式，代价是自己要更小心地计算 stride。
2.3 索引缓冲与顶点缓冲的搭配
画一个三角形可以不用索引缓冲，但如果你想画两个相邻三角形，就会发现重复存储公共顶点很浪费。索引缓冲就是为这种情况准备的：顶点缓冲只存不重复的顶点，索引缓冲存每个三角形用哪几个顶点。
顶点数组：A B C D 索引数组：0 1 2 0 2 3第一个三角形用顶点 A、B、C，第二个三角形用 A、C、D，这样 A 和 C 不用拷贝两份。对一个小三角形来说省不了多少，但到了模型几万面、几十万面时，顶点复用能节省大量显存带宽。一个常见的规范是：顶点数少于 65536 时用 16 位索引，超过后用 32 位索引，因为虽然索引缓冲大小不同，但顶点缓冲的索引类型必须和绘制命令匹配，否则会出现“超出范围的访问”，甚至被验证层直接报错。
我在这个阶段的实际心得是：先把顶点布局调正确，再引入索引缓冲。每加一层抽象，都要确认对应的绘制命令没写错。尤其是当你开始用自研的内存分配器管理顶点缓冲时，最容易出现“数据好像传进去了，但绘制时读出来的全是垃圾”的诡异问题。
3. 顶点着色、光栅化与片段着色：管线里最容易被误解的三连站
3.1 顶点着色器：坐标变换的第一站
顶点着色器每个顶点执行一次，它的输入是顶点属性，输出是裁剪空间坐标以及需要传递给后续阶段的自定义属性。对画三角形来说，顶点着色器最简单的写法几乎长得一样：
layout(location = 0) in vec3 inPosition; layout(location = 1) in vec3 inColor; layout(location = 0) out vec3 fragColor; void main() { gl_Position = vec4(inPosition, 1.0); fragColor = inColor; }这段代码做了什么？它把模型空间或用户定义的 NDC 坐标直接当作裁剪空间坐标输出。gl_Position 是顶点着色器必须设置的输出，后续的裁剪、透视除法、视口变换都会基于它执行。
这里有一个常见误解：顶点着色器里做一些坐标平移、缩放很容易，但它不能“增加顶点”。如果你需要把一个三角形细分出更多小三角形，顶点着色器做不到，那得靠几何着色器或细分阶段。顶点着色器更像“每个既有顶点各有一次发言机会”，而不是“往图里添东西的家伙”。
很多初学者会把所有坐标变换都堆到着色器里，比如把模型矩阵、视图矩阵、投影矩阵全放进去。从工作顺序上这没问题，但从工程上更推荐把矩阵统一计算后再传入，因为 CPU 侧更新一个 uniform 的开销远低于每帧重新编译一份着色器或多做无谓的矩阵乘法。我一般会把一个简单相机结构体塞进 uniform 缓冲，然后在着色器里只做一次“模型矩阵 × 顶点”和“视图投影矩阵 × 结果”。
3.2 光栅化：从数学图形到像素集合的“插值器”
顶点着色器输出的是几何信息，下一步光栅化负责把几何“面”转成屏幕上的像素集合。这个过程包含背面剔除、裁剪、透视除法和覆盖检测。对于一张三角形，GPU 会判断每个像素中心是否落在三角形投影范围内，如果在内，这个像素就成为一个“片段”。
光栅化阶段还有一项极其重要的工作：为每个片段生成插值后的顶点属性。你在顶点着色器里输出了一份颜色 three_color，光栅化会根据像素中心在三角形内的重心坐标，插值计算出该像素应该拿到什么样的颜色。这个机制在物理世界里有直观的对应：一个三角形三个顶点分别是红、绿、蓝，那中间区域就会是平滑过渡的混合色。
这里有个容易被忽略的关键：属性插值默认是透视正确的。也就是说，当顶点有不同深度时，插值不是简单的线性插值，而是按深度做了校正。越是做大型场景渲染，越要记得这一点；如果自己手写插值公式，很容易得到错误的纹理坐标。解决办法是尽量把纹理坐标、法线等属性交给管线的插值机制负责，不要自己额外做透视还原。
另外，光栅化模式（填充、线框、点）也在这个阶段生效。调三角形时我经常用线框模式辅助看顶点连接关系，但记得正式渲染时切回填充模式，否则会得到空心三角形。
3.3 片段着色器：每个像素的“最终色”决定者
片段着色器在光栅化之后对每个被三角形覆盖的片段执行。它的核心任务是输出颜色，并可选地对深度、模板、覆盖信息做处理。最简单的片段着色器可能是：
layout(location = 0) in vec3 fragColor; layout(location = 0) out vec4 outColor; void main() { outColor = vec4(fragColor, 1.0); }很多教程会强调“一个片段不一定是一个像素”，因为多重采样抗锯齿（MSAA）会把一个像素拆成多个采样点；早期深度测试也不一定在片段着色器之前执行，所以片段着色器里写 discard 会影响后续的深度写入。这些细节在你只画一个三角形时几乎不会露馅，但你一旦开始做草地、头发、粒子的透明度效果，马上就会遇到“为什么我的透明物体排序不对”之类的问题。
在这个阶段，我还发现一个很实用的小技巧：用片段着色器输出纯色，先验证光栅化和 Render Pass 是否工作正常，再叠加插值颜色。如果纯色能显示，说明管线、Render Pass 都没问题；如果纯色是黑色的，问题多半出在输出格式或者忘写了 clear 值；如果纯色正常但插值颜色不对，再回头查顶点属性和布局。
4. Render Pass：把“清除、绘制、交换”变成一张清晰的执行表
4.1 Render Pass 和 FrameBuffer 的关系：先下菜谱，再备食材
终于聊到标题里反复强调的 Render Pass。我对这个概念的顿悟来自一个类比：Render Pass 和帧缓冲的关系，就像菜谱和备菜的关系。
Render Pass 定义了整个绘制过程使用哪些附件（颜色、深度、模板）、每个附件在开始时怎么处理（是保留旧值还是清除）、结束时怎么处理（是保存到内存还是丢弃），以及绘制过程被拆成几个子通道。而帧缓冲则是附件的具体实例，告诉 GPU 这些附件实际存在哪张图像上。两者配合，才能回答“我要在这个通道里画东西，但第一笔下去时底色是什么”。
Render Pass 创建时指定： attachment[0] = 颜色附件，格式 RGBA8 attachment[1] = 深度附件，格式 D32F 绘制前用 clear color 清空颜色附件，用深度值 1.0 清空深度附件这比早期图形接口要清楚得多。旧式接口里你可能习惯调用一个“清屏”函数，但到底清成什么色、清哪些缓冲其实是隐式约定；现代图形接口则把这些选择全放进 Render Pass 的描述里，让驱动知道“这一帧从哪里开局”。
4.2 attachment 的 load/store 操作：别小看“清除颜色”
Render Pass 配置里最容易忽略的是两个操作：loadOp 和 storeOp。一个决定绘制开始时怎么读取附件的旧内容，一个决定绘制结束后是否把结果写回附件。
- Clear：用指定值把附件清除。画三角形时，颜色附件一般选 Clear，背景色就是 clear color。如果不选 Clear，旧内容会残留，叠加后会产生视觉混乱。
- Load：保留上一帧或前一个子通道写进去的内容，再在其上做增量绘制。比如你的 UI 层想保留 3D 场景，就可以让颜色附件 load 上一轮结果。
- DontCare：告诉 GPU “我不关心开始时里面的内容或结束时要保存内容”，性能最好，但要求你确实不会去读它。
我画三角形时曾经把颜色附件的 loadOp 设成 Load，却发现背景颜色怎么清都清不掉，屏幕像是“和稀泥”一样每次叠一层。后来才知道 loadOp 决定的是让 GPU 先“看见”什么，只有设成 Clear 才会执行清除。调三角形阶段建议一律用 Clear 开头，让每个可控变量都只有一个来源。
这里还可以聊一个性能冷知识：移动端 GPU 对 tile-based 渲染特别敏感，如果一帧开头你用 Clear 把整张颜色附件清掉，后面又把整张附件从主存里加载回来，带宽会被白白浪费。很多引擎的做法是把前一帧结果保留在 on-chip 缓存里，而 Render Pass 的描述直接影响驱动能否做这个优化。所以即使是画三角形，也应该尽量把 load/store 语义写准确，而不是无脑全清全存。
4.3 subpass 和依赖关系：哪些绘制必须按顺序串行
Render Pass 内部可以再分成多个 subpass。一个 subpass 里绑定一组附件，下一个 subpass 可以复用同一批附件，但读写方式可以不同。这样设计的好处是，把需要共享数据的多个渲染步骤放到同一个 Render Pass 里，GPU 可以避免把中间结果从高速缓存写回主存，再在下一个阶段读回来。这种共享能力在延迟光照、后处理、阴影生成里特别常见。
画单个三角形时基本用不到多 subpass，但至少要理解 subpass 之间的依赖关系。比如某一步必须等待刚才生成的深度图写完后才能读取，subpass dependency 就是给这种“先后关系”做约束的。每位刚接触现代图形接口的朋友都会在某一天被“诡异的黑屏”困住，然后发现问题不是着色器写错，而是两个 subpass 没有声明依赖，结果在 GPU 并行执行时读到了半成品。
我的建议是：第一个三角形老老实实只配一个 subpass。不要为了秀操作把后处理和主渲染塞进同一个通道的组合里，那是后面优化时才做的事。先把依赖关系、区分附件在这些细节里练熟，再一点点拆开做多通道渲染。
4.4 结合管线对象：画一个三角形需要准备哪些状态
现在把前面几点收拢。在一个现代图形接口里，画三角形的实际运行步骤看似简单，无非创建资源、创建 Render Pass、创建管线、提交绘制命令，但背后的状态其实是成体系的：
| 状态类别 | 典型内容 | 容易踩坑的点 |
|---|---|---|
| 渲染通道 | 附件格式、清除/保存操作、子通道划分 | 附件格式与帧缓冲不一致 |
| 管线对象 | 两个可编程着色器、顶点输入、图元装配 | 忘记把 Render Pass 与管线一起创建 |
| 视口与裁剪矩形 | 以像素为单位的窗口区域 | 视口比窗口小，三角形显示不全 |
| 光栅化状态 | 填充/线框、剔除开关、顺时针/逆时针 | 顶点绕序写反导致三角形被剔除 |
| 深度/模板状态 | 深度比较函数、是否写入深度 | 深度范围不匹配，三角形被裁掉 |
| 颜色混合状态 | 是否启用混合、混合因子 | 透明物体没关混合导致颜色异常 |
如果一个一个去核对，你会发现每种状态都能直接解释一类渲染异常。这也是我强烈建议不要直接用大而全的框架跑三角形的原因：框架帮你隐藏了这些细节，你也就不会排查问题。
5. 我调通第一个三角形时踩过的坑（附排查思路）
5.1 屏幕一片黑：先从清除颜色和 Render Pass 配置下手
第一次跑通渲染时，我盯着屏幕看了整整五分钟，期望中的彩色三角形没出现，只有纯黑背景。最初的直觉是“是不是顶点着色器写错了”，于是反复查代码，愣是没查出问题。后来一步一步排除，才发现是 Render Pass 描述里颜色附件的 storeOp 配置不匹配，导致绘制结果被丢弃，整张附件内容变成未定义。
这里分享我的排查顺序：先验证窗口本身能否收到正确的清屏颜色，如果背景色都不对，那就不是着色器的问题，而是附件或清除操作的问题；再把三角形退化成纯色，确认顶点着色器输出没有产生 NaN 或非法裁剪坐标；最后才相信片段着色器的逻辑。经过这一次，我养成了一个习惯：每次新建一个渲染目标，先跑一次“只清除颜色，不画任何东西”的冒烟测试，就像写代码先跑空函数一样。
另外一个容易忽略的是颜色空间和输出格式。如果你创建附件格式时用了整型，而着色器输出浮点，编译器通常会报错，但如果用了格式转换不严格的接口，验证层会提示“片段着色器输出类型与附件类型不一致”。所以看到黑屏，先去看验证层输出，它们往往已经用大字暗示了根因。
5.2 三角形看不见或只露半边：坐标、翻转和顶点顺序
当背景色正常、三角形却只出现一半或完全消失时，我第一时间排查的是几何数据。首先是坐标：现代图形接口里 NDC 的 y 轴方向不一定朝上，有些操作系统中视口原点在左上角，如果不做翻转，三角形会上下颠倒或出现在窗口外。
其次是顶点顺序和背面剔除。默认情况下，图形接口会按照“正面”的定义来剔除背面，但正面是顺时针还是逆时针，不会白纸黑字写在屏幕上，而取决于你设定的状态。如果你把剔除的绕序写反，三角形可能被完全剔除，视觉表现就是“什么都没画”。排查方法很简单：先暂时关闭剔除，如果三角形出现了，说明问题就出在绕序上。
最后一个隐藏较深的情况是深度范围。如果你把三角形放到 z=0.0，而深度附件的范围是 [0,1]，但清除深度值设置成了 1.0 以外，那么深度测试可能默认失败。排查思路是把深度测试先关闭，或者把比较函数临时改成“总是通过”，看画面是否恢复。等三角形能正常显示后，再把正确的深度测试加回来。
5.3 颜色不对或插值“闪烁”：顶点属性和索引类型设置
颜色不对的情况我遇到两次。第一次是顶点属性布局里偏移写错，RGB 三个通道被错位读取，三角形整体呈现青紫色；第二次是索引缓冲的索引类型声明为 32 位，但实际数据是 16 位，结果每次都多读半截，三角形边缘出现不稳定的噪声。这两种问题在静态图中都很难一眼发现，尤其当你盯着屏幕看久了，反而会觉得“这个颜色好像本来就该这样”。
排查属性类问题，最直接的手段是打印顶点缓冲的原始字节，对照布局描述逐一解释。另一个好用的技巧是：故意把某个属性设成常量值。比如让所有顶点的颜色都是红色，如果画面显示红色，说明位置数据处理正常，颜色通道只是布局错位；如果画面出现奇怪渐变，说明属性读取顺序确实有问题。这种“二分法”在调试渲染管线时特别有效。
闪烁问题还有一个来源是同步：当你在 CPU 侧更新顶点缓冲，而 GPU 还在上一帧读取数据，就会产生同步竞争。画一个静态三角形时不太会遇到，但只要你想让三角形动起来，就必须考虑内存屏障或使用双缓冲。很多教程会把同步放得很后面，但我想说，等到你亲手把“只有一个三角形的简单 Demo”改成“旋转的三角形”那一刻，同步问题就会出现，提前知道会有这个坑能省不少调试时间。
6. 从三角形往实际渲染框架迈进的下一步
6.1 以“三角形”验收管线：如何写一个最小可运行基座
很多人会把“画三角形”当成一个练习，画完就扔了。我自己的建议是：把这次经历沉淀成一个最小可运行基座，哪怕只包含三个概念——窗口系统接入、Render Pass 配置、三角形模型上传，也要保证它能在任何新机器上快速跑通。这个基座的价值在于，后续你调试任何高级功能时，都能先退回这个三角形，验证“是新增环节错了，还是之前的底座坏了”。
一个典型的最小基座流程是这样：
- 初始化窗口和渲染上下文，创建窗口尺寸对应的交换链。
- 创建颜色附件和深度附件，配置 Render Pass。
- 上传三角形的顶点缓冲和索引缓冲，创建描述顶点布局的缓冲区信息。
- 编译顶点着色器和片段着色器，创建管线对象。
- 每帧调用流程：获取下一张可渲染图像 → 启动 Render Pass → 清除颜色 → 绑定管线 → 提交三角形绘制 → 结束 Render Pass → 提交到窗口呈现。
整个过程若用伪代码描述，大概是接近这样的结构：
for each frame: acquire_image() cmd = begin_command_buffer() begin_render_pass(frame_render_pass, frame_image) clear_color(cmd, attachment0, red) bind_pipeline(triangle_pipeline) bind_vertex_buffer(vertex_buffer) draw(3, 1, 0, 0) end_render_pass(cmd) submit(cmd) present_image()把这个流程跑通之后，你会发现后面加纹理、加绘制多个物体、加相机运动都是“往现有流程里插新步骤”，而不是推倒重来。
6.2 从单对象到多对象：Render Pass 为什么仍然是核心
三角形拓展到多对象，很多人第一时间想到的是“多画几个 draw call”。但更关键的问题依然是 Render Pass 的拆分：你是在同一个通道里连续绘制所有对象，还是在不同通道里绘制？比如先画不透明物体，再画透明物体，最后做后处理——每一步都有对应附件的 load/store 策略；当你需要多重采样抗锯齿时，Render Pass 里甚至要多个颜色附件的 resolve 关系。这些都不是画一个三角形时必需的，但理解 Render Pass 的数据流之后，升级会顺畅得多。
从工程角度看，把绘制流程划分为“几何通道”“光照通道”“后处理通道”，会让性能调优变得可测量。每个通道的耗时都能单独统计，每个附件的带宽开销也一目了然。这就是为什么很多引擎把核心渲染结构直接建立在 Render Pass 之上，而不是“绘制时临时指定渲染目标”。哪怕你只是写个小型框架，我也推荐尽早引入这个分层思维。
6.3 给新手的建议：不要急着跳到 PBR，先走稳三角形
最后想说的其实是学习路径。网络上有大量炫酷的截图和演示，会让人产生一种错觉：直接从光照模型、延迟渲染开始才“有用”。但以我做这个小框架的体会来看，把三角形这条最基础的链路彻底吃透，比堆一堆高级名词更划算。比如我在做透明物体排序时，发现排序错误很多情况下不是排序算法的问题，而是 Render Pass 里混合状态配错、深度写入时机不对，这种问题只有在基础链路足够清楚时才能迅速定位。
如果让我给后来者列一个进阶练习清单，大概是这样：
- 让三角形旋转起来，理解 uniform 和同步。
- 把单色三角形改成顶点渐变色，理解插值。
- 通过键盘移动相机，让三角形跟随视角变化，理解视图矩阵与投影矩阵。
- 给三角形换不同清屏色和混合模式，理解清除与混合的先后关系。
- 在一个 Render Pass 里画两个不同的三角形，理解绘制顺序和状态切换。
走完这几步，你的图形管线基础就已经比“能跑一个 Demo”的状态扎实很多了。我当时在调通所有步骤之后印象最深的一件事是：很多看似高深的概念，不过就是“顶点数据怎么走、沿途每站怎么办、最后落在哪张附件上”三个问题的不同组合。把画三角形的这趟旅程走稳，后面再翻那些渲染文档时，你会发现自己已经有了一个可靠的坐标锚点。
