Chapter 82: Pipeline Mapping to Workflow

OpenGL 的工程难点经常出现在“代码看起来已经按顺序调用，画面却受上一段状态影响”的位置。本章用一个贯穿材料把这种问题拆开：应用准备一批三角形顶点、绑定纹理和 shader，把一个不透明网格绘制到 framebuffer object，再把结果交给后续 pass。读者读完后应能把这一次 draw call 追踪到 vertex input、vertex shader、rasterization、fragment shader、depth/blend 输出，并能判断每一步由哪类 OpenGL 状态决定。

OpenGL 官方资料把 rendering pipeline 描述为由 rendering operation 触发的一串阶段：VAO 提供顶点定义，program 或 program pipeline 提供可编程阶段，随后进入顶点处理、图元装配、裁剪、光栅化、fragment shader 和 per-sample operations。这个顺序可以参考 Khronos OpenGL Wiki: Rendering Pipeline Overview。工程上更需要追踪的是：这些阶段在代码里并不都表现为一个独立对象，很多阶段由“当前上下文里的全局状态”共同决定。

本章的主结论是：OpenGL workflow 应按“声明当前 draw 所需状态 → 执行 draw → 记录状态证据 → 按状态成本组织 draw 顺序”来设计。这样才能把 OpenGL 的状态机风格映射成可维护的渲染流程，把视觉错误、shader 接口错误、framebuffer 输出错误和性能开销分别定位到对应阶段。

82.1 OpenGL 渲染管线的各阶段映射说明

OpenGL draw call 的输入由一组当前状态共同组成，单个函数调用只暴露其中一小部分。以一个 textured mesh pass 为例，CPU 侧先绑定 VAO、program、纹理、sampler、uniform buffer、framebuffer，再调用 glDrawElements。这一次调用只显式写了一个函数名，但 GPU 侧会读取一组已经绑定好的状态，并沿 pipeline 产生最终颜色和深度输出。

下面的图只覆盖本章贯穿材料中的不透明网格路径：顶点来自 VBO/IBO，shader 是 vertex + fragment，输出进入一个带 depth attachment 和 color attachment 的 FBO。tessellation、geometry shader、transform feedback 和 compute path 暂时不进入本章主线。

这条路径的核心点在于：OpenGL 中很多 pipeline 阶段通过“绑定时的当前对象”获得输入。VAO 决定 vertex input 如何从 buffer 中解码；program 决定 vertex shader 和 fragment shader 如何解释 attribute、uniform、varying；FBO 决定 fragment 输出写到哪里；depth、stencil、blend、color mask 决定 fragment 输出是否更新目标 attachment。draw call 本身更像是触发器，它让当前状态组合开始生效。

Pipeline 位置	OpenGL 侧主要状态	贯穿材料中的判断问题	常见画面症状
Vertex input	VAO、VBO、IBO、attribute format、stride、offset	顶点属性是否按 shader 输入读取	模型拉伸、顶点爆炸、UV 错位
Vertex shader	program、uniform、UBO、attribute location	顶点是否进入正确 clip space	模型消失、位置反转、深度异常
Primitive assembly / clipping	index buffer、primitive mode、front face、cull state	图元是否按期望组成三角形并通过裁剪	面片缺失、正反面错误
Rasterization	viewport、scissor、polygon mode、sample state	三角形是否覆盖目标像素或 sample	只渲染局部区域、线框异常
Fragment shader	texture binding、sampler、varying、uniform	每个 fragment 是否计算出正确颜色	黑色、粉色、贴图通道错乱
Per-sample output	depth/stencil/blend、color mask、draw buffers、FBO attachment	fragment 是否写入正确 attachment	被遮挡、透明错、MRT 缺通道

