• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Subscribers 137 subscribers
  • Views 52222 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

glInvalidateFramebuffer problem

Esenthel

Hello,

My app works OK on:

-Windows Desktop GL

-Apple iOS iPad mini 2

-Samsung Galaxy Note 4 (ARM Mali-T760)

-Sony Xperia XZ2 Adreno 630

However when running on:

Huawei Mate 20 X (ARM Mali-G76) version OpenGL ES 3.2 v1.r16p0-01rel0.95d2435cbe2284d49b9bbcf5b1624fdd

Then I'm getting problems.

Expected results:

ARM Mali results:

after touching the screen to rotate the camera

I'm suspecting a driver bug.

This problem appears to be related to 'glInvalidateFramebuffer', if I replace all glInvalidateFramebuffer calls with glClear (or just remove the glInvalidateFramebuffer calls), then it starts to work ok.

Please check this link which includes APK files and images:

https://www.dropbox.com/sh/17lho4zzuwhuh4r/AACiAVIiSTxSv5_CeMDSqPSZa?dl=0

Thank you,

Greg

Parents
  • +1 in reply to Esenthel
    Esenthel said:

    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'll let you know when I have a more concrete diagnosis from the driver team.

    For Mali using a glClear at the start of the render pass performs the same as using glInvalidateFramebuffer; both will set the tile memory to clear color and that is a free operation at the start of the render pass. Given you know this works it seems like the safest option. 

    I have an untested hunch that another workaround would be to use a different container FBO for each of the different resolutions and/or viewports that you are rendering. This is just an educated guess and I've not had time to test it.

    Esenthel said:
    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?

    We make the drivers available as soon as we have fixes. How those drivers get downstream to specific devices is unfortunately completely out of our hands.

    I'll update this thread when I know more.

    HTH, 
    Pete

Reply
  • +1 in reply to Esenthel
    Esenthel said:

    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'll let you know when I have a more concrete diagnosis from the driver team.

    For Mali using a glClear at the start of the render pass performs the same as using glInvalidateFramebuffer; both will set the tile memory to clear color and that is a free operation at the start of the render pass. Given you know this works it seems like the safest option. 

    I have an untested hunch that another workaround would be to use a different container FBO for each of the different resolutions and/or viewports that you are rendering. This is just an educated guess and I've not had time to test it.

    Esenthel said:
    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?

    We make the drivers available as soon as we have fixes. How those drivers get downstream to specific devices is unfortunately completely out of our hands.

    I'll update this thread when I know more.

    HTH, 
    Pete

Children