-
Notifications
You must be signed in to change notification settings - Fork 6k
[Flutter GPU] Get the GLES backend/Windows working. #55694
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. |
| encodable->EncodeCommands(); | ||
| } | ||
|
|
||
| if (context_->GetBackendType() == impeller::Context::BackendType::kOpenGLES) { |
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 thought the whole point of the GLES backend's task reactor design was that we could call these methods from any thread?
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.
blocking on the raster task runner for like this seems pretty bad, you're essentially de-pipeling .
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 funky that the submit fails if done outside the raster thread. I need to take a closer look at this. If I'm not holding it wrong then fixing the API to defer the submit in the reactor shouldn't be difficult.
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.
Okay, so submitting the command buffer on GLES just flushes the reactor, which makes sense. I changed this to not synchronize with the raster task. So this doesn't block the UI thread anymore.
lib/gpu/render_pass.cc
Outdated
| context.GetPipelineLibrary()->GetPipeline(pipeline_desc).Get(); | ||
| std::shared_ptr<impeller::Pipeline<impeller::PipelineDescriptor>> pipeline; | ||
|
|
||
| if (context.GetBackendType() == impeller::Context::BackendType::kOpenGLES) { |
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.
Similar question here, are we misssing some thread handling in the gles shader library
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 the reactor was WAI here. When attempting to create a pipeline from the UI thread, the pipeline creation task was getting stored in the reactor because GL calls need to be done on the raster thread. The problem is I need the pipeline right away, and so I need to post a raster task.
It's excessive to post a raster task every time we do a pipeline lookup like this. We only need to do it when we know a new pipeline needs to be created, but the API is lacking at the moment.
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.
Do you actually need the pipeline object, or could we store the pipeline future?
Alternatively, consider making this API future returning so we don't end up with weird thread pinning issues.
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 need the pipeline object immediately. This happens during RenderPass.draw. I don't think we should make it async. But we could prevent this raster task in cases where a new pipeline doesn't actually need to be created.
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 changed this to not post a raster task unless we know a new pipeline actually needs to be created.
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.
I'd like @chinmaygarde to take a look since he's more familiar with the threading issues on GLES. Ideally we'd have them fixed such that we don't need to post messages to different threads to use this backend.
…asks for creating pipelines when a pipeline needs to be created
|
|
||
| // Note that this branch is only called if a new pipeline actually needs to | ||
| // be built. | ||
| auto dart_state = flutter::UIDartState::Current(); |
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.
So I think this is a problem in the HAL design. We expect to be able to have a pipeline synchronously for encoding but 1) we can only get the pipeline on a particular thread for GLES and 2) we don't actually need the pipeline until we render - which always happens on the react thread.
I think it would be something to punt to a new PR, but I would consider change the HAL design such that SetPipeline accepted the pipleine future. The Vulkan/Metal implementation would call waitandget while the GLES implementation would defer that until encoding.
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 completely agree with this. Started filing an issue for it but you beat me to it. :)
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
Filled flutter/flutter#156441
…156478) flutter/engine@db0c0b7...4a97943 2024-10-09 [email protected] Roll Fuchsia Linux SDK from TlU-It6X_ZLrNqMjW... to xGr5ZkxX3CajAY1xu... (flutter/engine#55770) 2024-10-09 [email protected] Roll Skia from a077e78e531f to e0bb55353b27 (3 revisions) (flutter/engine#55768) 2024-10-09 [email protected] [Impeller] libImpeller: Allow fetching OpenGL texture handle. (flutter/engine#55753) 2024-10-09 [email protected] Roll Fuchsia Test Scripts from jCde9sMKJ3YAdG2DH... to _fkA2GjLQH4bc_n2p... (flutter/engine#55762) 2024-10-09 [email protected] Roll Skia from 701b6e4b4bc4 to a077e78e531f (3 revisions) (flutter/engine#55761) 2024-10-09 [email protected] Release`onTrimMemoryListener` after `ImageReaderSurfaceProducer` released. (flutter/engine#55760) 2024-10-09 [email protected] [Flutter GPU] Get the GLES backend/Windows working. (flutter/engine#55694) 2024-10-08 [email protected] [canvaskit] Fix incorrect clipping with Opacity scene layer (flutter/engine#55751) 2024-10-08 [email protected] Refactor multi-file build parsing into a single `BuildPlan` class. (flutter/engine#55720) Also rolling transitive DEPS: fuchsia/sdk/core/linux-amd64 from TlU-It6X_ZLr to xGr5ZkxX3Caj 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
…5694) Resolves flutter#156305. * Resolve pipelines and submit command buffers on the raster thread. * Don't use desktop GL shader variation on Windows. * Fix interpretation of `array_elements`. * Fix texture binding metadata. Gets Flutter GPU working on Windows!  
Resolves flutter/flutter#156305.
Resolves flutter/flutter#145012.
array_elements.Gets Flutter GPU working on Windows!