对这个表的使用方式是从输出倒推输入。若画面完全没有三角形，先检查 FBO 是否完整、viewport 是否覆盖目标区域、depth test 是否把 fragment 全部淘汰，再回到 VAO 和 program。若几何形状出现但贴图错误，优先检查 texture unit、sampler uniform、UV attribute 和 fragment shader 的采样路径。若颜色正确但透明叠加异常，问题更可能落在 blend state、depth write、draw order 和目标 attachment 格式。

一个最小 draw setup 可以写成下面这样。它的目的在于固定“当前状态组合触发 pipeline”的路径，完整引擎代码中的窗口、资源创建和错误处理留给外围模块。

// 简化示例：假设对象已经创建完成，下面只展示一次 draw 前的状态声明顺序。
glBindFramebuffer(GL_FRAMEBUFFER, sceneFbo);
glViewport(0, 0, sceneWidth, sceneHeight);

glEnable(GL_DEPTH_TEST);
glDepthMask(GL_TRUE);
glDisable(GL_BLEND);

glUseProgram(meshProgram);
glBindVertexArray(meshVao);

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, albedoTexture);
glBindSampler(0, linearSampler);
glUniform1i(albedoLocation, 0);

glBindBufferBase(GL_UNIFORM_BUFFER, 0, cameraUbo);
glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_INT, nullptr);

这段代码中，glDrawElements 只提供 primitive mode、index 数量、index 类型和起始偏移。它没有重新声明 shader、FBO、depth、blend、纹理和 uniform buffer。工程工作流必须把 draw 前的状态声明当成 draw 的一部分管理，因为任何一个上游 pass 留下的绑定都可能被当前 draw 读取。

映射 pipeline 时还要区分对象状态和上下文状态。VAO 保存 attribute format、enabled attribute 和相关 buffer 绑定；texture object 保存纹理存储、参数和数据；sampler object 保存采样状态；program 保存链接后的 shader 接口和部分 uniform 状态；当前 context 则保存当前绑定、enable flag、viewport、depth/blend 等状态。排查时把这些层级分清，可以减少“随机改一堆 GL 调用”的调试成本。

82.2 状态机风格命令与固定功能兼容性分析

OpenGL 的状态机风格来自它把大量渲染决策放在当前 context 中。应用调用 glEnable(GL_DEPTH_TEST) 后，后续 draw 会持续使用 depth test，直到应用显式关闭或修改相关状态。glBindTexture(GL_TEXTURE_2D, tex) 会改变当前 texture binding point，后续采样会通过 shader 中的 sampler uniform 找到对应 texture unit。状态持续存在，是 OpenGL 工作流需要额外约束的根源。

把状态分层管理时，可以使用四类边界。第一类是 context-global state，例如 viewport、scissor、blend enable、depth test、current program、current FBO。第二类是 binding point，例如 GL_ARRAY_BUFFER、GL_UNIFORM_BUFFER、texture unit、sampler unit。第三类是 object state，例如 VAO 的 attribute 描述、texture 的 storage 和 filtering、FBO 的 attachment。第四类是 shader interface state，例如 attribute location、uniform location、uniform block binding 和 fragment output location。

贯穿材料中的一次 draw 可以按下面的状态账本描述。这个账本的作用是把“当前 draw 依赖什么”写成可检查对象，让状态集中出现在 pass、material、geometry 和 resource 字段中。

状态层级	需要记录的字段	当前 draw 的稳定写法
Pass state	FBO、viewport、clear、depth/stencil/blend policy	pass 开始时统一设置，并在 pass 描述中保存
Material state	program、textures、samplers、blend mode、cull mode	按 material key 绑定，变更后更新 state cache
Geometry state	VAO、index buffer、primitive mode、index type	mesh draw item 持有并在 draw 前声明
Resource state	UBO binding、SSBO binding、texture unit、image unit	由 resource binder 统一分配 binding slot
Debug state	object label、debug group、draw marker	捕获工具和 debug callback 能读到人类可识别名称

