Reduce pipeline depth when GPU and Platform are same thread #9132
Conversation
|
To add some more context: As we have reached a dead end with the investigation, we've decide to try and reduce exposure to the issue, as a first step by reducing the pipeline depth to 1(which makes it equivalent to the single threaded case as in that case the UI thread never has a chance to submit a frame while the GPU thread is rasterizing). Another potential way to reduce exposure to the problem will be a thread merging strategy that keeps the threads unmerged for as long as possible(once dynamic thread configuraiton lands). We also believe it's likely that we will stop seeing the issue once we move to metal. For anyone coming back to investigate this, to make it easier to reproduce you should set the pipeline depth to 2, make sure you're running with just the gpu and platform threads merged, have some animation ongoing, and type really fast in a Flutter TextField. |
amirh
left a comment
amirh
left a comment
There was a problem hiding this comment.
LGTM (left a comment adding more context as for why we're landing this)
|
(Updated PR description to add more context) |
|
Only other note here - part of the goal of this patch is to have something that is attainable for the next beta to help people who are currently broken. The suggested improvements here are believed to take more time than the next beta. |
flutter/engine@4c4c0f8...fa9b5bd git log 4c4c0f8..fa9b5bd --no-merges --oneline fa9b5bd Reduce pipeline depth when GPU and Platform are same thread (flutter/engine#9132) d479412 Change the virtual display size restriction to warning (flutter/engine#9110) The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff ([email protected]), and stop the roller if necessary.
3 participants
Ameliorates flutter/flutter#31138
This is a work around which should eventually be removed. Users have reported that since splitting the UI and IO threads when platform views are enabled, it is easy to lock up the entire application when typing while an animation (e.g. the blinking cursor or a spinner) is running. This issue most reliably reproduces in profile or release mode, but can be noticed less significantly in debug mode. This change must be reverted if we go to dynamic thread merging and unmerging, as we don't currently handle restoring the pipeline depth when the threads split (only when the animator is constructed).
This patch makes it harder to stall the platform thread on the GPU when the threads are merged by reducing parallelization in rendering/rasterization. In a single threaded configuration, the pipeline never gets a chance to get above 1, whereas when the UI thread is split out it gets a chance to schedule additional frames while the rasterizer is going. In this case, the merged GPU/Platform thread (which is really just the Platform thread), tries to
The problem can be seen in flutter tracing as in the linked bug - a
glClearcall ends up taking much longer than normal, which blocks the platform thread for one or more frames. In Xcode tracing, this can be observed as a 1 second pause with "Thread blocked while waiting for next drawable" (the large purple boxes in the screen shot below):I have three ideas for other, larger scale improvements that may fix this: