glInvalidateFramebuffer problem

Hi Pete,

My code more or less looks like this:

I have 2 renderings per frame:

-#1 deferred fullscreen

-#2 deferred to small rectangle on the left side, this rendering is partial (doesn't actually draw to default FBO)

---

Rendering #1, deferred fullscreen:

-set custom RT#0 (fbo attachment 0) for color, RT#1 (fbo attachment 1) for normals

-draw meshes

-set custom RT#2 (fbo attachment 0) for light

-calculate per pixel light based on depth and RT#1 normals

-set custom RT#3 (fbo attachment 0) for lit-color

-combine RT#0 color with RT#2 light

-set default FBO

-copy RT#3 lit-color results into default FBO

---

start Rendering #2, deferred to small viewport in left rectangle:

-for this rendering I reuse the same RT's from Rendering #1, (HOWEVER reusing might be in different order, like instead of RT#0, RT#1, RT#2.., there's RT#2, RT#1, RT#0)

-set custom RT#0 (fbo attachment 0) for color, RT#1 (fbo attachment 1) for normals

-draw meshes

-set custom RT#2 (fbo attachment 0) for light

-calculate per pixel light based on depth and RT#1 normals

-set custom RT#3 (fbo attachment 0) for lit-color

-combine RT#0 color with RT#2 light

---

And I've noticed that the problem on Mali already happens, without even copying results from Rendering #2 into the default FBO.

My guess is that the 'glInvalidateFramebuffer' calls from Rendering #2 affect somehow the Rendering #1, because I reuse the same RT's for both renderings.

Also I operate on viewports instead of scissor rectangle if that matters.

I've just made another test, that makes sure to disable any scissor before clearing RT's. And when I replace all glInvalidateFramebuffer with glClear or glClearBufferfv to purple color, then my app works OK, and I don't see any purple pixels. So it really looks like there's some bug with glInvalidateFramebuffer in the driver.

Hi Greg, 

I would expect the behavior of a sub-frame render to be the same (whether you are using scissors or viewports).

Calling glInvalidateFramebuffer() will invalidate the memory contents of the entire surface - irrespective of what scissor or viewport is set - so any region outside of that will contain garbage unless it is explicitly redrawn. If you are reusing attachments across framebuffers then an invalidate in one framebuffer will render the contents of that attachment invalid in all other framebuffers that are using it (i.e. the invalidate applies to the memory content of the attachment not the framebuffer container).

Calling glClear on the other hand will honour both scissor and viewport, leaving the part outside untouched.

The behavior of the two is very different in these cases, so don't expect the rendering to be the same. That said, I'll check the APK now - the devil is in the detail in these cases.

Cheers, 
Pete

glClear and glClearBufferfv are not affected by the viewport, only by scissor.

I use only default FBO (0) and 1 custom FBO, for which I change all attachments depending on what I need.

My engine is cross platform, including directx 11 support, and there there's no concept of a frame buffer, you just attach render targets to 0,1,2.. slots. I find this approach much more natural. So I've built the render target management around that concept. Also I have a lot of post process effects, for which most of the time I need different kind of render targets attached. Creating an FBO for each combination would result in a lot of FBO'S created. Also it would make the render targets have to be strictly attached to those FBO'S. It would apply some restrictions about what render targets I can use and what not. But with my approach, I allocate render targets on demand when I need them, I keep them in a pool of render targets, once an effect is finished, then I mark render target as available for reuse, so it can be used for another post process effect. This way there's no restriction on what render targets can be used for a post process effect, I just reuse the first one available that matches desired resolution and format. 

Just to confirm - I've taken a look at the APK and reproduced the issue on a Galaxy S10. As far as I can tell it is indeed a driver problem, so I'll raise a ticket for the driver team to take a look at it. Thanks for reporting the problem.

Cheers, 
Pete

Thank you very much for taking the time to investigate.

Is the only workaround to simply don't call glInvalidateFramebuffer?

What devices are affected, all Mali G-series? What would be the driver version GL_VERSION that fixes this problem?

I'm looking for a way to identify the affected devices based on GL_RENDERER, GL_VENDOR, GL_VERSION, ..

Even if you release a new driver update, what are the chances that major phone manufacturers (Samsung, Huawei, ..) will include this driver in a software update? Few years ago I've contacted Samsung about their GPU driver not being updated to Galaxy Note 4 (which suffered from shadows not being properly rendered for alpha-tested shaders) and they didn't bother to reply or make an update. Personally I think it's a big problem how Android Manufacturers handle updates, and GPU driver updates. I think a better system should be implemented, for example allowing to install GPU drivers manually.

Thank you very much,

Greg

we have encountered the similar problem, currently we are trying to send GL_DEPTH_STENCIL_ATTACHMENT to glInvalidateFramebuffer, and this works fine on other devices except for the huawei mate 20. on huawei mate 20 an gles error will be throwed out.

This sounds like a different problem. Please raise a new forum post with details, and a reproducer and we can investigate, 

Thanks, 
Pete

Thank you very much, I'll await more info.

Was the bug fixed?