Chapter 81: OpenGL State Machine and Context Lifecycle

读完本章，读者应能追踪一个 OpenGL 三角形从窗口上下文创建、函数入口加载、对象绑定、draw call 提交到默认 framebuffer 呈现的完整路径，并能判断一次渲染错误属于上下文生命周期问题、状态绑定问题、shader / buffer / texture 输入问题，还是版本与 profile 不匹配问题。

OpenGL 的工程难点集中在“当前状态”这件事上。一个 glDrawArrays 调用表面上只有图元类型、起点和顶点数量，实际会读取当前 context 中的 program、vertex array object、buffer、texture unit、sampler、framebuffer、viewport、depth / blend / rasterizer flag 等多组状态。画面正确性来自这些状态在 draw 之前形成一致组合；画面错误通常来自某个状态在上一段代码、上一帧或另一条初始化路径中被改写。

本章使用一个最小窗口三角形作为贯穿材料：程序创建 OpenGL context，加载函数指针，建立 VAO / VBO，编译 shader，绑定 program 和 framebuffer，然后调用 draw 并 swap。这个例子足够小，可以把 OpenGL 的状态机、上下文生命周期和版本兼容边界放到同一条可观察数据路径中解释。

本文采用 OpenGL 4.6 Core Profile Specification 作为语义边界。窗口创建、像素格式选择和 swap 由 WGL、GLX、EGL、CGL 或 GLFW / SDL 这类窗口系统绑定完成；OpenGL 规范描述的是 context 已经存在之后，GL 命令如何解释状态、对象和渲染命令。

81.1 OpenGL State Machine and Compatibility Contract

OpenGL 状态机可以理解为“当前 context 中一组可变记录的集合”。应用调用 glBindBuffer、glUseProgram、glBindTexture、glEnable、glViewport 这类命令时，命令会改变当前 context 的状态记录；应用调用 glDrawArrays 或 glDrawElements 时，GL 会按当前状态解释顶点输入、shader、纹理采样、framebuffer 输出和测试混合规则。

这个模型让 OpenGL API 具有很短的命令形式。draw call 本身无需携带完整 pipeline 描述，因为大量信息已经提前写入当前状态。代价是状态依赖分散在调用序列中，调试时需要重建“draw 发生时 context 中到底有哪些状态”。在大型程序里，渲染模块、材质模块、调试绘制模块和 UI 模块共用同一个 context 时，状态污染会直接表现为错纹理、黑屏、深度测试异常或 blend 结果异常。

Context 是 OpenGL 状态机的承载对象。它包含当前状态、对象命名空间、对象绑定点、错误状态、debug 输出设置，以及与窗口系统提供的默认 framebuffer 的连接。一个进程可以创建多个 context；具体 API 由平台决定，例如 Windows 上常见 WGL，Linux 桌面常见 GLX 或 EGL，macOS 使用 CGL / NSOpenGL，跨平台工程常用 GLFW 或 SDL 做封装。OpenGL 命令只作用于当前线程中被设为 current 的 context。

这条线程关系是生命周期判断的第一条边界。创建 context 之后，需要先把它设为 current，再加载 OpenGL 函数指针，再调用 GL 命令。函数 loader 例如 GLAD、GLEW 或 glad2 会根据当前 context 暴露的版本与 extension 获取入口地址。loader 发生在 current context 之前时，很多现代函数指针会保持空值；后续调用可能直接崩溃，也可能在封装层报错。

下面的图把本章贯穿材料中的状态变化压缩成一条路径。图中每个节点都对应后续小节要检查的对象。

Compatibility contract 指 OpenGL 在不同版本、profile 和 extension 之间维持的语义承诺。对工程判断最有影响的是 core profile 与 compatibility profile。Core profile 保留现代可编程管线需要的对象、shader 和 framebuffer 路径，并移除旧固定功能接口；compatibility profile 继续提供部分旧接口，使早期 OpenGL 代码可以在新驱动上运行。

