是否由API限制颜色附件的数量

Question

OpenGL规范要求帧缓冲支持至少8种颜色附件。现在，OpenGL使用编译时常量（至少在我的系统上），GL_COLOR_ATTACHMENTi和GL_DEPTH_ATTACHMENT之类的内容在GL_COLOR_ATTACHMENT0之后的32个单位之后。这是不是意味着无论硬件有多强大，都不可能使用超过32种颜色的附件？为了澄清，这在Ubuntu 16.04上与GLEW完美编译：

static_assert(GL_COLOR_ATTACHMENT0 + 32==GL_DEPTH_ATTACHMENT,"");

并且因为它是static_assert，所以对于任何硬件配置都是如此（除非驱动程序安装程序修改头文件，这将导致非可移植的二进制文件）。不同的附件类的单独函数会不会更好，因为它消除了碰撞常量的可能性？

Answer 1

重要的是要注意规范语言的差异。 glActiveTexture对其参数说明了这一点：

  

如果指定了无效纹理，则会生成INVALID_ENUM错误。    texture 是TEXTURE i 形式的符号常量，表示要修改纹理单元 i 。每个TEXTURE i 遵守TEXTURE i = TEXTURE0 + i ，其中 i 的范围为0到k- 1，k是MAX_COMBINED_TEXTURE_IMAGE_UNITS

的值

本文明确允许您计算枚举值，准确解释如何执行此操作以及限制是什么。

将其与glFramebufferTexture的说法相比较：

  

如果附件不是表9.2中的附件之一，则会生成INVALID_ENUM错误，并且附件不是COLOR_ATTACHMENT m 其中 m 大于或等于MAX_COLOR_ATTACHMENTS的值。

看起来很相似。但请注意，它没有关于这些枚举器的值的语言。关于COLOR_ATTACHMENT m = COLOR_ATTACHMENT0 + m 的说明中没有任何内容。

因此，使用除特定枚举之外的任何值都是非法的。现在是的，规范确保其他地方 COLOR_ATTACHMENT m = COLOR_ATTACHMENT0 + m 。但由于该部分没有保证，该部分明确禁止使用除实际枚举数之外的任何值。无论您如何计算它，结果必须是实际的枚举器。

所以回答你的问题，目前只有32个颜色附件枚举器。因此，MAX_COLOR_ATTACHMENT的有效最大值为32。

Answer 2

第9.2节中的OpenGL 4.5 spec个州：

  

...由名为COLOR_ATTACHMENT0到COLOR_ATTACHMENTn的帧缓冲附加点。每个COLOR_ATTACHMENTi都符合COLOR_ATTACHMENTi = COLOR_ATTACHMENT0 + i

并作为脚注

  

头文件为范围为[0,31]的i定义标记COLOR_ATTACHMENTi。大多数实现支持少于32个颜色附件，并且将不受支持的附件名称传递给接受颜色附件名称的命令是一个INVALID_OPERATION错误。

我对此的解释是，只要硬件支持它，就可以完美地使用COLOR_ATTACHMENT0 + 32等来处理超过32个附着点。所以支持的颜色附件没有实际限制，只是没有直接定义常量。为何这样设计只能由khronos集团的人员来回答。