PowerVR GE8320 Driver Bug (Crash)

We’re using Unity(a new version, 2022.3.7f1) and we get the following crash at a very high rate ONLY on PowerVR 8320 devices with the Mediatek driver:

#00 pc 00000000001052dc /vendor/lib64/egl/libGLESv2_mtk.so (BuildId: e4df3d68e05df74645dcb8286d896e8b)
#01 pc 000000000010c9d4 /vendor/lib64/egl/libGLESv2_mtk.so (BuildId: e4df3d68e05df74645dcb8286d896e8b)
#02 pc 0000000000072a54 /vendor/lib64/egl/libGLESv2_mtk.so (BuildId: e4df3d68e05df74645dcb8286d896e8b)
#03 pc 0000000000033b18 /vendor/lib64/libsrv_um.so (BuildId: 322a1adcc56edc459a2c8250fa7a2624)
#04 pc 00000000000ed138 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: e210c4c63224a2c0f652a1c781aab289)
#05 pc 000000000008b2a0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: e210c4c63224a2c0f652a1c781aab289)

Given we don’t have symbols for libGLESv2_mtk.so, it’s really difficult to tell exactly what’s happening, but the crash most often occurs when we have many RenderTextures in use.

Many other Unity users complain of the same crash: https://forum.unity.com/threads/there-is-a-bug-and-the-crash-in-libglesv2_mtk-so-on-some-devices.1262033

Things we’ve tried that didn’t work:

  • Injecting a glFlush at the end of every frame
  • Sharing/re-using RenderTextures
  • Drawing once to a RenderTexture and copying to a regular texture so we don’t call CommandBuffer.DrawRenderer repeatedly
  • Limiting our commandBuffer.DrawRenderer usage to just MeshRenderers(not skinned/particles)

This is clearly a driver bug with the GE8320 - all we need to know is what’s triggering it, or at least what the symbolicated callstack is, so we can design a workaround.

What information can I provide to help get more clarity on this crash?

Thank you!

Hi troy-lfg,

Thanks for contacting PVR Developer Forum.
Would you mind send an email to devtech.portal@imgtec.com to discuss more in detail?

It would be good for us to reproduce the issue if you have a chance to share an APK with us with this email.



Done - thanks the for response!

So, while I did not yet receive a response to the ticket, we did figure out a workaround.

The crash occurs when we have a “per material” constant buffer in Unity and goes away when moving those variables to the “$Global” constant buffer.

Since we have a workaround, no more effort is needed, although I’d still be curious what the symbolicated callstack looks like and whether it would have made this a lot easier to track down(we did >50 builds adding/removing features to find it).