固定功能兼容性会让这个账本更难维护。compatibility profile 中可能出现 glBegin、glMatrixMode、glTexEnv、client-side array、fixed-function lighting 等旧路径；core profile 更强调 buffer object、VAO、shader program 和显式 framebuffer object。旧固定管线把矩阵、材质、光照和纹理组合放入更多隐式状态，现代 shader path 则把这些输入搬到 attribute、uniform、UBO 和 texture 绑定中。

工程判断应先确定项目使用的是 core profile 还是 compatibility profile。若项目目标是教学、旧 CAD 软件、遗留编辑器或跨平台维护已有 OpenGL 代码，compatibility profile 可能仍有价值；若目标是接近现代图形 API 的资源组织方式，core profile 更容易和 Vulkan、Metal、Direct3D 的 pipeline 思维对齐。两种 profile 的共同点是 context state 持续存在，差异在于旧固定功能路径会引入更多历史状态和更弱的 shader 接口约束。

implicit dependency 也要单独纳入工作流。OpenGL 驱动会根据当前绑定对象、资源使用方式和命令顺序推导依赖关系。比如当前 pass 写入一个 texture attachment，后续又把同一个 texture 绑定给 fragment shader 采样，应用需要在 pass 结构中明确“先完成写入，再进入采样路径”。不同驱动对 hazard 的诊断能力存在差异，渲染框架应通过资源生命周期和 pass graph 约束这类依赖。

下面的简化结构展示了状态机 API 如何被包进一个更稳定的 draw item。它的重点是把“本次 draw 需要的状态”变成数据，让调用者直接提交完整状态需求。

struct MeshDrawItem {
    GLuint framebuffer = 0;
    GLuint program = 0;
    GLuint vao = 0;
    GLuint albedoTexture = 0;
    GLuint cameraUbo = 0;
    GLsizei indexCount = 0;
    bool depthTest = true;
    bool blend = false;
};

void drawMeshItem(const MeshDrawItem& item) {
    glBindFramebuffer(GL_FRAMEBUFFER, item.framebuffer);
    item.depthTest ? glEnable(GL_DEPTH_TEST) : glDisable(GL_DEPTH_TEST);
    item.blend ? glEnable(GL_BLEND) : glDisable(GL_BLEND);

    glUseProgram(item.program);
    glBindVertexArray(item.vao);
    glBindBufferBase(GL_UNIFORM_BUFFER, 0, item.cameraUbo);

    glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_2D, item.albedoTexture);

    glDrawElements(GL_TRIANGLES, item.indexCount, GL_UNSIGNED_INT, nullptr);
}

这种封装的收益来自可审计性。review 代码时可以直接检查 MeshDrawItem 是否覆盖 FBO、program、VAO、resource binding 和输出状态。若一个 draw 依赖外部隐式状态，例如“调用者已经绑定了某个 sampler”，它就应该被提升为 draw item 的字段或 material 的字段。这样才能把 OpenGL 的状态机命令收束成稳定工作流。

82.3 Shader 管线与 GLSL 工作机制

GLSL 工作机制需要分成编译、链接、绑定和执行四段。shader source 先进入 shader object，通过 glCompileShader 编译；多个 shader object 再 attach 到 program object，并通过 glLinkProgram 形成可执行 program。Khronos Wiki 的 Shader Compilation 说明了编译状态、链接状态、info log、program pipeline 和 program binary 等路径。工程上要把 compile error、link error、runtime binding error 分成三类处理。

在本章贯穿材料中，vertex shader 接收 position、normal、UV，把 position 变换到 clip space，并把 UV 传给 fragment shader。fragment shader 读取 sampler uniform 对应的 texture unit，采样 albedo texture，输出到 color attachment。shader 的输入输出通过 OpenGL 的 program link、location、interface block 和当前绑定状态共同连接，C++ 类型系统只负责应用侧数据组织。

#version 330 core

layout(location = 0) in vec3 aPosition;
layout(location = 1) in vec2 aUv;