这种兼容性使旧项目维护成本降低，也使状态空间膨胀。固定功能矩阵栈、立即模式绘制、客户端数组、可编程 shader、VAO、FBO、UBO 等对象可能在同一本资料或同一个历史项目里同时出现。写新工程时应先把 profile 固定为 core profile，再围绕 VAO、VBO、program、texture、FBO 和 debug callback 建立状态边界。维护旧工程时应先识别它依赖了哪些 compatibility 行为，再决定迁移顺序。

Debug context 是状态机调试的入口之一。OpenGL 4.6 规范的 Debug Output 章节说明，debug output 可以报告错误、未定义行为、实现相关性能提示和应用插入的消息。创建 debug context 后启用 GL_DEBUG_OUTPUT，再注册 glDebugMessageCallback，可以把许多“某个状态组合无效”的问题提前暴露为回调消息。这个回调回答的是“GL 在解释命令时看到了什么问题”，它无法替应用证明当前材质系统或 frame graph 的高层意图正确。

工程中可以把 OpenGL 状态分为四类来管理。第一类是 context 级状态，例如 current context、debug output、错误队列和默认 framebuffer 连接。第二类是对象状态，例如 buffer storage、texture image、sampler 参数、program link 结果和 framebuffer attachment。第三类是绑定状态，例如当前 VAO、当前 program、当前 active texture unit、当前 draw framebuffer。第四类是 pipeline flag，例如 depth test、blend、cull face、viewport、scissor 和 color mask。一次 draw 的正确性来自这四类状态同时匹配。

状态机模型的稳定使用方式是把“谁负责写状态”和“谁负责恢复状态”明确下来。渲染器可以维护 state cache，记录当前已绑定的 program、VAO、texture、framebuffer 和 enable flag；每个 pass 只提交缺失或变化的状态。调试代码、UI 代码和临时可视化代码进入同一 context 时，应通过明确的 render pass 包装来恢复关键状态。这里的目标是让每个 draw call 的输入来源可追踪，并把状态恢复控制在明确的 pass 边界内。

81.2 OpenGL Pipeline Mapping to Draw State

OpenGL 的 draw state 是渲染管线的当前配置快照。一个三角形 draw 需要顶点数据、顶点解释规则、shader 程序、uniform / texture 输入、rasterizer 状态、depth / stencil / blend 状态和输出 framebuffer。OpenGL 不把这些配置集中放入一个 pipeline object；它通过多个绑定点和 enable flag 组合出当前管线。

对 glDrawArrays(GL_TRIANGLES, 0, 3)，顶点数量来自第三个参数，顶点属性来源来自当前 VAO，顶点 shader 来源来自当前 program，uniform 值保存在 program 关联状态中，纹理采样通过 sampler uniform 指向 texture unit，颜色输出写入当前 draw framebuffer。官方 glDrawArrays reference page 给出命令语义；工程排查时需要把它展开成完整状态读取链。

下表把常见 OpenGL 调用映射到管线阶段。这张表用于记录一次 draw 的状态证据。

管线位置	OpenGL 状态或对象	典型命令	错误表现
顶点输入	VAO、vertex attrib format、VBO 绑定	`glBindVertexArray`、`glVertexAttribPointer`、`glEnableVertexAttribArray`	顶点坐标错乱、黑屏、属性全为默认值
Shader 执行	program、shader link、uniform	`glUseProgram`、`glUniform*`	shader 未执行、颜色固定、矩阵错误
纹理采样	texture object、texture unit、sampler uniform	`glActiveTexture`、`glBindTexture`、`glUniform1i`	采样到白色、黑色、旧纹理或 mip 异常
光栅与测试	viewport、cull、depth、stencil、blend	`glViewport`、`glEnable`、`glBlendFunc`	画面被裁掉、深度顺序错、透明混合异常
输出目标	default framebuffer 或 FBO	`glBindFramebuffer`、`glDrawBuffers`	画到离屏目标、FBO incomplete、屏幕无结果

