-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] iOS/macOS: Only wait for command scheduling prior to present #40781
Conversation
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
753d254
to
21d2761
Compare
Gonna change this up to do the trick that we do in the macOS embedder and just create an empty command buffer/wait for it: https://github.com/flutter/engine/blob/main/shell/platform/darwin/macos/framework/Source/FlutterSurfaceManager.mm#L127 |
8dced25
to
7dbc0c5
Compare
7dbc0c5
to
b90ef01
Compare
@@ -127,7 +130,11 @@ | |||
return false; | |||
} | |||
|
|||
[drawable_ present]; | |||
id<MTLCommandBuffer> command_buffer = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lock can fail in case of context loss. We need to check and return false from this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, derp. You got rid of the weak ptr. I think the weak ptr does make more sense though. We just need to be able to survive context loss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just switched to hanging onto a shared_ptr
instead.
bbb8bf4
to
cbff90d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I slightly favor the weak hold on the context. As a habit, I think we should not hold onto the context via a strong reference from objects derived from the context itself. Its easy to get into a case where we cause reference cycles. I could image surfaces being held by swapchains and such.
Having said that though, I this this use is probably safe. But again, weak ptrs with a lock checks I like better.
cbff90d
to
3174bc1
Compare
Alrighty, seems reasonable. Added the weak ptr back with a check. |
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. |
…123833) flutter/engine@571c5de...c0e7cd5 2023-03-31 bdero@google.com [Impeller] iOS/macOS: Only wait for command scheduling prior to present (flutter/engine#40781) 2023-03-31 skia-flutter-autoroll@skia.org Roll Skia from 9b2e538f1367 to f6c1eefd4600 (4 revisions) (flutter/engine#40807) 2023-03-30 dnfield@google.com Revert "[Impeller] move everything needed by the code gen template to core (#40801)" (flutter/engine#40811) 2023-03-30 dnfield@google.com [Impeller] Delete dead code from reflector.cc (flutter/engine#40805) 2023-03-30 dnfield@google.com [Impeller] move everything needed by the code gen template to core (flutter/engine#40801) 2023-03-30 jacksongardner@google.com `ui_web` library (flutter/engine#40608) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…to present" (#40895) Reverts #40781 Fixes flutter/flutter#124056 When unmerging threads we appear to get stuck for multiple seconds. Haven't debugged further, but bisected to this commit.
…lutter#123833) flutter/engine@571c5de...c0e7cd5 2023-03-31 bdero@google.com [Impeller] iOS/macOS: Only wait for command scheduling prior to present (flutter/engine#40781) 2023-03-31 skia-flutter-autoroll@skia.org Roll Skia from 9b2e538f1367 to f6c1eefd4600 (4 revisions) (flutter/engine#40807) 2023-03-30 dnfield@google.com Revert "[Impeller] move everything needed by the code gen template to core (flutter#40801)" (flutter/engine#40811) 2023-03-30 dnfield@google.com [Impeller] Delete dead code from reflector.cc (flutter/engine#40805) 2023-03-30 dnfield@google.com [Impeller] move everything needed by the code gen template to core (flutter/engine#40801) 2023-03-30 jacksongardner@google.com `ui_web` library (flutter/engine#40608) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
edit: This was updated to just wait for scheduling in a new command buffer. Similar to how we already do in the macOS embedder, but better because we don't even block on the current thread thanks to presentDrawable.
This patch makes us conform to the docs and sync properly for the drawable present, and gets rid of the excessive
waitUntilScheduled
blocking on iOS sim. Tested on iPhone 12, iPhone 6s, and x64 sim.Open to ideas for better architecting this. Waiting for the last committed command buffer to be scheduled is the same as waiting for all previously committed command buffers to be scheduled. Command buffers are scheduled in queue order.
Explanation:
Sleuthing through the Metal docs for all the calls we're making, I found one thing that's unsafe about not doing
waitUntilScheduled
on iOS, but I'm only able to reproduce symptoms of an actual problem on iOS sim. Wondrous on iPhone 12 and iPhone 6s seems to run perfectly fine withoutwaitUntilScheduled
, but the simulator is a choppy mess because we're flipping too fast:Screen.Recording.2023-03-29.at.10.37.33.PM.mov
The problem is that immediately after we're done committing our buffers to the root texture, we present by calling
MTLDrawable.present()
.The docs for
present
say:The scheduled part is key here -- committing the buffer signals to the queue that it's ready to be scheduled.
MTLCommandBuffer.commit()
docs:This is slightly ambiguous, but we know this call doesn't block on scheduling; scheduling happens in the background sometime after
commit()
is called, hence the existence ofwaitUntilScheduled()
.