Depth clear affected by GL-state?

Hello. I’m just wondering if depth clears depend on some random GL state I’ve overlooked? A quick browse of the spec revealed nothing, but I may have missed something.

Basically I’m trying to clear a depth texture attached to an FBO by binding the FBO and then calling glClearBufferfv(GL_DEPTH, 0, &value);. In one of my test programs this code works fine, but in this particular instance it doesn’t seem to work. No GL-errors are raised, but the texture still contains data from the previous frame when I later render it to screen.

I did get it to work at one point by randomly reordering some related rendering code, but I can’t reproduce that any more.

Am I possibly looking at a driver bug? GL3.2 context, Catalyst 10.5, Vista 64, HD3850.

Yes. See the glClear man page:

http://www.khronos.org/opengles/documentation/opengles1_0/html/glClear.html

See the sentence with “scissor” and “color buffer masks” in it.

Thanks for the pointer.

Hmm. The color buffer masks shouldn’t matter when I’m clearing the depth attachment, dithering I haven’t even touched and the pixel ownership test I assume doesn’t matter for FBOs (or it would presumably always be true?)

Scissor is context state, right? Or do I need to reset it for every FBO I bind? I’m not at my dev computer right now, but I’ll give that a go tomorrow.

Shouldn’t. Might try glDepthMask( GL_TRUE ) just for kicks.

the pixel ownership test I assume doesn’t matter for FBOs (or it would presumably always be true?)

That’s my understanding. It’s a window framebuffer thing.

Scissor is context state, right?

Think so. Just try a glDisable( GL_SCISSOR_TEST ).

Hmm, neither glDepthMask(GL_TRUE) nor glDisable(GL_SCISSOR_TEST) had any effect… Weird.

At http://www.wien-systems.no/files/malfunctioning-clear.zip is a simplified Windows-version of my program if anyone wants to try it. I’d be especially interested in seeing what the Nvidia driver thinks of it. You’ll need GL 3.3 drivers and the VS2010 runtime. The camera can be moved around using WASD-FR and the arrow keys.

Here’s how the scene looks rendered with D3D10 (the four buffers down the left are albedo, specular, depth and normal respectively. The main window is intentionally left blank.):

In OpenGL the gbuffer is obviously rendered Y-inverted (why is that anyway?) and I also have some trouble with the GUI not showing up, but that’s related to a different bug with sampler objects and hopefully not relevant to this problem. Moving the camera should reveal the problem.

Thanks.

OpenGL puts the origin in the lower-left of images/textures/etc. DirectX puts it in the upper-left. Could be related.

Hmm. I just got to try my program on an Nvidia-card and all I got back was a black screen with no errors (and a shader compile error which I’ve now fixed). I must be doing something fundamentally wrong here. Guess I’ll have to buy an Nvidia card so I can debug this properly.