glDrawElementsInstanced 是绘制百万级物体的唯一可行路径，必须配合 glVertexAttribDivisor 设置实例属性更新频率、对齐的 InstanceData 结构体及视锥裁剪才能高效运行。
glDrawElementsInstanced 是核心入口，不是可选优化
想一次性绘制百万物体，glDrawElementsInstanced 不是“试试看”的高级技巧，而是唯一可行路径。传统循环调用 glDrawElements 一百万次，CPU 会卡死在驱动层——不是你的代码慢，是 OpenGL 状态提交本身有不可忽略的固定开销。实测在主流桌面 GPU 上，单次 glDrawElements 平均耗时约 1–3 μs，乘以百万就是 1–3 秒/帧，直接掉帧到无法交互。
关键点在于：你必须把“每个物体的差异数据”（比如位置、缩放、旋转）提前打包进一个缓冲区，并通过顶点属性指针告诉 GPU 这些数据每多少个实例才更新一次。这个控制粒度由 divisor 参数决定。
-
divisor = 0：该属性每顶点更新（常规用法，不用于实例化） -
divisor = 1：该属性每实例更新（最常用，比如每个小行星一个mat4变换矩阵） -
divisor = N：该属性每 N 个实例更新一次（适合分组复用，如每 10 个子弹共用一套颜色）
实例属性必须用 glVertexAttribDivisor 控制更新频率
很多人卡在“画出来但所有物体叠在一起”，问题几乎都出在忘了调 glVertexAttribDivisor。即使你把一百万个 mat4 正确上传到了 GL_ARRAY_BUFFER，只要没设置 divisor，GPU 会把它当成普通顶点属性——每个顶点都读同一个矩阵，结果就是所有实例渲染在同一位置。
典型配置流程：
立即学习“C++免费学习笔记（深入）”；
- 绑定存放实例数据的 VBO（比如叫
instanceVBO） - 调用
glVertexAttribPointer绑定到某个 location（比如 location = 3） - 紧接着必须调
glVertexAttribDivisor(3, 1)，表示该属性每实例更新一次 - 如果上传的是
mat4（16 float），需连续调 4 次glVertexAttribPointer（对应 4 个 vec4），每次都要配对应的glVertexAttribDivisor
实例数据布局影响显存带宽和 shader 可读性
传一百万个变换矩阵，不是随便排布就行。GPU 对内存访问模式敏感，错位或跨度过大会触发缓存未命中，尤其在低端显卡上帧率波动明显。
推荐结构（C++ 端对齐 + GLSL 端匹配）：
- C++ 中用
alignas(16) struct InstanceData { glm::mat4 model; uint32_t id; };，确保model起始地址 16 字节对齐 - 上传时用
glBufferData(GL_ARRAY_BUFFER, sizeof(InstanceData) * count, data, GL_STATIC_DRAW) - GLSL 中声明为
layout(location = 3) in mat4 model;（注意：现代驱动支持直接用mat4输入，无需拆成 4 个vec4，但需确认 OpenGL 版本 ≥ 3.3） - 避免混合类型混排：比如把
vec3 position和float scale分开放入不同 buffer，比塞进同一 struct 更易对齐和调试
百万级实例仍需配合视锥裁剪，否则 GPU 白算
glDrawElementsInstanced 解决了 CPU 瓶颈，但没解决 GPU 工作量。如果所有一百万个物体都参与光栅化（哪怕在屏幕外），填充率和片元着色器开销依然爆炸。实测中，未裁剪的百万小行星在 1080p 下帧率可跌至 5 FPS 以下，而加了简单视锥剔除后稳定在 60+ FPS。
裁剪建议分两层做：
- CPU 端粗筛：用包围球或 AABB 批量测试，剔除明显不在视锥内的物体组（例如按空间格网分块，每块一个包围盒）
- GPU 端精筛：在顶点着色器开头加
if (!isInFrustum(model[3].xyz)) discard;，但注意这会导致分支预测失败，仅当剔除率 > 70% 时才值得开启 - 更稳方案：用
gl_InstanceID做间接索引，结合SSBO存储有效实例 ID 列表，再用glDrawElementsInstancedBaseInstance只绘制存活实例
真正难的从来不是“怎么画一百万”，而是“怎么让 GPU 只画屏幕上真正需要的那几百个”。实例化只是管道，别让它变成漏水的水管。
