问题描述
在HD4000(Windows 64位,驱动程序版本15.28.20.64.3347)上运行应用程序时,我收到一个奇怪的OpenGL错误.
I am getting a weird OpenGL error when running my application on my HD4000 (Windows 64bit, driver version 15.28.20.64.3347).
我将其归结为几个OpenGL调用以重现它:
I boiled it down to a few OpenGL calls to reproduce it:
- 创建两个帧缓冲对象.
- 创建纹理并将其作为GL_COLOR_ATTACHMENT0绑定到两个FBO.
- 再次在纹理上调用glTexImage2D
- 绑定第一个FBO并调用glCheckFramebufferStatus(返回GL_FRAMEBUFFER_COMPLETE).
- 绑定第二个FBO并致电glClear. glClear提供了GL_INVALID_FRAMEBUFFER_OPERATION.
需要第3步和第4步来重现该错误,我发现这对于glCheckFramebufferStatus调用尤其令人不安.在其他图形卡(包括同一台计算机上的Nvidia卡)上也不会发生此问题.
Step 3 and 4 are required to reproduce the error, which I find especially disturbing for the glCheckFramebufferStatus call. The problem also does not occur on other graphics cards (including the Nvidia card on the same machine).
如果在第二个FBO上调用glCheckFramebufferStatus,它还会返回GL_FRAMEBUFFER_COMPLETE.但是,当使用apitrace检查内部OpenGL状态时,它表示第二个FBO现在具有对象名称为零的颜色附件.
If you call glCheckFramebufferStatus on the second FBO, it also returns GL_FRAMEBUFFER_COMPLETE. However, when inspecting the internal OpenGL state with apitrace, it says that the second FBO has now a color attachment with object name zero.
在glCheckFramebufferStatus调用解决了错误之后,将纹理重新绑定到第二个FBO.目前,这是一种解决方法,但我认为将纹理绑定到每个帧的各种FBO并不是一个好主意.
Re-binding the texture to the second FBO after the glCheckFramebufferStatus call resolves the error. This is working as a workaround for now, but I suppose that binding textures to various FBOs each frame is not a good idea.
这是重现该错误的C ++代码:
Here is the C++ code that reproduces the error:
// Create a texture and bind it to two FBOs
GLuint textureName;
glGenTextures(1, &textureName);
glBindTexture(GL_TEXTURE_RECTANGLE, textureName);
glTexImage2D(GL_TEXTURE_RECTANGLE, 0, GL_RGBA, 2, 2, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
GLuint fboNames[2];
glGenFramebuffers(2, fboNames);
glBindFramebuffer(GL_FRAMEBUFFER, fboNames[0]);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_RECTANGLE, textureName, 0);
glBindFramebuffer(GL_FRAMEBUFFER, fboNames[1]);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_RECTANGLE, textureName, 0);
glBindTexture(GL_TEXTURE_RECTANGLE, textureName);
glTexImage2D(GL_TEXTURE_RECTANGLE, 0, GL_RGBA, 2, 2, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glBindFramebuffer(GL_FRAMEBUFFER, fboNames[0]);
// Removing this line resolves the error
glCheckFramebufferStatus(GL_FRAMEBUFFER); // Returns GL_FRAMEBUFFER_COMPLETE
glBindFramebuffer(GL_FRAMEBUFFER, fboNames[1]);
GLenum bufferTarget = GL_COLOR_ATTACHMENT0;
glDrawBuffers(1, &bufferTarget);
// Adding this line resolves the error
// glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_RECTANGLE, 1, 0);
glCheckFramebufferStatus(GL_FRAMEBUFFER); // Returns GL_FRAMEBUFFER_COMPLETE
//This call causes a GL_INVALID_FRAMEBUFFER_OPERATION error.
glClear(GL_COLOR_BUFFER_BIT);
这是一个最小的Visual Studio 2013项目,可用于重现它: https://www. dropbox.com/s/5142j26d839gkp9/HD4000Error.zip
Here is a minimal Visual Studio 2013 Project to reproduce it: https://www.dropbox.com/s/5142j26d839gkp9/HD4000Error.zip
现在,我的问题是:我是在这里用OpenGL做非法行为还是仅仅是驱动程序错误?
Now, my question is: Am I doing something illegal with OpenGL here or is this simply a driver bug?
推荐答案
我们已将此问题报告给了Intel,看来这实际上是一个错误.在当前驱动程序版本中已修复.
We reported this issue to Intel and it seems that it was in fact a bug. It is fixed in the current driver version.
这篇关于glCheckFramebufferStatus之后无效的帧缓冲区操作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!