I reported this a while back against Android 4.3 on the old forums but since you guys blew away all the old content I'm reporting it again. I just updated my Nexus 10 to KitKat hoping the problem might be fixed but it's still there.
This was the old thread: http://forums.arm.com/index.php?/topic/17088-msaa-renderbuffer-back-buffer-blit-generates-invalid-operation-error-on-nexus-10/
Basically we're rendering off-screen to an FBO with an RGBA texture attached to COLOR_ATTACHMENT0. At the end of the frame we try to blit this image to the back buffer using glBlitFramebuffer. What we get in the back buffer is a trail of all previous frames as though we were never clearing the screen between frames. If I draw the image to the back buffer as a textured quad instead of using BlitFramebuffer then it looks correct, so I don't think it's really an issue in the source image (not to mention this code works fine on Desktop GL and other non-Mali ES 3.0 devices).
Here's a link to an APK file that shows the problem. Just load any of the sample documents and try to manipulate the camera and you'll see the trails.
https://dl.dropboxusercontent.com/u/69927239/HOOPSAndroidViewer_nexus10_trails.apk
Hi Chris,
Thanks for the info. I don't believe the build I linked to is using any MSAA surfaces though, it's just attempting to blit a regular single-sampled texture to the main FBO. We've already found that drawing a textured quad instead works fine for this case. We also found that when using MSAA and resolving first to a temporary surface, and then drawing that as a textured quad, the trails problem persists, so I think the work-around you suggested addresses this case.
I have a couple questions about this approach if you or anyone can answer them. 1. Is using MSAA textures really the preferred solution for Mali devices? Even if this bug did not exist would we still be better off doing that? 2. We need to be able to blit msaa depth-stencil surfaces as well, can we expect that surfaces allocated with glRenderbufferStorageMultisampleEXT will also be affected by this bug (since BlitFramebuffer is our only option in this case).
Thanks,
Evan
Hi Evan,
I have some feedback for you:
1. Yes. MSAA textures created via glFramebufferTexture2DMultisampleEXT are better suited than “true” multisample textures to our driver at the very moment. And those will work on Mali400 as well which does not support GLES3. 2. As we have not root-caused the problem I can’t say much about whether those are affected or not. In general depth-stencil surfaces can be used via the same code path as above (create a depth-stencil texture, and attach it via the MS extension to an FBO). It would be interesting to know their use case here. Copying depth/stencil does not work via texturing without additional extensions, as a shader cannot write into the stencil channel. Writing into depth only works via gl_FragDepth in GLES3.
1. Yes. MSAA textures created via glFramebufferTexture2DMultisampleEXT are better suited than “true” multisample textures to our driver at the very moment.
And those will work on Mali400 as well which does not support GLES3.
2. As we have not root-caused the problem I can’t say much about whether those are affected or not. In general depth-stencil surfaces can be used via the same code path as above (create a depth-stencil texture, and attach it via the MS extension to an FBO). It would be interesting to know their use case here. Copying depth/stencil does not work via texturing without additional extensions, as a shader cannot write into the stencil channel. Writing into depth only works via gl_FragDepth in GLES3.
I agree that we need to know more about your use case, and we can give better advice. Is there any particular reason you are rendering to an offscreen FBO before blitting to the default framebuffer? Is this to facilitate a resolve of a multisampled buffer?
I would recommend the use of glFramebufferTexture2DMultisampleEXT and the related MultisampleEXT functions on mali for a few reasons:
Also, if you are only doing the offscreen render in order to resolve the data, then have you considered rendering to the default framebuffer and setting that up so it's MSAA? As I say above, the actual resolve will happen in hardware and only the resolved colour channel will be written out.
Basically I'm trying to get an existing desktop GL architecture working on ES devices. The way it is setup we have off screen color and depth-stencil surfaces that may or may not be multisampled, and we need to save and restore the contents of each in various places.
We have a path for ES 2.0 that supports copying color only (no depth) via textured quads. In the msaa case we use GL_IMG/EXT_multisampled_render_to_texture on Android when available and save to single sampled textures.
With ES 3.0 we were attempting to use the same path we do on the desktop, with BlitFramebuffer being available to copy depth-stencil surfaces. Since ES 3.0's BlitFramebuffer can't blit to a multisampled destination, we're saving to single sampled color and depth textures, and doing the restore with textured quads (writing gl_FragDepth in the depth case and ignoring the stencil contents).
I just did a test trying to use glFramebufferTexture2DMultisampleEXT with a depth texture and I get an INVALID_ENUM error. Looking at the spec for the extension:
http://www.khronos.org/registry/gles/extensions/EXT/EXT_multisampled_render_to_texture.txt
It seems to say that the attachment point must be GL_COLOR_ATTACHMENT0 so I'm not sure this will work to get multisampled depth textures.
If we can't get msaa depth surfaces working this way I think we're probably better off just limiting Mali ES 3.0 capable devices to either our ES 2.0 path, or ES 3.0 with no msaa. This is not really a serious problem for us right now, I just wanted to make sure you guys were aware of it so it can get fixed at some point.
Hi eodabash,
Just a quick update, we can't reproduce this on trunk (since last October), and the issue only appears to be present on the driver running on the Nexus 10. When they update to something more recent this issue should go away . I had another look at the apk with MGD and had a few ideas for workarounds if you are interested, but accept that this isn't a big issue for you currently as you have an alternate path. Thanks again for bringing it to our attention.
Chris