[Impeller] dont print format strings for blend filter and snapshots. #57105
Conversation
jonahwilliams
changed the title
|
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. |
gaaclarke
left a comment
gaaclarke
left a comment
There was a problem hiding this comment.
Instead of removing the labels altogether can we just remove the sprintf calls? That's where all the overhead is coming from anyways I think.
| #ifdef IMPELLER_DEBUG | ||
| pass.SetCommandLabel( | ||
| SPrintF("Advanced Blend Filter (%s)", BlendModeToString(blend_mode))); | ||
| pass.SetCommandLabel(BlendModeToFilterString(blend_mode)); |
| std::nullopt, // sampler_descriptor | ||
| msaa_enabled_, // msaa_enabled | ||
| /*mip_count=*/mip_count, | ||
| SPrintF("Contents to %s Filter Snapshot", label.c_str())); // label |
There was a problem hiding this comment.
Instead of removing this argument, can we just send the argument directly here. That way we'd remove the sprintf but keep valuable debugging information?
There was a problem hiding this comment.
It always gets sprintf'd with the existing texture label. I just don't think these are useful - you can already see the pipeline in the debugger.
and if we do find out we need them its easy to add back.
There was a problem hiding this comment.
These are printed out in validation logs too, you won't always have the opportunity to inspect the pipeline. Where ever it is getting sprintf's? We should be able to just take a string verbatim instead of trying to modify it. That's more useful than having no label. If we are trying to debug a customer's issue it won't be easy to add them back in.
There was a problem hiding this comment.
@gaaclarke do you use this feature? I don't . If it turns out to be useful, we can add it back.
There was a problem hiding this comment.
Yes, I've benefited from having debug labels when responding to a warning printed out from validation layers. We've had vulkan in a good state for a while I think we've forgotten how useful they can be. Respectfully, I think you are throwing out the baby with the bath water. The expensive part is the sprintf/malloc/free calls, not the actual labelling. I'd rather we throw those out first and remeasure.
There was a problem hiding this comment.
This is not a baby or bathwater. its a debug label. If we need it, we can add it back.
There was a problem hiding this comment.
Can we keep the string literals in the source code and conditionally use them? Then the compiler will just rip them out if they aren't used. They aren't going to be easy to bring back. Bringing them back would be recreating something we already had, it will be easier for us to just maintain them. Any patch will bit rot pretty fast.
There was a problem hiding this comment.
You PR that landed today basically did that, right? It makes it so naming textures is a noop, so can we just keep the literals in the code to make them easy to turn on?
| std::nullopt, // sampler_descriptor | ||
| true, // msaa_enabled | ||
| /*mip_count=*/mip_count, | ||
| SPrintF("Filter to %s Filter Snapshot", label.c_str())); // label |
|
I updated this to keep the labels, but changed them to static string_views and removed the additional formatting. |
gaaclarke
left a comment
gaaclarke
left a comment
There was a problem hiding this comment.
Awesome, good call. Accidentally copying strings but not actually used them could have still created overhead we didn't want.
jonahwilliams
added
the
autosubmit
…160220) flutter/engine@9b51e30...5eedfef 2024-12-13 [email protected] Normalize round rect bounds when coming from Flutter (flutter/engine#57171) 2024-12-13 [email protected] [ios]enable the webview non tappable workaround by checking subviews recursively (flutter/engine#57168) 2024-12-12 [email protected] removed c style casts and enabled the lint (flutter/engine#57162) 2024-12-12 [email protected] [Impeller] exploit perfect hash for SamplerDescriptor. (flutter/engine#57036) 2024-12-12 [email protected] Reenabled labelling test with a capabilities check. (flutter/engine#57160) 2024-12-12 [email protected] [Impeller] dont print format strings for blend filter and snapshots. (flutter/engine#57105) 2024-12-12 [email protected] Make fl_engine_send_key_event into a standard async function. (flutter/engine#57112) 2024-12-12 [email protected] Roll Fuchsia Linux SDK from HJ57Y3zxqDamI8qkY... to iWMEbVYaNdH8RJmXZ... (flutter/engine#57163) 2024-12-12 [email protected] Migrate FlPlatformChannel tests to FlMockBinaryMessenger (flutter/engine#57140) 2024-12-12 [email protected] Migrate FlBasicMessageChannel tests to FlMockBinaryMessenger (flutter/engine#57115) 2024-12-12 [email protected] Migrate layers and layer_tree to DisplayList/Impeller geometry classes (flutter/engine#57153) 2024-12-12 [email protected] [web] Use CanvasKit to run tests under engine/ (flutter/engine#54786) Also rolling transitive DEPS: fuchsia/sdk/core/linux-amd64 from HJ57Y3zxqDam to iWMEbVYaNdH8 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] 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
…lutter/engine#57105) We can use a macro to distinguish between all of the blend modes. We don't need to distinguish between porter duff/ advanced /pipeline as the pipeline is already labeled with the shader used. For all snapshots the additional label on the texture isn't useful since we can just look at the command.
2 participants
We can use a macro to distinguish between all of the blend modes. We don't need to distinguish between porter duff/ advanced /pipeline as the pipeline is already labeled with the shader used.
For all snapshots the additional label on the texture isn't useful since we can just look at the command.