颜色附件的数量是否受 API 限制
Is the number of color attachments bounded by API
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，这对于任何硬件配置都是正确的（除非驱动程序安装程序修改头文件，这将导致不可移植的二进制文件）。将不同附件的函数分开 类 会不会更好，因为它消除了常量冲突的可能性？
第 9.2 节中的 OpenGL 4.5 spec 状态：
... by the framebuffer attachment points named COLOR_ATTACHMENT0 through COLOR_ATTACHMENTn. Each COLOR_ATTACHMENTi adheres to COLOR_ATTACHMENTi = COLOR_ATTACHMENT0 + i
并作为脚注
The header files define tokens COLOR_ATTACHMENTi for i in the range [0, 31]. Most implementations support fewer than 32 color attachments, and it is an INVALID_OPERATION error to pass an unsupported attachment name to a command accepting color attachment names.
我对此的解释是，（只要硬件支持）使用 COLOR_ATTACHMENT0 + 32 等来解决超过 32 个连接点是完全没问题的。所以对支持的颜色附件没有真正的限制，只是没有直接定义常量。为什么要这样设计，只有khronos组的人才能回答。
请务必注意规范语言的差异。 glActiveTexture 关于它的参数是这样说的：
An INVALID_ENUM error is generated if an invalid texture is specified.
texture is a symbolic constant of the form TEXTUREi, indicating that texture unit i is to be modified. Each TEXTUREi adheres to TEXTUREi = TEXTURE0 + i, where i is in the range zero to k−1, and k is the value of MAX_COMBINED_TEXTURE_IMAGE_UNITS
本文明确允许您计算枚举值，并准确解释了如何计算以及限制是什么。
将此与它所说的 glFramebufferTexture 进行比较：
An INVALID_ENUM error is generated if attachment is not one of the attachments in table 9.2, and attachment is not COLOR_ATTACHMENTm where m is greater than or equal to the value of MAX_COLOR_ATTACHMENTS.
看起来很像。但请注意，它没有关于这些枚举器的 value 的语言。该描述中没有关于 COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m.
因此，使用这些特定枚举以外的任何值都是非法的。现在是的，规范确实保证 elsewhere COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m。但是因为保证不在该部分中，所以该部分明确禁止使用实际枚举器以外的任何值。无论您如何计算它，结果都必须是一个实际的枚举器。
所以回答你的问题，目前只有32个彩色附件普查器。因此，MAX_COLOR_ATTACHMENT 的有效最大值为 32.
OpenGL 规范要求帧缓冲区至少支持 8 种颜色附件。现在，OpenGL 使用编译时常量（至少在我的系统上），用于 GL_COLOR_ATTACHMENTi 和 GL_DEPTH_ATTACHMENT 附件在 GL_COLOR_ATTACHMENT0 之后的 32 个单元之后。这是否意味着无论硬件多么强大，都不可能使用超过 32 种颜色的附件？澄清一下，这与 Ubuntu 16.04:
static_assert(GL_COLOR_ATTACHMENT0 + 32==GL_DEPTH_ATTACHMENT,"");
并且因为它是 static_assert，这对于任何硬件配置都是正确的（除非驱动程序安装程序修改头文件，这将导致不可移植的二进制文件）。将不同附件的函数分开 类 会不会更好，因为它消除了常量冲突的可能性？
第 9.2 节中的 OpenGL 4.5 spec 状态：
... by the framebuffer attachment points named
COLOR_ATTACHMENT0throughCOLOR_ATTACHMENTn. EachCOLOR_ATTACHMENTiadheres toCOLOR_ATTACHMENTi = COLOR_ATTACHMENT0 + i
并作为脚注
The header files define tokens
COLOR_ATTACHMENTifor i in the range [0, 31]. Most implementations support fewer than 32 color attachments, and it is an INVALID_OPERATION error to pass an unsupported attachment name to a command accepting color attachment names.
我对此的解释是，（只要硬件支持）使用 COLOR_ATTACHMENT0 + 32 等来解决超过 32 个连接点是完全没问题的。所以对支持的颜色附件没有真正的限制，只是没有直接定义常量。为什么要这样设计，只有khronos组的人才能回答。
请务必注意规范语言的差异。 glActiveTexture 关于它的参数是这样说的：
An INVALID_ENUM error is generated if an invalid texture is specified. texture is a symbolic constant of the form TEXTUREi, indicating that texture unit i is to be modified. Each TEXTUREi adheres to TEXTUREi = TEXTURE0 + i, where i is in the range zero to k−1, and k is the value of MAX_COMBINED_TEXTURE_IMAGE_UNITS
本文明确允许您计算枚举值，并准确解释了如何计算以及限制是什么。
将此与它所说的 glFramebufferTexture 进行比较：
An INVALID_ENUM error is generated if attachment is not one of the attachments in table 9.2, and attachment is not COLOR_ATTACHMENTm where m is greater than or equal to the value of MAX_COLOR_ATTACHMENTS.
看起来很像。但请注意，它没有关于这些枚举器的 value 的语言。该描述中没有关于 COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m.
因此，使用这些特定枚举以外的任何值都是非法的。现在是的，规范确实保证 elsewhere COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m。但是因为保证不在该部分中，所以该部分明确禁止使用实际枚举器以外的任何值。无论您如何计算它，结果都必须是一个实际的枚举器。
所以回答你的问题，目前只有32个彩色附件普查器。因此，MAX_COLOR_ATTACHMENT 的有效最大值为 32.