EGL_BAD_ACCESS on Vivante GC1000 (driver doesn't support making a window context current on a non-platform main thread)

[mikemimik]

Steps to Reproduce

• fresh flutter create myapp
• cd myapp
• flutter run -d DEVICE_ID
• logs below

Logs

OrionsBelt:testingapp orion$ flutter run -d 47900c1859623100
Building APK in debug mode (android-arm)...         7458ms
Installing build/app.apk...                         18022ms
E/flutter ( 9282): [ERROR:../../flutter/shell/platform/android/android_context_gl.cc(230)] Could not make the context current
E/flutter ( 9282): [ERROR:../../flutter/shell/platform/android/android_context_gl.cc(49)] EGL Error: EGL_BAD_ACCESS (12290)
W/flutter ( 9282): [WARNING:platform_view.cc(157)] WARNING: Could not setup an OpenGL context on the resource loader.
E/flutter ( 9282): [ERROR:../../flutter/shell/platform/android/android_context_gl.cc(230)] Could not make the context current
E/flutter ( 9282): [ERROR:../../flutter/shell/platform/android/android_context_gl.cc(49)] EGL Error: EGL_BAD_ACCESS (12290)
I/flutter ( 9282): [INFO:SkFontMgr_android_parser.cpp(608)] [SkFontMgr Android Parser] '/system/etc/fonts.xml' could not be opened
I/flutter ( 9282):
I/flutter ( 9282): [INFO:SkFontMgr_android_parser.cpp(608)] [SkFontMgr Android Parser] '/vendor/etc/fallback_fonts.xml' could not be opened
I/flutter ( 9282):
Syncing files to device...                          10660ms
Running lib/main.dart on SM T110...

🔥  To hot reload your app on the fly, press "r" or F5. To restart the app entirely, press "R".
The Observatory debugger and profiler is available at: http://127.0.0.1:8100/
For a more detailed help message, press "h" or F1. To quit, press "q", F10, or Ctrl-C.

Flutter Doctor

[✓] Flutter (on Mac OS, channel master)
    • Flutter at /Users/orion/dev-build/flutter
    • Framework revision 15fb5c4ca6 (64 minutes ago),
    • Engine revision ce8b187914
    • Tools Dart version 1.21.0-dev.3.0

[✓] Android toolchain - develop for Android devices (Android SDK 22.0.1)
    • Android SDK at /Users/orion/Library/Android/sdk
    • Platform android-22, build-tools 22.0.1
    • Java(TM) SE Runtime Environment (build 1.8.0_91-b14)

[✓] iOS toolchain - develop for iOS devices (Xcode 8.1)
    • XCode at /Applications/Xcode.app/Contents/Developer
    • Xcode 8.1, Build version 8B62

[✓] IntelliJ IDEA Community Edition (version 2016.2.5)
    • Dart plugin installed
    • Flutter plugin installed

[✓] Connected devices
    • SM T110 • DEVICE_ID                         • android-arm • Android 4.2.2 (API 17)
    • leetpad • DEVICE_ID • ios         • iOS 9.3.5 (13G36)

[eseidelGoogle]

Any ideas @chinmaygarde? We don't seem to have one in the lab, but we can easily order one if necessary. Looks like EGL is failing to initialize?

Looks like this is the device: http://www.devicespecifications.com/en/model/6e2f2a7a

Supposedly a Vivante GC1000, which is a rather uncommon GPU ~1.4% of devices according to unity's numbers: http://hwstats.unity3d.com/mobile/gpu-android.html

According to the spreadsheet I've seen, I'm not sure this config is currently covered in Skia's testing matrix. FYI @jcgregorio (it's not clear that it needs coverage, just FYI in case you'd like to see this report).

[jcgregorio]

Correct, we currently don't have any Vivante coverage, I will make sure a Vivante device gets added to the list of devices we add this quarter.

[chinmaygarde]

Haven't seen such errors before. We should get a hold of the device. This is in the platform initialization before we call into Skia. EGL_BAD_ACCESS could happen if the context is current to some other thread. However, we only ever initialize the main and resource loading context on their dedicated threads. And this is happening for both contexts.

[eseidelGoogle]

I don't see one of these devices in the lab. @chinmaygarde please order one. This looks like the device: https://www.amazon.com/Samsung-Galaxy-Lite-7-Inch-Dark/dp/B00HWMPSL0

[mikemimik]

Device Info: Model number: SM-T110 Android version: 4.2.2

Kernel version:
3.4.5-2828964
se.infra@SWDB2805 #2
Thu Apr 16 14:00:00 KST 2015

Build number: JDQ39.T110UEUAOD1

[eseidelGoogle]

I now have one of these on my desk.

[mikemimik]

Let me know if there is anything more I can do to help with this issue.

[eseidelGoogle]

@chinmaygarde now has the device and I suspect will find the answer soon. :) @mikemimik is also often found in the Flutter gitter if needed.

[chinmaygarde]

Just an update. I am able to reproduce the issue but have not been able to figure out the root cause or determine a fix. So far, I have tried:

• Checked if the context was bound on any other thread. This is the documented reason for an EGL_BAD_ACCESS. It wasn't. The bad access happens on the very first bind.
• Checked if the device did not support multiple context. It does. Just to be absolutely safe, I also tried disabling the resource loading context so there was only ever one context. No difference. Same bad access on first bind of the window context.
• Checked if the context could only be made current on the thread on which it was created. Definitely a long shot. Rethreaded the creation so that the single context was created on the thread on which it was bound. No difference. Same bad access on first bind.
• Checked if there was any way we could be passing in a config the device did not support. We don't. Only configs returned via eglChooseConfig are ever used. Even in case of failures, the context creation should fail. Not the bind.
• Does the device support ES 2.0. Doubtful. adb shell dumpsys SurfaceFlinger seems to indicate the device supports only 1.1 GLES: Vivante Corporation, GC1000 Graphics Engine, OpenGL ES-CM 1.1. However, we were able to create an ES 2.0 context. Even then, this was on the first bind. Not first use of the higher client API.

Honestly, I am out of ideas.

cc @jason-simmons, @abarth: Did I miss anything? Anything else come to mind?

[eseidelGoogle]

@chinmaygarde do we want to just wait until @jcgregorio and co. get a device to see if the normal Skia tests even run on the device?

[chinmaygarde]

On a hunch, @jason-simmons and I hypothesized that maybe this driver could not make a window context current on a non-platform main thread. I have verified that this is indeed the case. I was able to initialize an ES2 context and make it current only on the main thread. Also, I could not make a resource loading context (so a non-window pbuffer context) current on any other thread either.

The way I see it, there are multiple ways to fix this issue for this driver, all shitty:

1. Attempt to make the resource loading context current on the background thread and have that fail. The resource loading context is not mandatory and we already have fallback paths in place. There will be an immense performance hit on this device. But, ultimately, this is not a fatal error.
2. Work around the limitation of not being able to make the context current on a non-platform main thread in one of the following ways:
   • Get rid of a separate GPU thread. Instead use the platform main thread as the GPU thread on all Android devices. The upside is that it is easy to implement and the code is clean without any weird device specific workarounds or checks for hacks. The downside is that platform events (touches, lifecycle events, VSync pulses, etc.) will be backed up by the workload being currently performed on the GPU thread.
   • Get rid of the separate GPU thread by merging it with the platform thread, but, only after doing a startup check where the platform attempts to switch threads on initialization and attempts to make the window context current. The upside is that only buggy driver pay the performance penalties mentioned above. Also, we don't need device specific blacklists. Other devices that have similar issues will be automatically handled by this check. The downside is that all Android devices need to perform this check at startup. This adds a small overhead because we need to switch thread, make the context current and clear it and then latch on the whole operation.
   • Perform the thread responsibilities merging by performing a vendor check. Code is uglier and hard to maintain but otherwise no penalties borne by non-buggy drivers.
3. Not handle the issue at all and blacklist the device. We don't have a mechanism to do this yet. But thought I would just put it out there.

@eseidelGoogle We face this issue in the embedder before Skia is even initialized. So I doubt anything in Skia can help us.

I don't know what the best thing to do here is. But I have detailed the options. Thoughts?

[mikemimik]

Presented with the above information, my thoughts are:

• How many devices actually have this issue?
  • Is it limited to this Android OS version?
  • Is it limited to this manufacturer?
  • Is it a piece of hardware causing the issue? Thus devices with this hardware will have the issue. (can you target a fix for them?)
• I'm reminded of the "needs of the many, outweigh the needs of the few"
  • If this is just a specific device issue (and there aren't many), I would be in favour of creating a blacklist and putting this device on it.

[eseidelGoogle]

@chinmaygarde I recommend we just start a blacklist of devices which Flutter does not support out of the box. I'm not exactly sure how that should manifest, but the goal would be to provide guidance to customers as to what devices their Flutter-using apps can/should work on. @jcgregorio knows some about Skia blacklisting and may have further thoughts since other clients of Skia may have this issue?

[eseidelGoogle]

@mikejurka my understanding from reading http://hwstats.unity3d.com/mobile/gpu-android.html is that 1.4% of GPUs seen by unity in the wild are this GPU. :/ I still believe that for now we should look into blacklisting this for expediency, and consider other more complicated/performance-compromising options later.

[mikejurka]

Did you mean @mikemimik ?

[mikemimik]

@mikejurka I do think https://github.com/flutter/flutter/issues/6886#issuecomment-264650217 was meant for me.

@eseidelGoogle I agree with you, the device (at this point) should just be blacklisted. Might we look into if all android devices with this GPU are affected, then a more broad blacklist for the GPU could be applied.

[bboydflo]

I'm trying flutter for the first time with the default counter app on an older android device (4.1.2) and get these errors

Syncing files to device GIRCGYKFRST8UCOF... D/skia (25678): [SkFontMgr Android Parser] '/system/etc/fonts.xml' could not be opened D/skia (25678): [SkFontMgr Android Parser] '/vendor/etc/fallback_fonts.xml' could not be opened

It works fine in the emulator

[Hixie]

Moving to next milestone since this doesn't affect a large portion of our users at this time.

[fourscience]

@chinmaygarde @mikemimik o/ So a side note on this, would it be resolved for other devices with a custom shell built on top of the embedder? As far as i can get it seems like, exposing the task runners (just like the platform one) probably could resolve this, and it's like in the code since ages to implement the others, like io, render just like the platform one.

A note on this that i'm pushing this on an LG TV and seems like the call's fail to bad access no matter what (like the first call). Probably i'm facing the same issue here. Any ideas? Shall i try to implement the rest of the runners on top of the embedder? 🤔

[mossmana]

Adding the fyi-engine label since this may involve additional investigation from the engine team. Do we know if impeller helps to address this issue?

[jonahwilliams]

We're closing this as stale as the device in question is ancient and we have no intention of supporting it.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.