VAO 是 core profile 中顶点输入状态的核心容器。它保存每个 attribute 的启用状态、格式描述、stride、offset，以及 attribute 指向的 buffer 关系。常见错误是在没有绑定 VAO 的情况下设置 attribute，或者在绑定错误 VAO 时调用 glVertexAttribPointer。这种错误会在 draw 时表现为输入缺失；真正的原因发生在初始化或状态录制阶段。

下面的最小代码展示了一个三角形 draw 的关键状态写入。示例省略窗口创建和错误检查，只保留 draw state 的依赖顺序；真实工程应检查 shader compile / link 日志，并在 debug context 下接收回调。

GLuint vao = 0;
GLuint vbo = 0;
GLuint program = createTriangleProgram();

const float vertices[] = {
    -0.6f, -0.4f, 0.0f,
     0.6f, -0.4f, 0.0f,
     0.0f,  0.6f, 0.0f,
};

glGenVertexArrays(1, &vao);
glBindVertexArray(vao);

glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);
glEnableVertexAttribArray(0);

glUseProgram(program);
glViewport(0, 0, framebufferWidth, framebufferHeight);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glDrawArrays(GL_TRIANGLES, 0, 3);

这段代码证明的是“OpenGL draw 依赖当前状态组合”。glBindVertexArray 先选择 attribute 状态容器，glBindBuffer 让后续 attribute 指针记录 buffer 来源，glVertexAttribPointer 写入 attribute 0 的解释规则，glUseProgram 选择 vertex / fragment shader，glBindFramebuffer 选择输出目标。draw 调用本身只触发读取，不补齐缺失状态。

Program 对象承载 shader 阶段和接口匹配结果。glUseProgram 选择当前 program；program 必须完成 link，vertex shader 输出需要和 fragment shader 输入匹配，uniform 需要按 location 或 block binding 写入。对于一个输出纯色三角形的例子，fragment shader 可以不采样纹理；一旦 shader 中出现 sampler，当前 texture unit 与 sampler uniform 的关系就进入 draw state。

Texture 状态具有两层间接关系。应用先通过 glActiveTexture(GL_TEXTURE0 + unit) 选择 active texture unit，再用 glBindTexture 把 texture object 绑定到该 unit 的目标上，最后用 glUniform1i 告诉 sampler uniform 读取哪个 unit。很多“材质串图”来自 unit 编号、texture 绑定和 uniform 值三者错配。排查时应先固定一个 draw，只绑定一个纹理单元，再确认 sampler uniform 值和当前 unit 一致。

Framebuffer 状态决定 draw 的输出位置。窗口系统通常提供默认 framebuffer，也就是绑定名称 0 时使用的目标；应用也可以创建 FBO，将 color / depth / stencil attachment 指向 texture 或 renderbuffer。OpenGL 规范把默认 framebuffer 的创建交给窗口系统绑定，FBO 的完整性由 GL 命令检查。一个 draw 可以完全正确执行，同时写入当前绑定的离屏 FBO；屏幕黑色只是因为后续没有把 FBO 内容拷贝、采样或 blit 到默认 framebuffer。

从管线角度排查一个 draw，应按固定顺序读取证据。先看当前 context 是否 current，函数入口是否有效；再看 framebuffer 是否完整、viewport 是否覆盖目标区域；再看 program 是否 link 成功并被 use；再看 VAO attribute 是否启用并指向有效 buffer；再看 uniform、texture unit 和 sampler 是否匹配；最后看 depth、stencil、cull、blend、color mask 这类测试与输出状态。这个顺序从生命周期到输出目标，再回到输入和中间状态，能减少在 shader 代码里盲目修改的时间。

81.3 OpenGL 与现代图形需求的适配性分析