layout(std140, binding = 0) uniform CameraBlock {
    mat4 uViewProj;
};

out vec2 vUv;

void main() {
    vUv = aUv;
    gl_Position = uViewProj * vec4(aPosition, 1.0);
}

#version 330 core

in vec2 vUv;
layout(binding = 0) uniform sampler2D uAlbedo;
layout(location = 0) out vec4 outColor;

void main() {
    outColor = texture(uAlbedo, vUv);
}

这两段 shader 展示了三条接口链。第一条是 VAO attribute 到 vertex shader input：layout(location = 0) 要与 VAO 中 position attribute 的 index 对齐。第二条是 uniform block 到 UBO binding：binding = 0 要与 glBindBufferBase(GL_UNIFORM_BUFFER, 0, cameraUbo) 对齐。第三条是 sampler 到 texture unit：binding = 0 或 glUniform1i 要与 GL_TEXTURE0 绑定的 texture 对齐。任何一条链断开，pipeline 仍然可能执行，但输出会落到错误画面。

shader link 阶段重点检查 stage 之间的接口。比如 vertex shader 输出 vUv，fragment shader 输入也叫 vUv 且类型一致，link 才能建立 varyings 的传递。若两个 stage 中同名 uniform block 的成员顺序或类型不一致，link 会失败。若 attribute location 与 VAO 格式不匹配，link 可能成功，但运行画面会错，因为 OpenGL 只知道 shader 需要某个 location 的输入，无法保证应用上传的数据语义正确。

uniform 的更新策略也会影响 workflow。少量 per-draw 参数可以使用普通 uniform；相机、灯光、材质数组这类跨多个 draw 复用的数据更适合放入 UBO；大数组或可写数据可能进入 shader storage buffer object。对 OpenGL 工作流来说，选择哪类资源不只影响 shader 写法，也影响绑定频率、缓存命中、driver validation 和调试证据。

program pipeline 是更分离的 shader 组合方式。它允许把不同 stage 的 separable program 组合到 pipeline object 中，使 vertex stage 和 fragment stage 可独立替换。它适合 shader 组合数量较多的框架，但也增加了接口验证和状态追踪成本。对多数 OpenGL 工程，先把普通 program 的 compile/link/log/resource binding 工作流做稳定，再引入 program pipeline 更可控。

shader 管线的排查顺序可以固定为五步。先读取 compile log，确认单个 shader source 合法；再读取 link log，确认 stage interface 合法；然后用 program introspection 或约定表检查 attribute、uniform、block 和 sampler binding；接着用最小纹理或常量输出替换 fragment shader，验证 rasterization 和输出状态；最后恢复材质采样路径，检查 texture unit、sampler、format 和 color space。这个顺序从“shader 本身合法”推进到“shader 与 OpenGL 状态连接正确”。

82.4 调试 Render State 的有效方法

Render state 调试的目标是找到“当前 draw 实际使用了哪些状态”。OpenGL 代码经常把状态设置分散在 pass、material、mesh、utility function 和 legacy helper 中，肉眼顺着源码读很难还原某个 draw 的最终状态。有效方法是把 debug callback、state dump、frame capture 和 minimal repro 组合使用，每个工具回答一个不同问题。

debug callback 负责把 driver 发现的错误、性能提示和 shader 编译链接问题送回应用。KHR_debug 在 OpenGL 4.3 成为 core feature，并提供 debug message、debug group、object label 等能力；可以参考 Khronos OpenGL Wiki: Debug Output。工程上应在 debug context 中启用 GL_DEBUG_OUTPUT，注册 glDebugMessageCallback，并为 FBO、texture、buffer、program、VAO 设置可读名称。

void GLAPIENTRY onGlDebugMessage(GLenum source,
                                  GLenum type,
                                  GLuint id,
                                  GLenum severity,
                                  GLsizei length,
                                  const GLchar* message,
                                  const void* userParam) {
    logOpenGlMessage(source, type, id, severity, std::string(message, length));
}

