Thanks to visit codestin.com
Credit goes to github.com

Skip to content

feat: GPU shared texture offscreen rendering #42953

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

Merged
merged 17 commits into from
Aug 23, 2024
Merged

feat: GPU shared texture offscreen rendering #42953

merged 17 commits into from
Aug 23, 2024

Conversation

reitowo
Copy link
Contributor

@reitowo reitowo commented Jul 18, 2024

Description of Change

Reopen #42001

I managed to add ARGB + kGpuMemoryBuffer support for FrameSinkVideoCapturer in recent upstream changes. Thus, we can finally use zero-copy (actually one, there's a CopyRequest of frame texture) GPU shared texture OSR in chromium apps.

This will be the fastest OSR mode than the existing two, and it supports enabling hardware acceleration.

However, this mode will not compose the popup widgets, directly provide both window types' textures to user. It is expected that user themselves to compose these textures at their rendering pipeline.

Details:

  1. Add webPreferences.offscreen.useSharedTexture to enable this feature.
  2. Add texture to paint event of webContent.
  3. Add structure definitions and docs.
  4. Add tests about this feature.

Fix: #41972

Checklist

Release Notes

Notes: feat: GPU accelerated shared texture offscreen rendering.

@reitowo reitowo requested a review from a team as a code owner July 18, 2024 03:57
@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Jul 18, 2024
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Hello @reitowo! It looks like this pull request touches one of our dependency files, and per our contribution policy we do not accept these types of changes in PRs.

@samuelmaddock samuelmaddock added the semver/minor backwards-compatible functionality label Jul 18, 2024
@reitowo
Copy link
Contributor Author

reitowo commented Jul 18, 2024

Well, it seems the CI machine failed to create a D3D11 device.

image

Trying to make this optional.

@ckerr ckerr self-requested a review July 19, 2024 19:47
@ckerr ckerr dismissed github-actions[bot]’s stale review July 19, 2024 19:48

The change requested was to not have unknown contributors modifying yarn.lock, but the change here is just to add an internal vendorized dependency for specs. It's harmless.

@ckerr ckerr requested a review from a team July 19, 2024 19:50
+ // once the GMB is returned from CopyRequest. So there will be no race
+ // condition on that texture. We can request a GMB without a keyed mutex to
+ // accelerate and probably prevent some driver deadlock.
+ if (format_ == PIXEL_FORMAT_ARGB || format_ == PIXEL_FORMAT_ABGR) {
Copy link
Member

Choose a reason for hiding this comment

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

Electron's desktopCapturer uses this format. Would it be affected?

video_capturer_->SetFormat(media::PIXEL_FORMAT_ARGB);

Copy link
Contributor Author

@reitowo reitowo Jul 22, 2024

Choose a reason for hiding this comment

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

As long as that code use BufferFormatPreference::kDefault which will only requests a CPU only buffer, it won't be affected by this, this patch made changes to renderable_gpu_memory_buffer_video_frame_pool which is a GPU related buffer code.

Even it use GPU texture later (BufferFormatPreference::kPreferGpuMemoryBuffer), it will not be affected if you won't write to the texture again. The patch just remove the keyed mutex on that texture.

PS: Does it mean desktopCapturer also possible to use GPU for acceleration? Just randomly thinking...

@erickzhao erickzhao self-assigned this Jul 22, 2024
@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Jul 25, 2024
@reitowo
Copy link
Contributor Author

reitowo commented Jul 25, 2024

Rebased conflict.

Copy link
Member

@erickzhao erickzhao left a comment

Choose a reason for hiding this comment

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

Thanks for this PR! Some API comments. :)

@itsananderson
Copy link
Member

If someone enables this feature, but neglects to call texture.release(), it sounds like that could cause a memory leak. Would it be possible to monitor for when the JS texture object is getting GC'd and either release the shared texture automatically (if that is safe to do), or print a warning so that the developer can detect that they're leaking memory?

There is an EmitWarning function that you could use to log this warning. You'd also only want to log it once per process lifetime, to avoid spamming for every paint event.

@reitowo
Copy link
Contributor Author

reitowo commented Aug 2, 2024

Definetely ok, but not necessary. People use OSR features are expected to receive continuous frames. And since it will be drained only after 10-11 frames, the user will no longer receive any updates, so they must notice this as a bug.

Relying on GC is not working because the unknown timing. 10 frames are only 160ms at 60fps and GC are not running that fast.

However I think it is best to add that hint when it got GC-ed but not manually released for better understanding whats going on. 👍🏻 (If theres really a way to monitor that)

@reitowo
Copy link
Contributor Author

reitowo commented Aug 5, 2024

Implemented it, fun feature. @itsananderson

Note the warning won't show until next GC, so its kinda slow under testing enviroment. You can manually trigger GC to see this.

image

@samuelmaddock
Copy link
Member

@reitowo looks like the patch needs to be updated as it's failing to apply.

@reitowo
Copy link
Contributor Author

reitowo commented Aug 5, 2024

I noticed that and I already updated the patch.

Terrifying that they are working on opt-out GpuMemoryBuffer......

PS: For future maintaince of this patch please @ me at any time.

@reitowo reitowo force-pushed the main branch 2 times, most recently from c72e37c to 6bd174d Compare August 5, 2024 18:50
@reitowo
Copy link
Contributor Author

reitowo commented Aug 5, 2024

Fixed the patch and verified to work! Hope we can merge this in next days 😎

@release-clerk
Copy link

release-clerk bot commented Aug 23, 2024

Release Notes Persisted

feat: GPU accelerated shared texture offscreen rendering.

@reitowo
Copy link
Contributor Author

reitowo commented Aug 23, 2024

Great!

Thanks for all your work reviewing this PR and maintaining electron. I'm glad to be able to make this contribution! ❤️

@reitowo
Copy link
Contributor Author

reitowo commented Sep 11, 2024

Just to ask, is it possible to backport this feature to previous Electron versions? (32)

@erickzhao
Copy link
Member

Hi @reitowo,

If you would like to backport the PR to previous branches, a releaser can assist by running Trop automation. Backporting a feature PR will automatically put it up for a vote by the Releases working group, whereafter the PR can be accepted or denied on a case-by-case basis.

See https://www.electronjs.org/docs/latest/tutorial/electron-versioning#backport-request-process for more info.

As an aside (I'm not in the WG), I think the general policy for stable release lines is that PRs with large patches or changes to existing code paths are considered riskier and have a lower chance of being accepted.

@VerteDinde
Copy link
Member

Thanks @erickzhao! @reitowo, I'll go ahead and run backports for you to 33-x-y and 32-x-y. To Erick's point, I think we're probably unlikely to backport a change this large into an already existing stable release line, but we can vote and determine whether or not it's a good fit 🙂

@VerteDinde
Copy link
Member

/trop run backport-to 33-x-y

@trop
Copy link
Contributor

trop bot commented Sep 11, 2024

The backport process for this PR has been manually initiated - sending your PR to 33-x-y!

@trop
Copy link
Contributor

trop bot commented Sep 11, 2024

I have automatically backported this PR to "33-x-y", please check out #43694

@VerteDinde
Copy link
Member

/trop run backport-to 32-x-y

@trop
Copy link
Contributor

trop bot commented Sep 11, 2024

The backport process for this PR has been manually initiated - sending your PR to 32-x-y!

@trop
Copy link
Contributor

trop bot commented Sep 11, 2024

I was unable to backport this PR to "32-x-y" cleanly;
you will need to perform this backport manually.

@reitowo
Copy link
Contributor Author

reitowo commented Sep 12, 2024

Thanks! I got your point about bp into 32, thats reasonable, and it will still be nice if we can bp into 33. 😉

I'll still try manual bp into 32 and wait for your vote.

@trop
Copy link
Contributor

trop bot commented Nov 1, 2024

@reitowo has manually backported this PR to "33-x-y", please check out #44509

@trop
Copy link
Contributor

trop bot commented Nov 1, 2024

@reitowo has manually backported this PR to "32-x-y", please check out #44510

@trop
Copy link
Contributor

trop bot commented Nov 1, 2024

@reitowo has manually backported this PR to "33-x-y", please check out #44511

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-review/approved ✅ merged/33-x-y PR was merged to the "33-x-y" branch. semver/minor backwards-compatible functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request]: Hardware accelerated off-screen rendering
7 participants