Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@bdero
Copy link
Member

@bdero bdero commented Oct 7, 2024

Resolves flutter/flutter#156305.
Resolves flutter/flutter#145012.

  • 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!
image
image

@flutter-dashboard
Copy link

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) {
Copy link
Contributor

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?

Copy link
Contributor

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 .

Copy link
Member Author

@bdero bdero Oct 7, 2024

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.

Copy link
Member Author

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.

context.GetPipelineLibrary()->GetPipeline(pipeline_desc).Get();
std::shared_ptr<impeller::Pipeline<impeller::PipelineDescriptor>> pipeline;

if (context.GetBackendType() == impeller::Context::BackendType::kOpenGLES) {
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Contributor

@jonahwilliams jonahwilliams left a 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();
Copy link
Contributor

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.

Copy link
Member Author

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. :)

Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bdero bdero added the autosubmit Merge PR when tree becomes green via auto submit App label Oct 9, 2024
@auto-submit auto-submit bot merged commit db49445 into flutter:main Oct 9, 2024
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Oct 9, 2024
zanderso pushed a commit to flutter/flutter that referenced this pull request Oct 9, 2024
…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
nick9822 pushed a commit to nick9822/flutter that referenced this pull request Dec 18, 2024
…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!
![image](https://github.com/user-attachments/assets/9eecb67f-a980-4556-8060-b0c947713534)
![image](https://github.com/user-attachments/assets/c8e2071f-e7c0-411c-8f37-e1f3037916f4)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

autosubmit Merge PR when tree becomes green via auto submit App e: impeller flutter-gpu

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

[Flutter GPU] Windows: UI thread hangs indefinitely on RenderPass::Draw. [Flutter GPU] OpenGLES support.

2 participants