OpenGL 适合用来建立渲染管线直觉，因为它把 draw state 的每一类对象都暴露为短命令：绑定 buffer、绑定 texture、绑定 program、设置 viewport、调用 draw。学习者可以在几百行代码内看到 CPU 数据如何变成 vertex shader 输入、fragment shader 输出和 framebuffer 像素。这种路径对理解 GPU 渲染基础有价值。

OpenGL 也适合维护旧项目、编辑器插件、科研可视化、CAD / DCC 工具和跨平台桌面工具中的渲染模块。许多项目的资产导入、UI 叠加、离屏渲染和工具预览建立在 OpenGL 生态上。对这些场景，工程价值优先来自稳定复用现有代码、工具链和驱动覆盖，对最低层内存控制权的需求通常较低。

现代渲染需求会放大 OpenGL 状态机的管理成本。显式 API 例如 Vulkan、Metal 和 Direct3D 12 倾向于把 pipeline state、descriptor / argument binding、command buffer、resource transition 和同步显式化。OpenGL 把许多验证、资源状态转换和驱动调度交给实现处理，应用层代码更短，但 CPU 提交路径、驱动内验证、跨线程构建和精确同步的可控性较低。

教学场景中，OpenGL 的优势是反馈快。修改 shader、改一个 uniform、切换一个 texture 后，画面变化直接呈现。工程场景中，OpenGL 的风险是状态来源分散。一个材质系统如果没有统一的状态设置入口，后续新增 shadow pass、postprocess pass、debug line pass 和 UI pass 时，前一个 pass 留下的 depth mask、blend mode 或 framebuffer 绑定会影响后一个 pass。

工具场景中，OpenGL 的优势是 RenderDoc 等 frame debugger 可以显示 draw call、pipeline state、texture、buffer 和 framebuffer。一次 capture 能回答“当前 draw 使用哪个 program、哪个 VAO、哪些 texture、输出到哪个 framebuffer”。工具也会暴露 OpenGL 的状态机特征：每个 draw 前的状态变更需要从事件列表中追踪，状态污染通常表现为某个 draw 继承了前一个 draw 的设置。

旧项目维护时，应先分离三类目标。第一类目标是保持输出一致，此时优先建立 state dump、debug callback 和最小复现。第二类目标是迁移到 core profile，此时优先替换立即模式、客户端数组、固定功能矩阵和旧纹理路径。第三类目标是迁移到显式 API，此时需要把 OpenGL 的隐式状态整理成引擎内部的 pipeline、resource binding 和 render pass 描述。

跨平台可用性需要按平台设定边界。桌面 OpenGL、OpenGL ES、WebGL 共享很多概念，但版本、shader 语言、默认 framebuffer 行为、extension 可用性和驱动限制不同。写可迁移代码时，应把版本和 extension 查询集中到一个 capability profile 中；渲染层只读取 profile 选择路径。这样可以把平台差异隔离在初始化和 feature selection 阶段。

因此，OpenGL 在现代工程中的定位应按目标判断。用于学习图形管线、维护旧渲染器、实现工具预览和中小型桌面可视化时，状态机模型仍然高效。用于大规模多线程 command recording、显式内存管理、复杂同步、现代主机平台深度优化时，OpenGL 会把关键控制权留给驱动，实现差异与性能诊断成本会上升。

81.4 创建 OpenGL 上下文与基本渲染流程

OpenGL context 的创建流程从窗口系统开始。应用先创建窗口或 surface，选择 color / depth / stencil / MSAA 等 framebuffer 属性，再请求 OpenGL 版本、profile 和 debug flag。成功后，应用把 context 设为 current，加载函数入口，注册 debug callback，创建渲染对象，进入 render loop。每帧设置 draw state、提交 draw call、交换前后缓冲。

