You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
android_hardware_smoke_opengles_instrumented_tests is flaky #196453
I believe #196069 is the root cause, and it seems this introduced a real startup error race / deadlock on opengles during engine startup.
I haven't spent the time to fully understand it, but AI suggests the problem is this: Prewarming default OpenGL ES shaders during engine startup can schedule compilation jobs on the IO thread before the IO thread's EGL context has been made current. Because those jobs are silently skipped and removed from the compile queue without fulfilling their futures, the raster thread later deadlocks indefinitely waiting on those uncompiled shaders during rendering.
This test shard was particularly impacted by this because it starts a new flutter engine with openGL nine times in one run. This might be the first real issue caught by my suite!
cc @gaaclarke I think we should probably revert #196069. I'm also seeing that while it improved startup latency on my stress test app that uses a lot of shaders on the first frame, it regressed startup latency on the complex_layout benchmark that only uses a few shaders on the first frame.
Activity
andywolff commentedon Nov 12, 2026
I believe #196069 is the root cause, and it seems this introduced a real startup error race / deadlock on opengles during engine startup.
I haven't spent the time to fully understand it, but AI suggests the problem is this: Prewarming default OpenGL ES shaders during engine startup can schedule compilation jobs on the IO thread before the IO thread's EGL context has been made current. Because those jobs are silently skipped and removed from the compile queue without fulfilling their futures, the raster thread later deadlocks indefinitely waiting on those uncompiled shaders during rendering.
This test shard was particularly impacted by this because it starts a new flutter engine with openGL nine times in one run. This might be the first real issue caught by my suite!
zanderso commentedon Nov 12, 2026
cc @gaaclarke I think we should probably revert #196069. I'm also seeing that while it improved startup latency on my stress test app that uses a lot of shaders on the first frame, it regressed startup latency on the complex_layout benchmark that only uses a few shaders on the first frame.
zanderso commentedon Nov 12, 2026
Possibly also more clearly a win with OpenGL than with Vulkan, but needs more investigation.
gaaclarke commentedon Nov 12, 2026
Interesting, okay. I can give it another look. Thanks guys.
gaaclarke commentedon Nov 12, 2026
When this is closed I'll file another issue to investigate relanding.
Revert: [android]: prewarms shaders when the context is created (flut…
[android] Adds failing test for GLES pipelines requested before the I…
[android] Flushes IO thread reactor operations once its resource cont…
[android] Only prewarms default pipelines for OpenGL ES
[android] Warms default pipelines once the IO thread's resource conte…