void setupDebugOutput() {
    glEnable(GL_DEBUG_OUTPUT);
    glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS);
    glDebugMessageCallback(onGlDebugMessage, nullptr);
    glDebugMessageControl(GL_DONT_CARE,
                          GL_DONT_CARE,
                          GL_DEBUG_SEVERITY_NOTIFICATION,
                          0,
                          nullptr,
                          GL_FALSE);
}

这段代码的作用是让错误靠近触发点。若 glBindFramebuffer 后 FBO 不完整、shader link 失败、使用 deprecated behavior 或触发 driver performance warning，debug callback 通常比散布 glGetError 更容易定位。同步输出会增加调试开销，release build 应关闭或降级为可控日志。

state dump 回答“应用以为当前 draw 使用什么状态”。它可以在 draw wrapper 中记录 program、VAO、FBO、viewport、depth/blend/cull、texture units、UBO binding、draw buffers 和 object labels。state dump 不需要记录所有 OpenGL 状态，优先记录会影响本章贯穿材料输出的状态。记录量过大时，调试日志会淹没关键差异。

struct DrawStateSnapshot {
    GLuint framebuffer;
    GLuint program;
    GLuint vertexArray;
    GLint viewport[4];
    bool depthTest;
    bool blend;
    GLuint texture2DUnit0;
    GLuint uniformBuffer0;
};

RenderDoc 这类 frame debugger 回答“GPU 捕获到的当前 draw 状态是什么”。OpenGL frame capture 可以查看 draw call 列表、pipeline state、shader source、texture viewer、buffer viewer 和 framebuffer 输出。使用捕获工具时，先给对象命名，再用 debug group 把 pass 和 draw 分组；这样 draw list 里会出现 OpaquePass / MeshBody / MaterialBrick 这类路径，工程人员可以直接定位 pass、mesh 和 material。RenderDoc 的项目文档入口可见 RenderDoc Documentation。

minimal repro 回答“去掉工程复杂度后问题是否仍存在”。如果捕获显示 texture unit 绑定正确，但画面仍然黑，可以构造一个只渲染单个三角形、单张 2D 纹理、一个 FBO 的独立程序。若 repro 正常，问题更可能在引擎的状态复用、资源生命周期或 draw 排序。若 repro 也失败，问题通常落在 shader、纹理格式、FBO 配置或平台 profile 差异。

下面是一个可复用的状态污染排查顺序。它按输出阶段向输入阶段回退，适合处理“上一段 pass 改了状态，当前 draw 被影响”的问题。

1. 先固定输出目标：检查当前 FBO、draw buffers、viewport、scissor、clear 结果和 color/depth attachment。
2. 再固定 per-sample 状态：检查 depth test、depth func、depth write、stencil、blend、color mask 和 sample count。
3. 然后固定 shader 输出：把 fragment shader 改成常量色，确认 rasterization 和输出路径有效。
4. 接着固定 vertex 输入：检查 VAO attribute enable、format、stride、offset、index type 和 primitive mode。
5. 最后恢复资源采样：检查 texture unit、sampler uniform、sampler object、texture completeness、format 和 mipmap。

这个顺序的价值在于它不会一开始就陷入 shader 或 asset 细节。OpenGL 的状态错误常出现在输出端，例如仍然绑定上一帧的 FBO、viewport 还是 shadow map 尺寸、depth mask 被透明 pass 关闭、blend 仍然开启。先确认输出路径，可以快速把问题从“GPU 没画”缩小到“画了但被状态拦截”或“数据本身进入错误阶段”。

82.5 性能考量：平衡状态切换与批次化策略

