Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Allow creating slimpeller engine variants. #51824

Merged
merged 2 commits into from
Apr 2, 2024

Conversation

chinmaygarde
Copy link
Member

@flutter-dashboard
Copy link

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 "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use 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.

@chinmaygarde
Copy link
Member Author

Just adding a new target to start getting this wired up on CI (I'll probably need some help here). Doesn't actually enable any of the savings.


# Whether binary size optimizations with the assumption that Impeller is the
# only supported rendering engine are enabled.
slimpeller = false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, let's use a less cute name, like remove_skia_gpu_backend please.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guessing that this is going to be used for ifdef guards around the Skia GPU code. In that case, we might want to avoid double negatives (#ifndef REMOVE_SKIA_GPU) and instead call it include_skia_gpu so that it would be #ifdef INCLUDE_SKIA_GPU in the code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems reasonable, just something that isn't a codename or a double negative!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dashboard tracks more than just removing Skia GPU with this effort (like removing the built-in codecs as well as the Skia software backend).

let's use a less cute name

Why? Did I miss a memo? To borrow your phrase, I am not taking suggestions for an alternate name at this time.

Copy link
Contributor

@matanlurey matanlurey Apr 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are making a joke and I don't get the reference (the link you provided is an internal link that probably should not be linked here in general) feel free to ignore.... but if not - this is team project, and I would not possibly be able to know that "slimpeller = true" means, for example, the built-in codecs change, and I suspect that goes the same for our gardeners and rollers.

If include_skia_gpu_and_built_in_codecs is not sufficient, then another idea is to break it into two flags (include_skia_gpu, include_skia_built_in_codecs).

tl;dr: Not trying to be persnickety, I'm trying to make future debugging easier.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link I provided is obfuscated behind a UUID. So you can't read it if you aren't on the channel (you are). But, yeah, the context is that that we added DeathRattle as an alternative to fml::ScopedCleanupClosure. Thought it was cute (and less readable, made future debugging harder as you put it). Which is to say, I don't think there is a moratorium on using cute names in the codebase. So I reject the notion that we should stop introducing them now.

Back to the point though, I need one simple engine variant I can wire up on CI where the various action items listed on the dashboard can be implemented and their size binary size impact tracked. All items related to this effort are tracked on a dashboard and labelled. What the flag does is documented in GN file as well as the help string for ./flutter/tools/gn. Trying to figure out what slimpeller is supposed to be is trivial. include_skia_gpu_and_built_in_codecs is pedantic and as the effort continues to evolve and, say implements the removal of the codecs, becomes out of date. Hence the name.

I am not trying to do this to be cute. Need one variant I can put on CI that tracks an evolving effort (that does more than Skia GPU removal).

Copy link
Contributor

@matanlurey matanlurey Apr 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aside: I am perfectly fine with renaming DeathRattle (which is a test only appliance that cannot impact user code) - flutter/flutter#146105.

I strongly don't think we should be using code names like this. An engine variant does not have to be tied to a single flag (you can setup the variant and flip the flags however you want), that is, you can create a slimpeller variant that turns both the flags to false.

What I am asking for is to pick flags that accurately explain what something is doing, in so far that a gardener, sheriff, google3 roller, or even a client name downstream will be able to understand why something might have impacted or broke them. This is a very reasonable request, but I'm also happy to bring up at the weekly and get other opinions if comes to that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impeller is a codename, so is flow, so is Skia. I obviously feel less strongly about codenames. No Flutter user/developer cares about these. But these are already part of the lexicon of the sheriffs and gardeners (who are neither real sheriffs nor gardners).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, request withdrawn.

@chinmaygarde chinmaygarde added the autosubmit Merge PR when tree becomes green via auto submit App label Apr 2, 2024
@auto-submit auto-submit bot merged commit c60b00a into flutter:main Apr 2, 2024
@chinmaygarde chinmaygarde deleted the slimpeller branch April 2, 2024 20:23
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Apr 2, 2024
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Apr 2, 2024
…146157)

flutter/engine@5bf8b94...c60b00a

2024-04-02 [email protected] Allow creating slimpeller engine variants. (flutter/engine#51824)
2024-04-02 [email protected] [Impeller] fix plus blend mode in porterduff shader. (flutter/engine#51792)

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 [email protected],[email protected],[email protected] 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
autosubmit Merge PR when tree becomes green via auto submit App
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Prepare an engine variant that tracks work towards removing heavy dependencies.
3 participants