-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] Add StC color source/clip behavior + constexpr flag for enabling StC. #50817
Conversation
12a3ee0 to
07d6e72
Compare
c7c1687 to
90d5e29
Compare
| if (is_stencil_then_cover) { | ||
| pass.SetStencilReference(0); | ||
|
|
||
| /// Stencil preparation draw. |
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.
What is the stencil preparation?
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 i c, I think I'm just having a hard time following this code now. This is essentially taking whatever geometry we got and configuring how to treat it, in this case it goes to the stencil buffer. Then we add the cover + reset afterwards. makes sense!
jonahwilliams
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.
LGTM!
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.
This is awesome. Mostly nits. I was going to suggest factoring some of this out to reduce cyclomatic complexity since it is getting tough to follow. But I suspect once this is well baked, we won't have the giant constexpr check around kEnableStencilThenCover.
| /// 2. Switches the generic tessellation fallback to use stencil-then-cover. | ||
| /// See also: https://github.com/flutter/flutter/issues/123671 | ||
| /// | ||
| // TODO(bdero): Remove this setting once StC is fully de-risked |
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 don't see an enumeration of anticipated risks. We should jot them down so we aren't surprised. Perhaps discuss during the weekly and I can prep. a list.
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 don't think we need to do that in the source code, we can handle that in the issue tracker
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.
Totally, just pointing out that we don't have that written down anywhere.
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.
Just to clarify my thinking here around this flag:
I think "fully de-risked" wasn't quite the right terminology for me to use here. Overall this is a big change to the perf characteristics of paths and clips, and the biggest risk in my eyes is users encountering slow (but reasonable) usage patterns that I haven't come across/considered.
After the flag flip, overall risk will rapidly decay through:
- Seeing benchmark & golden results
- The team churning on tasks at ToT
- The engine rolling into g3
- Smoke testing (Wondrous, Gallery)
- Profiling the trouble cases
I anticipate the flag's lifespan to be a few weeks. Maybe slightly longer if nontrivial problems pop up and the flag needs to get flipped back and forth a few times.
This flag impacts the config of most RenderPasses and draw calls, so if at some point we decide to keep it around for several months (which I doubt will happen), we should set up golden variations for both modes to avoid bitrot.
|
|
||
| float Entity::GetShaderClipDepth() const { | ||
| return new_clip_depth_ * kDepthEpsilon; | ||
| return std::clamp(new_clip_depth_ * kDepthEpsilon, 0.0f, 1.0f); |
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.
Is this just defensive coding or did you actually run into this?
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, I see the max-uint setting below. Nevermind.
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.
Yeah not sure about keeping the max int pattern... thinking about replacing with a SetMaxDepth or adding a kMaxDepth sentinel to make the code easier to read.
| /// stencil buffer after a stencil-then-cover operation. | ||
| kSetToRef, | ||
| /// Draw the stencil for the nonzero fill path rule. | ||
| kNonZeroWrite, |
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.
For clarity, I suggest the following convention. Make the StencilMode specify the phase in play clearly. Something like k<Phase><Option> perhaps. In my head, with stencil-then-cover, kEvenOddWrite would be kStencilEvenOddFill. You used the term "preparation" above. If you prefer that (I'm warming up to it too), kPreparationEvenOddFill. I found kEvenOffWrite too terse to follow initially. Ditto for the "cover" phase.
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.
You can then document the two phases in detail.
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.
| case StencilMode::kCoverCompare: | ||
| front_stencil.stencil_compare = CompareFunction::kNotEqual; | ||
| front_stencil.depth_stencil_pass = StencilOperation::kKeep; | ||
| front_stencil.depth_stencil_pass = |
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'd add a comment here that says the reference value ought to be zero.
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.
Ditto below.
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.
Added some comments here. This is also documented in the docstrings, but tried to make it a little more clear.
| /// | ||
| // TODO(bdero): Remove this setting once StC is fully de-risked | ||
| // https://github.com/flutter/flutter/issues/123671 | ||
| static constexpr bool kEnableStencilThenCover = false; |
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 like the if constexpr!
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.
Woo! I'll probably use this pattern for other huge feature migrations in the future. ContentContext turned out to be a good place for it because everything in the universe depends on it. ;)
…lag for enabling StC. (flutter/engine#50817)
…143933) flutter/engine@7777480...9250bfd 2024-02-22 [email protected] Roll Skia from 0b55d78d32f9 to b9c16065b76d (1 revision) (flutter/engine#50861) 2024-02-22 [email protected] Roll Skia from cbdbcf9bebe6 to 0b55d78d32f9 (1 revision) (flutter/engine#50860) 2024-02-22 [email protected] Roll Fuchsia Linux SDK from dLhvv964txwnSlvNw... to j9cJ94K-T1i3u5xGh... (flutter/engine#50858) 2024-02-22 [email protected] Roll Skia from ec119f44e6b9 to cbdbcf9bebe6 (2 revisions) (flutter/engine#50857) 2024-02-22 [email protected] Roll Skia from 4aa97aca087c to ec119f44e6b9 (1 revision) (flutter/engine#50849) 2024-02-22 [email protected] [Impeller] Add StC color source/clip behavior + constexpr flag for enabling StC. (flutter/engine#50817) 2024-02-22 [email protected] Roll Skia from 3fd1a5a7c7c1 to 4aa97aca087c (2 revisions) (flutter/engine#50848) 2024-02-22 [email protected] Minor non-semantic refactors of `ExternalTexturesFlutterActivity` (flutter/engine#50845) Also rolling transitive DEPS: fuchsia/sdk/core/linux-amd64 from dLhvv964txwn to j9cJ94K-T1i3 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
Included in this PR is:
This patch shouldn't actually change any behavior when StC is off.