OpenGL 性能优化要把状态切换成本和 draw batching 放在同一个 workflow 里判断。CPU 侧调用 OpenGL 会触发 driver validation、状态变更记录、命令构建和资源依赖分析；GPU 侧则受 shader 执行、纹理采样、带宽、overdraw 和 framebuffer 输出影响。减少状态切换主要降低 CPU/driver 侧开销，批次化则可能同时降低 draw count、resource binding 次数和验证成本。

贯穿材料中的 opaque mesh pass 可以按“结果约束优先，状态成本次之”的顺序排序。先按 framebuffer/pass 分组，因为不同输出目标之间通常存在资源依赖；再按 transparency policy 分组，因为透明物体常需要保持特定 draw order；然后按 program、blend/depth state、texture set、VAO 或 material key 排序。这个顺序把视觉正确性放在 draw 重排之前。

一个常见排序 key 可以这样设计。它只用于不透明物体，透明物体还要按相机距离或材质策略处理。

struct OpaqueSortKey {
    uint32_t passId;
    uint32_t programId;
    uint32_t depthBlendStateId;
    uint32_t textureSetId;
    uint32_t vaoId;
    uint32_t materialId;
};

排序 key 的作用是让相邻 draw 尽量复用 program、texture、sampler、VAO 和 depth/blend state。比如连续绘制同一个 shader、同一组纹理和同一个 VAO 的对象，driver validation 和 binding 命令数量会下降。若每个对象都切换 program、texture、FBO 和 blend state，CPU 侧提交会变碎，GPU 侧也可能因为 pipeline 状态频繁变化而降低吞吐。

state cache 是 OpenGL batching 的基础。它记录当前已经绑定的 program、VAO、FBO、texture、sampler 和 enable flag；当下一个 draw 请求相同状态时，跳过重复绑定。这个 cache 的目标是把状态变更集中到一个可审计入口，降低 redundant state change，并保持 OpenGL context 仍然作为最终执行状态。

class GlStateCache {
public:
    void useProgram(GLuint program) {
        if (currentProgram == program) return;
        glUseProgram(program);
        currentProgram = program;
    }

    void bindVertexArray(GLuint vao) {
        if (currentVao == vao) return;
        glBindVertexArray(vao);
        currentVao = vao;
    }

private:
    GLuint currentProgram = 0;
    GLuint currentVao = 0;
};

这种 cache 有一个边界：它只能管理所有调用都经过它的状态。如果工程中仍有 utility function 直接调用 glBindTexture、glDisable(GL_DEPTH_TEST) 或 glBindFramebuffer，cache 里的记录会与真实 OpenGL context 分离。稳定做法是把 raw GL 调用限制在 backend 层，其他模块只提交 draw item、material state 和 pass state。

批次化也会改变资源路径。把多个 mesh 合并到同一个 VBO/IBO 可以减少 draw call 和 VAO 切换，但会增加构建 buffer、更新局部数据、处理材质边界和剔除粒度的成本。使用 instancing 可以把同一 mesh 的多次绘制合并成一次 draw，但它要求 shader 读取 per-instance data，并让 instance buffer 的更新路径变成新的性能变量。使用 texture array 或 bindless-like strategy 可以降低 texture binding，但会引入格式一致性、索引管理和平台能力边界。

对 OpenGL 项目，性能检查顺序可以固定为：先测 CPU submit 时间和 draw count，再看 program/texture/FBO/VAO 切换数量，然后检查 shader cost、texture bandwidth、overdraw 和 framebuffer bandwidth。若 CPU submit 占主导，优先做 batching、state cache、material sorting 和 multi-draw。若 GPU fragment cost 占主导，减少状态切换不会显著改善帧耗时，应回到 shader、overdraw、render target format 和 texture sampling。

最终工作流可以写成一条闭环：pass builder 收集 draw item，sorter 在视觉约束内排序，state cache 生成最小状态变更，debug marker 标记 pass/draw，profiler 或 frame capture 复查成本。这个闭环让 OpenGL 状态机保留其即时提交特性，同时把工程层面的可维护性、可调试性和性能判断拉回同一套数据结构。

