1

I'm implementing shadowmapping in OpenGL es 2.0. I use OES_depth_texture extension to render the depth to a DEPTH_ATTACHMENT texture of type UNSIGNED_SHORT. The solution works on my macbook, and even in WebGL. However on Android (Acer B1-721, Mali-400 MP, Android version 4.4.2) there is an issue with clearing the depth texture. I haven't tried on other devices (it's the only android I have).

Most of the time the depth texture simply doesn't clear. Sometimes (very rarely) it clears it one frame. It also clears it when I suspend the app or the screen is dimmed.

I know Mali-400 MP is old, but it does claim it supports OES_depth_texture. Still it sounds like a driver issue. Does anyone have similar experiences? Any ideas for circumventing this issue?

EDIT: The problem isn't only with depth textures. I'm getting similar issues also with a normal depth buffer when rendering to a texture. It gets better when I drop the texture size, but there is still some flickering. Also reducing amount of vertices reduces the flickering. Might be a memory bandwidth issue?

EDIT: Some discussion on this matter https://www.opengl.org/discussion_boards/showthread.php/199655-Clearing-DEPTH_COMPONENT-of-type-UNSIGNED_SHORT-in-gles2-using-OES_depth_texture/page3 It's not only the clearing that isn't working. All operations on a FBO depth buffer (texture or render buffer, doesn't matter) are executed at wrong times in the pipeline or discarded. glFinish fixes the issue but isn't a very good solution otherwise.

Lof
  • 113
  • 7
  • Have you tried flushing after the clear call (glFlush())? Sometimes these these things just help since you claim it acts a bit randomly. – Matic Oblak May 30 '17 at 10:49
  • Thanks for the suggestion. I tried this but it had no effect. – Lof May 30 '17 at 11:41
  • Alright, a glFinish actually did the trick. But I'm not sure why it's needed. My understanding is that it shouldn't be used explicitly. – Lof May 31 '17 at 12:33
  • I haven't thought about that command because I never really had a situation where I needed it. I am glad it fixes your issue but this may present another one. This call MAY interrupt your thread for quite some time and if I may assume we are talking about main thread on Android this is very dangerous to produce a crash. Please try to perform this on a separate thread; ensure that your context is set as current on that thread and wait for execution to finish. By wait I mean have some flag in your draw method and if the operation is being executed there discard all other openGL calls. – Matic Oblak May 31 '17 at 14:28
  • Sorry for using comments but this is not yet ready for an answer... So with this idea when finish is being called your draw method should do nothing at all and may be called multiple times until the finish command is done executing. Once the execution is done the drawing method should be unlocked and proceed with drawing. Just in case I would add a bit of sleep when testing to see if all goes well when frames are being dropped (remove the sleep once done). If it all works well please formulate an answer with code you did included and mention me in comment so I can remove these. Thank you. – Matic Oblak May 31 '17 at 14:33

0 Answers0