-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] support GLES 3.0 MSAA without extension. #56705
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. |
| // Unlike other backends the blit to restore the onscreen fails for GLES | ||
| // if the src is a multisample framebuffer, even if we specifically target | ||
| // the non-multisampled resolve of the dst. | ||
| bool is_gles_and_must_skip_blit = renderer_.GetContext()->GetBackendType() == |
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.
It seems like once we have a multisampled renderbuffer attached to a texture blits will just fail :(
|
FYI @bdero , I think with this approach we can let flutter gpu use a non-weird MSAA approach for GLES 3 (via ANGLE) which should cover all of the windows desktop usage at least. |
| case PixelFormat::kB8G8R8A8UNormInt: | ||
| case PixelFormat::kR8G8B8A8UNormInt: | ||
| return GL_RGBA4; | ||
| return GL_RGBA8; |
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 was fun to find lol
| GLint value = 0; | ||
| gl.GetIntegerv(GL_MAX_SAMPLES_EXT, &value); | ||
| supports_offscreen_msaa_ = value >= 4; | ||
| } else if (desc->GetGlVersion().major_version >= 3 && desc->IsES()) { |
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 is ES only? I don't have a desktop GL test environment.
|
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. |
gaaclarke
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.
Looking super promising. This is giving us MSAA for the render buffer right? Is it also going to give MSAA for offscreen frame buffers? That's what we need for the golden's to be antialiased.
| supports_offscreen_msaa_ = value >= 4; | ||
| } else if (desc->GetGlVersion().major_version >= 3 && desc->IsES()) { | ||
| GLint value = 0; | ||
| gl.GetIntegerv(GL_MAX_SAMPLES_EXT, &value); |
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 you can safely query this without first verifying that GL_EXT_framebuffer_multisample is present.
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.
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 GL_MAX_SAMPLES_EXT mentioned there. The only place I see it mentioned is in documentation for that extension (ex: https://www.khronos.org/opengl/wiki/GL_EXT_framebuffer_multisample). I'm pretty sure it's not standard because it has the _EXT postfix.
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, right that. I think we can just drop the ext
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.
can confirm GL_MAX_SAMPLES_EXT and GL_MAX_SAMPLES have the same value. I can change the latter to GL_MAX_SAMPLES but it doesn't actually matter, I think they should both just be GL_MAX_SAMPLES
| ? TextureGLES::Type::kTextureMultisampled | ||
| : TextureGLES::Type::kRenderBufferMultisampled) |
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 seems odd that it is conflating textures with render buffers. This isn't anything new introduced in this PR though.
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.
The render buffer AFAIK is like the "Device transient" texture, though there is some weirdness with how we treat the implicit msaa stuff
| // with regular GLES 3.0 multisampled renderbuffers/textures. | ||
| if (gl.GetCapabilities()->SupportsImplicitResolvingMSAA()) { | ||
| gl.RenderbufferStorageMultisampleEXT( | ||
| GL_RENDERBUFFER, // target |
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.
please use proper argument comments to get them checked by the linter (ex. /*foobar=*/)
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.
doesn't look like the linter is checking these, maybe something to do with the proc table drop argument names? either that or its a C ABI.
will switch the comment stye regardless
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.
Weird, I double checked we do have bugprone-argument-comment in .clang-tidy.
| // Perform multisample resolve via blit. | ||
| // Create and bind a resolve FBO. | ||
| GLuint resolve_fbo; | ||
| gl.GenFramebuffers(1u, &resolve_fbo); |
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 generating and deleting a frame buffer each frame?
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 offscreen fbos we always generate and delete the fbo AFAIK.
| } | ||
|
|
||
| if (gl.DiscardFramebufferEXT.IsAvailable()) { | ||
| gl.BindFramebuffer(GL_FRAMEBUFFER, fbo); |
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.
It's weird this logic is changing because the new logic above it is in in a conditional, will this be the right thing to do if the conditional above evaluates to true or 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.
it should be safe to rebind the same fbo but I'll move this to the end of the blit instead.
Nevermind, looks like it is based on the golden results. |
|
How is this going to be have on systems using opengles and which have support for offscreen msaa (for example here: engine/impeller/display_list/dl_dispatcher.cc Line 1248 in d5820a6
|
|
@gaaclarke CreateOffscreenMSAA conditionally handles implicit (extension) vs non-implicit MSAA |
gaaclarke
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 looking good to me. I just have one more suggestion on trying to make this code a bit easier to understand and maintain. It's a bit hard to follow as is.
| if (pass_data.resolve_attachment && | ||
| pass_data.resolve_attachment != pass_data.color_attachment && | ||
| !is_default_fbo) { |
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.
Can we make this branch use the same conditional that is being used in the other code? Something like:
if (!gl.GetCapabilities()->SupportsImplicitResolvingMSAA()) {
FML_DCHECK(pass_data.resolve_attachment);
}
This feature lives across multiple files, it would be nice if there was an easy way to find all the different components that go into making this work. So instead of conditionalizing on the state, conditionalize on how it should behave and assert the state.
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
|
Golden file changes are available for triage from new commit, Click here to view. |
gaaclarke
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, nice work
|
Golden file changes are available for triage from new commit, Click here to view. |
|
reason for revert: goldens occassionally fail to render anything. |
This reverts commit ec065be.
#56741) Reverts: #56705 Initiated by: jonahwilliams Reason for reverting: goldens occassionally fail to render anything. Original PR Author: jonahwilliams Reviewed By: {gaaclarke} This change reverts the following previous change: Adds multisampling support for GLES devices without GL_EXT_multisampled_render_to_texture provided they are at least GLES 3.0 to support mutlisampled render buffers. Fixes flutter/flutter#158360 Fixes flutter/flutter#157951 TBD: should we prefer renderbuffer 3.0 approach over multisample_render_to_texture?
…159308) flutter/engine@d1a0806...6f941c9 2024-11-21 98614782+auto-submit[bot]@users.noreply.github.com Reverts "[Impeller] support GLES 3.0 MSAA without extension. (#56705)" (flutter/engine#56741) 2024-11-21 [email protected] Roll Dart SDK from dde57dc75c15 to b36e4d731d67 (1 revision) (flutter/engine#56723) 2024-11-21 [email protected] [native assets] Consume `NativeAssetsManifest.json` (flutter/engine#56727) 2024-11-21 [email protected] [Impeller] support GLES 3.0 MSAA without extension. (flutter/engine#56705) 2024-11-21 [email protected] Updated some impeller benchmark urls (flutter/engine#56721) 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
…6705) Adds multisampling support for GLES devices without GL_EXT_multisampled_render_to_texture provided they are at least GLES 3.0 to support mutlisampled render buffers. Fixes flutter#158360 Fixes flutter#157951 TBD: should we prefer renderbuffer 3.0 approach over multisample_render_to_texture?
…#56705)" (flutter/engine#56741) Reverts: flutter/engine#56705 Initiated by: jonahwilliams Reason for reverting: goldens occassionally fail to render anything. Original PR Author: jonahwilliams Reviewed By: {gaaclarke} This change reverts the following previous change: Adds multisampling support for GLES devices without GL_EXT_multisampled_render_to_texture provided they are at least GLES 3.0 to support mutlisampled render buffers. Fixes flutter#158360 Fixes flutter#157951 TBD: should we prefer renderbuffer 3.0 approach over multisample_render_to_texture?
Adds multisampling support for GLES devices without GL_EXT_multisampled_render_to_texture provided they are at least GLES 3.0 to support mutlisampled render buffers.
Fixes flutter/flutter#158360
Fixes flutter/flutter#157951
TBD: should we prefer renderbuffer 3.0 approach over multisample_render_to_texture?