最小自检任务

给定一个 OpenGL 小程序：第一段 shadow pass 使用 1024 × 1024 的 FBO 和 viewport，只写 depth；第二段 scene pass 绑定默认 framebuffer 后绘制 textured mesh。现在 scene pass 画面只出现在窗口左下角的一块区域，且 mesh 有时全黑。请按本章方法判断最可能的状态问题，并给出排查顺序。要求把问题分别映射到 pipeline 阶段、OpenGL 状态、可观察证据和修复动作。

答案要点

画面只出现在左下角的一块区域，最先映射到 rasterization 和 framebuffer output 之间的状态。shadow pass 使用 1024 × 1024 viewport 后，scene pass 若没有重新设置窗口尺寸 viewport，后续 rasterization 仍按旧 viewport 产生 window-space fragment，所以默认 framebuffer 只有对应区域被写入。排查时先在 scene pass 开始处记录当前 framebuffer、viewport、scissor 和 draw buffers，再在 frame capture 中查看 scene draw 的 pipeline state。修复动作是在 scene pass 绑定默认 framebuffer 后立即设置 glViewport(0, 0, windowWidth, windowHeight)，并按需要设置 scissor。

mesh 有时全黑，应先把 fragment shader 改成常量色区分几何路径和采样路径。若常量色正常，问题落到 fragment shader 的 texture binding、sampler uniform、texture completeness、color space 或 mipmap。若常量色也黑，再检查 depth test、depth write、color mask、blend state 和 FBO attachment。由于 shadow pass 只写 depth，scene pass 还要确认 color mask 已打开，fragment shader 输出写入默认 framebuffer 的 color buffer，depth func 与 depth clear 值匹配。

完整排查顺序是：scene pass 开始处重设 FBO、viewport、scissor、clear 和 draw buffers；接着重设 depth/blend/color mask；然后用常量 fragment shader 验证 rasterization 与输出路径；再检查 VAO、program link、sampler uniform、texture unit 和 sampler object；最后把 shadow pass 和 scene pass 加上 debug group，在 RenderDoc 中比较两个 draw 的 pipeline state。这个顺序把问题从输出状态逐步推进到 shader 和资源绑定，能够同时覆盖“窗口区域错误”和“采样全黑”。

本章知识点总结

• Draw 触发：OpenGL 的 draw call 会读取当前 VAO、program、FBO、资源绑定和输出状态，并触发完整 pipeline。
• 阶段映射：vertex input、shader、rasterization、fragment 输出和 per-sample operations 都能映射到具体 OpenGL 状态。
• 状态持续：context 中的 enable flag、binding point、viewport 和当前 program 会持续影响后续 draw。
• 对象分层：VAO、texture、sampler、program、FBO 和 context-global state 应分层记录和排查。
• Profile 边界：core profile 更接近现代 shader 工作流，compatibility profile 会引入更多固定功能历史状态。
• Shader 链接：GLSL 工作流需要区分 compile、link、binding 和 execution 四段错误来源。
• 接口对齐：attribute location、uniform block binding、sampler unit 和 varying 类型共同决定 shader 与 OpenGL 状态是否连接正确。
• 调试入口：debug callback、state dump、frame capture 和 minimal repro 分别回答 driver 消息、应用期望、GPU 捕获状态和最小复现问题。
• 状态污染：FBO、viewport、depth mask、blend、color mask 和 texture unit 是跨 pass 残留问题的高频来源。
• 排序约束：draw 排序先满足输出目标、透明策略和资源依赖，再按 program、texture、VAO 和材质降低状态切换。
• State cache：state cache 把重复绑定过滤到 backend 层，但它要求 raw GL 调用入口集中。
• 性能判断：状态切换优化主要服务 CPU submit 和 driver validation，GPU fragment 或 bandwidth 瓶颈需要回到 shader 与资源路径分析。