这条流程中，OpenGL 规范和窗口系统绑定的职责要分清。像素格式、默认 framebuffer、swap interval、窗口 resize 和多显示器 surface 属于窗口系统绑定或窗口库。VAO、VBO、program、texture、FBO、debug output 和 draw command 属于 OpenGL context 内部语义。很多初始化错误来自把这两个层级混在一起，例如在没有 current context 时调用 glGenBuffers，或者在窗口 resize 后没有同步更新 viewport。

下面的 C++ 片段使用 GLFW 风格 API 表示上下文生命周期。它是最小路径示例，依赖实际项目的 GLFW / GLAD 初始化代码；重点放在调用顺序，窗口库只作为承载入口。

glfwInit();
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GLFW_TRUE);

GLFWwindow* window = glfwCreateWindow(1280, 720, "OpenGL State", nullptr, nullptr);
glfwMakeContextCurrent(window);

gladLoadGLLoader((GLADloadproc)glfwGetProcAddress);

glEnable(GL_DEBUG_OUTPUT);
glDebugMessageCallback(onGlDebugMessage, nullptr);

while (!glfwWindowShouldClose(window)) {
    int width = 0;
    int height = 0;
    glfwGetFramebufferSize(window, &width, &height);

    glViewport(0, 0, width, height);
    glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    glUseProgram(program);
    glBindVertexArray(triangleVao);
    glDrawArrays(GL_TRIANGLES, 0, 3);

    glfwSwapBuffers(window);
    glfwPollEvents();
}

这段代码的关键点有四个。第一，glfwMakeContextCurrent 在 loader 之前，因为 loader 需要读取当前 context 暴露的入口。第二，debug output 在对象创建和 draw 之前启用，便于捕获初始化阶段错误。第三，每帧根据 framebuffer size 设置 viewport，因为窗口像素尺寸可能和逻辑窗口尺寸不同。第四，swap 发生在窗口库层，它把默认 framebuffer 的 back buffer 呈现到窗口。

Shader 创建属于 context 内对象生命周期。应用创建 shader object，上传源码，编译，检查 compile log；再创建 program，attach shader，link，检查 link log；link 成功后才能作为当前 program 使用。glUseProgram 只选择当前 program，它不重新编译源码，也不自动修正 uniform 缺失。一个黑屏三角形若 program link 失败，后续 VAO 和 buffer 设置再完整也不会产生预期颜色。

Buffer 与 VAO 的顺序需要固定。创建 VBO 后，glBufferData 分配并上传顶点数据；绑定 VAO 后，glVertexAttribPointer 把当前 GL_ARRAY_BUFFER 记录为 attribute 的数据来源，并写入格式。之后 draw 时只需要重新绑定 VAO 和 program。这里的生命周期关系是：buffer storage 保存数据，VAO 保存解释规则，program 消耗解释后的 attribute。

窗口 resize 会改变默认 framebuffer 的实际尺寸。OpenGL 不会根据窗口变化自动更新 viewport；应用需要在 resize callback 或 render loop 中读取 framebuffer size 并调用 glViewport。如果 viewport 保持旧尺寸，draw 可能只覆盖窗口一部分，或在高 DPI 屏幕上出现比例错误。这个问题属于 context state 更新遗漏，不属于 vertex shader 坐标计算错误。

多 context 程序需要额外处理 current 关系和共享对象。一个资源上传线程可以拥有独立 context，并与渲染 context 处于 share group；buffer、texture、program 等对象共享规则受窗口系统绑定和 OpenGL 版本影响。同步需要通过 fence sync 或更高层任务系统协调。对单窗口单线程学习项目，先使用一个 context；对工具或引擎项目，再引入多 context 和共享规则。

销毁顺序也属于生命周期。正常退出时，先停止提交新的 GL 命令，再删除 program、buffer、texture、VAO、FBO 等对象，最后销毁窗口和 context。遇到 graphics reset 或 context loss 时，OpenGL 规范把 context 标记为 lost，恢复需要创建新 context 并重建相关状态。工程上应把资源创建参数保存在 CPU 侧资源系统中，使 context 重建可以从源数据恢复。

81.5 OpenGL 的版本演进与兼容性问题

OpenGL 版本演进改变了应用组织渲染状态的方式。早期 OpenGL 以固定功能管线、立即模式和大量全局状态为主；OpenGL 2.x 引入 GLSL shader 后，program 成为管线核心对象；OpenGL 3.x 引入 deprecation model 和 profile，core profile 开始推动现代对象路径；OpenGL 4.x 增加了 tessellation、compute shader、debug output、direct state access、SPIR-V ingestion 等能力。具体能力需要按实际 context 查询。

版本号只是第一层信息。一个程序请求 OpenGL 4.6 core profile，实际得到的 context 版本取决于操作系统、驱动、GPU、窗口系统绑定和 profile 请求参数。创建成功后，应使用 glGetString(GL_VERSION)、glGetString(GL_RENDERER)、glGetIntegerv(GL_MAJOR_VERSION)、glGetIntegerv(GL_MINOR_VERSION) 和 glGetStringi(GL_EXTENSIONS, index) 记录实际能力。运行时判断应基于查询结果，开发机经验只能作为初始假设。

Core profile 与 compatibility profile 的差异会直接影响代码能否运行。Core profile 要求使用 VAO 管理顶点输入，旧的立即模式、固定功能矩阵栈和客户端数组路径已经退出现代核心语义。Compatibility profile 允许很多旧代码继续运行，但新增状态组合会让渲染器更难建立统一规则。新代码应选择 core profile 并只使用对象化路径；旧代码迁移应按顶点输入、shader、texture、framebuffer 的顺序替换。

Extension 是 OpenGL 版本演进的重要机制。许多新能力先以 extension 形式出现，随后进入核心版本。应用使用 extension 前，应检查扩展字符串或 loader 结果，并为缺失能力准备 fallback。例如某个纹理压缩格式、debug marker、direct state access 函数或同步功能在目标平台上不可用时，渲染器应选择普通格式、关闭 marker、使用传统 bind-to-edit 路径或切换同步策略。

Driver difference 是 OpenGL 工程中的现实边界。同一组 GL 命令在规范语义上应产生一致结果，但性能、debug message 丰富程度、未定义行为暴露方式、shader compiler 诊断和 extension 覆盖会随实现变化。稳定工程代码应减少对未定义行为的依赖，并通过 debug context、frame capture、最小复现和 capability profile 收敛差异。

Fallback path 应从渲染需求反推。先列出必须能力，例如 core profile 版本、FBO、VAO、UBO、纹理格式、MSAA、sRGB framebuffer、debug output；再列出可降级能力，例如 anisotropic filtering、某些压缩格式、timer query、compute shader 或 direct state access。初始化阶段生成一个 renderer profile，后续材质、pass 和资源系统只读取 profile 做路径选择。

下面的检查顺序适合放入 OpenGL 初始化模块。它把版本、profile、extension 和 debug 信息收敛为可复用证据。

请求目标版本、profile、debug flag 和 framebuffer 属性。
创建窗口与 context，失败时降低版本或切换 profile，再记录失败原因。
设为 current，加载函数入口，检查 loader 是否成功。
查询实际 GL version、renderer、vendor、profile mask 和 extension 列表。
注册 debug callback，启用同步或异步 debug 输出策略。
构建 capability profile，把必需能力缺失标为启动失败，把可选能力缺失映射到 fallback。
创建最小 VAO / VBO / program / FBO smoke test，确认 draw path 可用。

这个顺序的价值在于把兼容性问题放在渲染器入口处理。后续 pass 看到的是稳定 profile，各处条件分支集中收敛到初始化阶段。对于 OpenGL，越早把状态机边界、版本边界和 fallback 边界固化，后续 draw call 越容易排查。

