To my surprise, most of the things I tried don’t work. I know I could make some workarounds but it just baffles me that I can’t do it.
So I’m using multisampled textures for color & depth in a framebuffer. I then want to resolve color AND depth textures. glBlitFramebuffer apparently only resolves color, depth is simply ignored, even when calling it with just the depth flag. (this is on a HD7850 with latest drivers, btw). So I resorted to using a sampler2DMS in a pixel shader and doing a full screen quad resolve manually. I then come across another issue, writing the resolved depth to gl_FragDepth is getting ignored… I disable depth test, enable depth write (through glDepthMask), reset glPolygonOffset to 0,0 and I still can’t get a write there…
Further down the line I tried writing depth to color, this works as expected, however my pipeline still uses a GL_DEPTH_COMPONENT32 texture and for the sake of easing up my workload, the simplest thing to do would be to somehow copy from that color to my original depth buffer, to get the resolve I need. So I tried glCopyTexImage2D which is simply getting ignored. I assume it just doesn’t want to convert GL_DEPTH_COMPONENT32 to GL_RED_32 or GL_RGBA32F (tried both). So like, I wonder if depth resolving has a driver issue or something.
glBlitFramebuffer apparently only resolves color, depth is simply ignored, even when calling it with just the depth flag. (this is on a HD7850 with latest drivers, btw).
Just because you’re on the “latest drivers” of a piece of hardware doesn’t mean that it’s not a driver bug. Which the behavior you describe most certainly would be.
Depth buffers are not special. If you do a multi-sample to single-sample blit, and that blit involves the depth, the blit should still happen.
Now, it is possible that the way in which you are confirming whether the depth blit happened is incorrect. Indeed, the fact that you said that your own multisample resolve failed to write anything suggests that this is your problem. I’d like to see that before firmly calling this a driver bug. Can you show a simple test application that does the blit and exhibits the bug?
As to your question (about your workaround), no, you cannot copy colors to depth or vice-versa. At least, not within the hardware. You can do it outside of the hardware, by DMA-ing it into a PBO, then DMA-ing it into the other texture.
Hm, this is kind of weird cause I just tried blitting with the depth bit again and it worked… The thing is though that there’s a difference. Previously I was trying to blit from multisampled renderbuffers while I now I use multisampled textures (for color and depth).
Ups, tried with renderbuffers and that works too, hm, I think this is all due to some full screen quad code that I can’t seem to figure out why it’s failing sometimes. Apparently If I render a full screen quad and not do a clear to the framebuffer, I risk to not get stuff rendered, and I do disable the depth test and set depth write to false.
EDIT:Yeah, depth resolve works, It was all me, I was enabling depth test when setting the current framebuffer (if it had a depth texture, it was on) but forgot to disable right before full screen quad rendering, so based on which was the last framebuffer object set, the depth test would be randomly enabled/disabled. It’s still a shame though that GL still doesn’t have a CopyResource (DX10+) like function for copying stuff around :).
It’s still a shame though that GL still doesn’t have a CopyResource (DX10+) like function for copying stuff around .
You mean like glCopyTexSubData? It can’t do multisample resolve; only blitting can do that because it may be connected to framebuffer resources.
Thanks, that was exactly what I was looking for :). Unfortunately that’s available only on GL 4.3, so I had to update to a beta driver for that, I hope nothing else breaks because of it.