颜色附件的数量是否受 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 完美编译:

The OpenGL specification requires that a framebuffer supports at least 8 color attachments. Now, OpenGL uses compile-time constants (at least on my system), for stuff like GL_COLOR_ATTACHMENTi and GL_DEPTH_ATTACHMENT attachment follows 32 units after GL_COLOR_ATTACHMENT0. Doesn't this mean that regardless of how beefy the hardware is, it will never be possible to use more than 32 color attachments? To clarify, this compiles perfectly with GLEW on Ubuntu 16.04:

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

并且由于它是 static_assert，因此对于任何硬件配置都是如此(除非驱动程序安装程序修改了头文件，否则会导致不可移植的二进制文件).将不同的附件类的函数分开会不会更好，因为它消除了冲突常量的可能性?

and since it is static_assert, this would be true for any hardware configuration (unless the driver installer modify the header files, which would result in non-portable binaries). Wouldn't separate functions for different attachment classes would have been better as it removes the possibility of colliding constants?

推荐答案

注意规范语言的差异很重要.glActiveTexture 关于它的参数是这样说的:

It is important to note the difference in spec language. glActiveTexture says this about its parameter:

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

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

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

This text explicitly allows you to compute the enum value, explaining exactly how to do so and what the limits are.

将其与关于 glFramebufferTexture 的内容进行比较:

Compare this to what it says about glFramebufferTexture:

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

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.

看起来很像.但请注意，它没有关于这些枚举器的值 的语言.该描述中没有关于 COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m.

It looks similar. But note that it doesn't have the language about the value of those enumerators. There's nothing in that description about COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m.

因此，使用这些特定枚举以外的任何值都是非法的.现在是的，规范确实保证其他地方 COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m.但是因为保证不在该部分，该部分明确禁止使用除实际枚举数以外的任何值.无论您如何计算，结果都必须是实际的枚举数.

As such, it is illegal to use any value other than those specific enums. Now yes, the spec does guarantee elsewhere that COLOR_ATTACHMENTm = COLOR_ATTACHMENT0 + m. But because the guarantee isn't in that section, that section explicitly prohibits the use of any value other than an actual enumerator. Regardless of how you compute it, the result must be an actual enumerator.

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

So to answer your question, at present, there are only 32 color attachment enumerators. Therefore, MAX_COLOR_ATTACHMENT has an effective maximum value of 32.

这篇关于颜色附件的数量是否受 API 限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！