使用块索引作为 UniformBufferObject、ShaderStorageBufferObjects 等的绑定点是否安全？答案

【问题标题】：Is it safe to use the block index as the binding point for UniformBufferObject, ShaderStorageBufferObjects, etc?使用块索引作为 UniformBufferObject、ShaderStorageBufferObjects 等的绑定点是否安全？
【发布时间】：2016-12-22 14:29:03
【问题描述】：

我很好奇在几个 OpenGL 缓冲区对象相关函数中使用的 *BlockBinding 参数。

例如glUniformBlockBinding中的uniformBlockBinding参数，glShaderStorageBlockBinding中的storageBlockBinding，以及glBindBufferRange和glBindBufferBase中对应的index参数。

我知道，如果使用以下布局限定符在着色器中设置绑定点，则无需调用 glUniformBlockBinding 和 glShaderStorageBlockBinding：

layout (binding = 0) blockName {...}

通过在我的机器上进行测试，我注意到了三件事：

1) 使用 glUniformBlockBinding 和 glShaderStorageBlockBinding 设置绑定点会覆盖使用布局限定符在着色器中设置的绑定点。

2) 从glGetUniformBlockIndex 和glGetProgramResourceIndex 返回的块索引对于相同类型 的每个块按0 到n 排序。例如，如果着色器包含 3 个统一块和 2 个缓冲区块，则返回的索引将分别为 [0,1,2] 和 [0,1]。

3) 绑定点，无论哪种方式设置，都不会在类型之间发生冲突。例如，将统一块设置为 binding = 0，将缓冲区块设置为 binding = 0 是完全安全的。

考虑到这些假设（如果有任何不一定正确且纯属巧合，请纠正我），我有什么理由不应该让我的代码自动设置@987654336 @ 对应块索引的参数，省去了通过gl*BlockBinding 或布局限定符手动指定它们的麻烦。

【问题讨论】：

标签： opengl glsl

【解决方案1】：

我曾经有过同样的问题。经过一番探索，特别是阅读了GL的权威资料来源：https://www.khronos.org/opengl/wiki/Uniform_Buffer_Object] 我很确定这就是为什么块索引和绑定点之间的分离。

将 GL 渲染上下文视为一个端口，将 glsl 程序对象视为一艘船。绑定点是港口的港口，区块索引是船舶储藏室的门。一艘船需要停靠在港口，其中一个门与特定港口对齐，以将货物装载到船上（或相反）。类似地，块索引需要与要在着色器块和上下文缓冲区之间传输的数据的绑定点相关联。

由于这种设计，块索引和绑定点是独立的实体。因此，简单地将绑定点等同于块索引是不安全的，因为这可能会无意中覆盖绑定点（可能已被其他船只停靠）。

你的观察也可以解释：

块索引和绑定点从 0 开始连续计数（正如您在 (2) 中观察到的那样）。
每种类型的缓冲区（因为它们驻留在上下文中）都有一组与其他类型分开的绑定点（因此您的观察 3）。
至于您的观察 1，是的，在应用程序端设置关联会抢占着色器中的硬编码绑定。

【讨论】：

【解决方案2】：

考虑到这些假设（如果有任何不一定正确且只是巧合，请纠正我），有什么理由不应该让我的代码自动将 *BlockBinding 参数设置为相应的块索引并且省去了通过gl*BlockBinding 或使用布局限定符手动指定它们的麻烦。

因为那完全没用。

块索引被任意分配给特定块。一个平台，一个特定块的索引可能是 0，而另一个对名称进行排序，使其索引为 2。因此，您的代码必须查询您计划使用的每个块的块索引。

如果您指定用于特定块的绑定索引，则无需查询任何内容。您的代码知道绑定索引 0 是您的矩阵所在的位置，绑定索引 1 是您的照明数据所在的位置，等等。

更糟糕的是，您可能有多个着色器使用相同的块。但它们极不可能具有相同的块 index。而如果为它们分配绑定索引，则可以为它们提供相同的绑定索引。因此，您不必在对此类程序的更改之间重新绑定缓冲区。

【讨论】：