-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Flutter GPU] Add missing MSAA stuff. #55424
Conversation
1b9c386
to
e1b0e6a
Compare
lib/gpu/lib/src/render_pass.dart
Outdated
@@ -21,6 +21,32 @@ base class ColorAttachment { | |||
|
|||
Texture texture; | |||
Texture? resolveTexture; | |||
|
|||
void _assertValid() { |
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 think this would be easier to read if you wrote it as a regular error checking function, throwing exceptions, then only called the function in an assert.
This is a regular pattern used in the framework, for example: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/animation/animation_controller.dart#L551-L564
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.
Thanks. I updated this. Let me know if you think I can improve the pattern more.
lib/gpu/render_pass.cc
Outdated
{ | ||
impeller::DepthAttachment desc; | ||
desc.load_action = flutter::gpu::ToImpellerLoadAction(depth_load_action); | ||
desc.store_action = flutter::gpu::ToImpellerStoreAction(depth_store_action); | ||
desc.clear_depth = depth_clear_value; | ||
desc.texture = texture->GetTexture(); | ||
if (resolve_texture) { |
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 depth/stencil attachments should have a resolve field.
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 we don't need to open this can of worms. Removed.
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.
maybe I made a mistake when reading this but it looks like this was from the same attachment as the color attachment but maybe that isn't the case.
Feel free to open the can of worms as needed
e1b0e6a
to
281c668
Compare
/// There is currently no way to render directly against the "onscreen" | ||
/// texture that the framework renders to, so all Flutter GPU textures are | ||
/// "offscreen". | ||
bool get doesSupportOffscreenMSAA { |
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 a thought. Maybe this doesn't actually need to be exposed at all.Just let folks construct the same MSAA or non-MSAA topolgy, and if its not supported then ignore the transient attachments and use the resolve attachment.
Practically speaking, the number of devices flutter targets that does not support MSAA is sooo small. I don't know if its worth carrying around in our API.
Additionaly, I don't know if this handles it but we need to do MSAA a bit differently for GLES. We don't ever actually allocate the transient attachment.
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.
Oooh, I think for the common case of kMultisampleResolve
, coercing to kStore
and ignoring the multisample texture just about works. But unfortunately, things get funky with kStoreAndMultisampleResolve
and I don't think we can reasonably assume the user's intent.
Additionaly, I don't know if this handles it but we need to do MSAA a bit differently for GLES. We don't ever actually allocate the transient attachment.
IIRC we did this in a way where it automagically does the right thing when you try to allocate a transient multisample texture on GLES (unless I'm thinking of the wrong thing). :)
If there's special HAL usage surrounding this, could you link to where we're doing it in the 2D renderer to help jog my memory?
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'm not sure if it would work automatically or not, see
engine/impeller/renderer/render_target.cc
Line 342 in 2d0eac0
if (context.GetCapabilities()->SupportsImplicitResolvingMSAA()) { |
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 think SupportsImplicitResolvingMSAA
is just for MSAA against the onscreen texture
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.
No, this is used for all offscreen MSAA on the GLES backend.
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'm remembering this now. I don't know if I can easily hide this complexity under the API. With the way the HAL currently works, I would have to surface and document SupportsImplicitResolvingMSAA
. The user is in an alternate reality where they have to creates, attach, and bind fake multisample textures.
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'm not sure the right way to fix this in the API, but maybe consider only supporting MSAA on metal/vulkan for now and coming back to 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.
Yeah. I changed this to add a graceful fallback to not use MSAA when "normal" MSAA support is not possible. I kept the doesSupportOffscreenMSAA
check, but now it also returns false if "implicit" MSAA is available.
A renderer could easily use this check to fallback to other AA techniques (such as FXAA) when MSAA is unavailable.
281c668
to
33d9f51
Compare
33d9f51
to
2d39218
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.
LGTM (but not to CI)
b2de4d1
to
29bd4c4
Compare
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. |
…157317) flutter/engine@b3e227b...8828844 2024-10-22 [email protected] [Flutter GPU] Add missing MSAA stuff. (flutter/engine#55424) 2024-10-22 [email protected] Roll Skia from 3a081993e2a7 to a71df7d9bc63 (24 revisions) (flutter/engine#56005) 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
Resolves flutter/flutter#144264.