-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] implement external texture gl for embedder. #56277
[Impeller] implement external texture gl for embedder. #56277
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). 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. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
| if (!image) { | ||
| // In case Skia rejects the image, call the release proc so that | ||
| // embedders can perform collection of intermediates. | ||
| if (texture->destruction_callback) { |
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.
@chinmaygarde do we have an existing way to track handles / a place for me to attach to a destruction callback? Otherwise I was just going to add an optional member to texture_gles.
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.
This is a case of the embedder giving us a texture handle, us using it, and then asking the embedder to collect it for us when we are done.
The most accurate way to do this is using the reactor. It knows when the texture handle is no longer in use. Attaching it to TextureGLES isn't going to be safe because of the skew between the destruction of the texture (which can happen on any thread) and the collection of the handle in the reactor (which must happen on one of the GL threads).
I did something similar (but not the same) here where the ownership of the handle is transferred in. See the wrap here of an external_handle. You could augment reactor handles to pass in a callback instead of a known destructor by handle (which essentially calls glDeleteTextures). That way, the handle will be collected at the right time on the right thread.
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.
Got it, thank you!
chinmaygarde
left a comment
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.
Nit about using C++ closures and not tracking the baton separately. Otherwise LGTM.
|
|
||
| namespace impeller { | ||
|
|
||
| typedef void (*VoidCallback)(void* /* user data */); |
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.
In a C++ TU, I think we should stick to using std::function and its niceties. This can just be fml::closure. The closure itself can be constructed like so in the embedder.cc
RegisterCleanupCallback(handle, [callback, user_data]() {callback(user_data);});This way, you don't need to hold onto the user data baton separately either. Its just a single closure.
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.
Done!
| std::optional<GLuint> name; | ||
| std::optional<std::string> pending_debug_label; | ||
| bool pending_collection = false; | ||
| fml::closure callback = {}; |
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.
fml::ScopedCleanupClosure so you don't need to remember to invoke it.
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.
Done
|
auto label is removed for flutter/engine/56277, due to - The status or check suite Mac mac_unopt has failed. Please fix the issues identified (or deflake) before re-applying this label. |
…158038) flutter/engine@38b6165...05cb5d7 2024-11-02 matanlurey@users.noreply.github.com Refactor `BuildPlan`, better document and explain `--config`. (flutter/engine#56324) 2024-11-01 skia-flutter-autoroll@skia.org Roll Fuchsia Linux SDK from MjcuejuzYvYGobbFM... to 07KmbdEtnhkg_tUhe... (flutter/engine#56322) 2024-11-01 jonahwilliams@google.com [Impeller] implement external texture gl for embedder. (flutter/engine#56277) 2024-11-01 skia-flutter-autoroll@skia.org Roll Dart SDK from 789763468d6b to 61bf0877807e (2 revisions) (flutter/engine#56323) Also rolling transitive DEPS: fuchsia/sdk/core/linux-amd64 from MjcuejuzYvYG to 07KmbdEtnhkg 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 chinmaygarde@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://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Fixes flutter/flutter#143809