本章最终建立的判断是：OpenGL 的核心工程对象是 current context 中多组状态在 draw 时形成的组合。理解 context 生命周期可以解释“为什么函数入口无效、debug context 没消息、默认 framebuffer 没输出”；理解状态机可以解释“为什么当前 program、VAO、texture、FBO 或测试状态导致画面变化”；理解版本与 profile 可以解释“为什么同一段历史代码在 core profile、compatibility profile 和不同驱动上表现不同”。

最小自检任务

你接手一个最小 OpenGL 4.1 core profile 程序。窗口能打开，shader 编译与 link 成功，clear color 能显示，但三角形没有出现。初始化代码如下：

GLuint vbo = 0;
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);
glEnableVertexAttribArray(0);

glUseProgram(program);
glDrawArrays(GL_TRIANGLES, 0, 3);

请判断最可能的状态生命周期问题，并给出排查顺序。要求说明它属于 context、VAO / buffer、program、framebuffer 还是 pipeline flag 问题。

答案要点

这段代码最可疑的问题是 core profile 下没有创建并绑定 VAO。glVertexAttribPointer 和 glEnableVertexAttribArray 写入的是当前 VAO 的 attribute 状态；没有有效 VAO 时，顶点输入状态无法按 core profile 的方式保存。修复路径是在设置 attribute 前创建并绑定 VAO：glGenVertexArrays，glBindVertexArray，再绑定 VBO、设置 attribute 格式并启用 attribute。

排查顺序应从生命周期到 draw state。先确认 context 已经 current 且 loader 成功；再确认 debug callback 是否报告 invalid operation；再确认 framebuffer 绑定为默认 framebuffer 或完整 FBO，viewport 覆盖窗口像素尺寸；然后确认 program link 成功并已经 glUseProgram；接着确认 VAO 已绑定、attribute 0 已启用、VBO storage 有数据；最后检查 cull、depth、blend、color mask 这类 pipeline flag。由于 clear color 能显示，默认 framebuffer 和 swap 路径基本可用；由于 shader link 成功，核心疑点集中在 VAO / buffer 顶点输入状态。

本章知识点总结

状态机核心：OpenGL draw call 会读取当前 context 中已经写入的多组状态，画面结果来自这些状态的组合。
Context 边界：OpenGL 命令只作用于当前线程中 current 的 context，函数 loader 需要在 context current 后执行。
兼容契约：Core profile 推动现代对象路径，compatibility profile 保留旧接口并增加状态组合复杂度。
Debug context：Debug output 可以报告 GL 命令解释阶段的错误、未定义行为和实现相关提示。
Draw state 映射：一次 draw 至少依赖 VAO、program、uniform、texture unit、framebuffer、viewport 和测试混合状态。
VAO 作用：VAO 保存顶点 attribute 的启用状态、格式和 buffer 来源，是 core profile 顶点输入的关键对象。
Program 作用：Program 保存 shader link 结果和接口匹配状态，glUseProgram 只选择当前 program。
Texture 间接性：Sampler uniform、texture unit 和 texture object 三者必须匹配，材质串图通常来自这条关系错配。
Framebuffer 目标：Draw 可以写入默认 framebuffer 或 FBO，屏幕无结果需要先确认当前 draw framebuffer。
初始化顺序：稳定顺序是创建窗口与 context、make current、加载函数、启用 debug、创建对象、绑定状态、draw、swap。
版本查询：运行时应记录实际 GL version、profile、renderer 和 extension，再生成 renderer capability profile。
排查顺序：OpenGL 问题应先查 context 生命周期和输出目标，再查 program、VAO、资源绑定和 pipeline flag。

81.1 OpenGL State Machine and Compatibility Contract​

81.2 OpenGL Pipeline Mapping to Draw State​

81.3 OpenGL 与现代图形需求的适配性分析​

81.4 创建 OpenGL 上下文与基本渲染流程​

81.5 OpenGL 的版本演进与兼容性问题​

最小自检任务​

答案要点​

本章知识点总结​