OpenGL 3.2+核心模式是否基于保留模式API设计？

你对立即模式的定义基本准确，但对保留模式的核心特征理解存在偏差：

• 保留模式的核心判定标准是图形库侧会完整维护整个场景的所有数据（包括对象层级、材质、变换矩阵、可见性等），应用仅需要对场景内的对象属性做增删改，不需要手动管理数据上传、绘制调度、状态排序等渲染流程细节，典型的保留模式实现包括Open Inventor、Java3D以及上层渲染框架Three.js。
• 你提到的无需直接调用渲染函数不是保留模式的必要特征，仅靠*顶点数据存储在GPU侧（VBO）*也不能判定为保留模式。

1. OpenGL 3.2+核心模式是否属于保留模式？ #

不属于，它本质还是立即模式的渲染架构。
核心模式虽然移除了glBegin/glEnd等旧立即渲染接口，要求所有顶点数据通过VBO存储在GPU侧，由驱动管理显存资源，但整个场景的状态管理、绘制顺序调度、Uniform参数更新、渲染指令调用全部需要应用侧手动实现，OpenGL驱动不会维护任何场景级别的数据，你每帧依然需要手动绑定VAO、设置着色器参数、调用glDraw*系列函数触发渲染，只是省去了逐帧向GPU传输顶点数据的步骤而已，完全不符合保留模式的定义。

2. 加入VBO特性的OpenGL 1.x/2.x版本是否属于保留模式？ #

不属于。
VBO在OpenGL 1.5版本正式纳入核心规范，它本质只是一个顶点数据存储的优化特性，允许开发者选择把顶点数据放在GPU显存减少逐帧传输开销，没有改变OpenGL的立即模式本质：场景逻辑依然完全由应用侧维护，驱动不会做任何场景级的管理，你甚至可以同时混用VBO和旧的glBegin/glEnd立即渲染接口。

3. OpenGL 3.2+兼容模式是不是立即模式与保留模式的混合实现？ #

不是。
兼容模式仅同时支持旧的固定管线、立即渲染接口和核心模式的着色器、VBO/VAO等新特性，两类特性都属于立即模式的范畴，全程没有引入保留模式的场景维护机制，所以它只是新旧两套立即模式渲染能力的兼容集合，和保留模式无关。

内容的提问来源于stack exchange，提问作者CoSalamander