Hi everyone,
I have a question regarding what seems to be a texture being
corrupted after it has been drawn to using FBO. The really
interesting part about it, is that this only occurs when the
program is compiled with gcc optimization flag of -O1 or larger
(incl. -Os); i.e. with -O0 the texture survives fine. It also
appears nice and fine on WinXP (although that's with a slightly
different general code base).
The FBO is used as a render target for a depth map. When our
program starts, we initialize the framebuffer object, and the
texture to hold the depth info, like this:
glGenFramebuffersEXT(1, &mDepthFBO);
glGenTextures(1, &mDepthTexture);
glGenRenderbuffersEXT(1, &mDepthRB);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, mDepthFBO);
// init texture
glBindTexture(GL_TEXTURE_2D, mDepthTexture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, mDepthTextureSize,
mDepthTextureSize, 0,
GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S,
GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T,
GL_CLAMP_TO_EDGE);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT,
GL_TEXTURE_2D, mDepthTexture, 0);
// initialize depth renderbuffer
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, mDepthRB);
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT,
GL_DEPTH_COMPONENT24, mDepthTextureSize, mDepthTextureSize);
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT,
GL_DEPTH_ATTACHMENT_EXT,
GL_RENDERBUFFER_EXT, mDepthRB);
CheckFramebufferStatus();
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
Then, each time the depth map is tagged as dirty, it is rendered
like this:
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, pRM->mDepthFBO);
[render all objects]
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
And then, mDepthTexture is used in the other render passes as a
depth map. But, as I said, when running an optimized executable,
this texture gets corrupted at semi-rendom intervals. It never
happens in none-optimized mode, and it always happens (at
approximately the same place each time) in optimized mode. Most
of the time, the corruption is evident as a shift/stripe pattern
of the original texture, but sometimes it seems to copy in some
very incorrect values from varying places of various other
textures (that, as far as I can establish, are also on the GPU).
And, while this takes place, the texture has not been rendered to
again at all. If the depth map is force-flagged as dirty, the
texture's content is reset to correct values, but the same
corruption pattern usually occurs shortly after.
I've tried to debug this error using the OpenGL Profiler, but it
seems that the Resource view is unable to show the mDepthTexture
at all. Depending on the blend modes, it shows up as either
(semi-)transparent, blank or white. And, enabling OpenGL error
breakpoints almost brings our program to a halt (framerate drops
from 30-40 down to ~1), but no errors seem to occur when the
texture corruption occurs. Another thing that makes debugging a
little bit harder, is that the only Mac hardware we have at our
disposal that can run the program with the shaders enabled, and
with a useable framerate, is my new 15" MacBook Pro (Core 2 Duo
2.33 w/ 2GB RAM and 256MB VRAM on ATI X1600). I tried to run it
through the Software Renderer (through the OpenGL Profiler), but
it seems that our Cg shader programs exceed the limitations of
that renderer's register count, so it fallbacks to the fixed
function render pipeline (without both the FBO and depth map).
Oh, and our Windows boxen all sport nVidia cards.
So, I'm not sure if this might be caused by: a) our code
[likely], b) some other code/library we're using [also rather
likely], c) the OpenGL.framework on my MBP or d) the ATI card
itself.
So, I was wondering if anyone had any ideas on what might be
causing this, or what I (or rather "we", as this part of our
program is written by our lead programmer, Cc'd here) could do to
find out what's wrong? Any hints or speculations would be
welcome, and I'll try to clarify any ambiguities.
Thanks!
Best regards,
--
Erik Harg
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40codeblender.com
This email sent to email@hidden
