是受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 是TEXTURE i 形式的符号常量，指示纹理单元 i 将被修改.每个TEXTURE i 都遵循TEXTURE i = TEXTURE0 + i ，其中 i 的范围为零至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_ATTACHMENT m ，其中 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.

它看起来很相似.但是请注意，它没有有关这些枚举器的 value 的语言.该描述中没有关于COLOR_ATTACHMENT m = 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_ATTACHMENT m = 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屋！