Compute Shader 需 OpenGL 4.3+（macOS 等旧平台不支持），驱动要求严格；必须用 SSBO 传物理数据，正确绑定与对齐；glDispatchCompute 需合理分组并配合 memoryBarrierBuffer() 和 barrier()；调试优先检查 glGetError() 和内存屏障。
Compute Shader 必须用 OpenGL 4.3+，且驱动要支持
低于 OpenGL 4.3 的环境（比如 macOS 最高只到 4.1）根本无法调用 glDispatchCompute，连编译都会报 error C7540: compute shader requires GLSL 4.30 or higher。NVIDIA 驱动需 340+，AMD 需 14.9+，Intel 核显在 Linux 上需 Mesa 17.1+、Windows 上需 DCH 驱动 26.20.100.7870+。检查方式很简单：
glGetIntegerv(GL_MAJOR_VERSION, &major);<br>glGetIntegerv(GL_MINOR_VERSION, &minor);<br>// 要求 major > 4 || (major == 4 && minor >= 3)
别依赖 glewInit() 后自动识别——它可能把扩展名列出来，但实际函数指针为空。务必用 glGetError() 在每次 glDispatchCompute 后检查，否则静默失败很常见。
物理数据必须用 SSBO（而非纹理）传入计算着色器
粒子位置、速度、质量这类结构化、随机读写的物理量，用纹理（sampler2D）不仅写起来反直觉，还会触发隐式格式转换和边界采样开销。SSBO 才是正解：
- 声明方式：
layout(std430, binding = 0) buffer Particles { vec4 pos[]; vec4 vel[]; float mass[]; }; - 绑定时注意对齐：vec4 占 16 字节，float 占 4 字节，
mass[]后若紧跟 vec4 会因对齐要求自动补空，建议统一用vec4存标量（如vec4(mass, 0, 0, 0)） - C++ 端用
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, ssbo_id)绑定，不是glBindBuffer后再 bind，否则着色器读不到
glDispatchCompute 的工作组数量不能硬写成粒子总数 / 64
GPU 不保证所有工作组并发执行，更不保证跨工作组内存可见性。物理模拟中常见的“每个粒子更新后立即被邻居读取”逻辑，在默认情况下会出错。必须加内存屏障：
memoryBarrierBuffer();<br>barrier(); // 这个 barrier 是工作组内同步，不是跨组！
真正需要的是：
- 把粒子分块（比如每 256 粒子一组），确保同一组内交互频繁的粒子尽量落在同个工作组
- 用
glDispatchCompute(num_groups_x, 1, 1)，别用单维大数，避免超出硬件限制（GL_MAX_COMPUTE_WORK_GROUP_COUNT查询） - 若需跨组读写（如 N-body 全局力计算），改用两级方案：第一轮算局部力存临时缓冲，第二轮用原子操作或 reduction shader 合并
调试 Compute Shader 物理结果异常，先关掉 GPU 调度优化
NVIDIA 的 GL_ARB_shader_clock 和 AMD 的 GL_AMD_shader_explicit_vertex_parameter 可能干扰时间步长一致性；Intel 核显在 Windows 上默认启用 GPU Boost，导致 glDispatchCompute 实际耗时不稳。最有效的排查顺序是：
- 用
glGetInteger64v(GL_TIMESTAMP, &start)测每帧 dispatch 前后时间戳，确认是否被调度器掐断 - 禁用垂直同步：
glfwSwapInterval(0)，否则glDispatchCompute可能被帧同步阻塞 - 物理更新步长必须与 GPU 计算周期解耦——不要用 dispatch 耗时动态调整 dt，而应固定 dt，靠多次 dispatch 模拟亚帧
SSBO 写入后不立刻可见、barrier 失效、工作组尺寸越界——这三个问题占了 80% 的物理模拟黑屏或爆炸现象。别急着优化算法，先用 glGetError() 和 glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT) 把基础通路走通。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
