Skip to content
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

Is OffscreenCanvas rendering supported in WebGPU context? #17776

Closed
lisanlow opened this issue Sep 1, 2022 · 8 comments · Fixed by #21467
Closed

Is OffscreenCanvas rendering supported in WebGPU context? #17776

lisanlow opened this issue Sep 1, 2022 · 8 comments · Fixed by #21467
Labels

Comments

@lisanlow
Copy link

lisanlow commented Sep 1, 2022

I see that webgpu OffscreenCanvas rendering is already available in chromium with this bug fix:

Looking at current implementation of wgpuInstanceCreateSurface(), it appears to me that rendering to OffscreenCanvas is currently not available in native webgpu API.
This code section shows that wgpuInstanceCreateSurface() asserts expect webgpu surface to be associated only to HTML canvas element?
https://github.com/emscripten-core/emscripten/blob/main/src/library_webgpu.js#L2410
WebGPUOffscreenNotSupported
Is my understanding correct?
If so, is there any known alternatives to render to canvas on webworker then transfer rendered output to main thread for chrome browser display?

In my prototype code, I am trying to configure OffscreenCanvas in the HTML and referencing this canvas in wgpuInstanceCreateSurface() call to be used for subsequent rendering.
It appears mandatory to define WGPUSurfaceDescriptorFromCanvasHTMLSelector when creating webgpu surface.
https://github.com/emscripten-core/emscripten/blob/main/src/library_webgpu.js#L2399
OffscreenHTML

@sbc100
Copy link
Collaborator

sbc100 commented Sep 1, 2022

@kainino0x

@lisanlow
Copy link
Author

lisanlow commented Sep 12, 2022

@sbc100 and @kainino0x FYI, I managed to overcome this issue in my prototype by setting specialHTMLTargets["!canvas"] = Module.canvas; and referencing it in the HTML selector with "!canvas" in the web worker.

@kainino0x
Copy link
Collaborator

Sorry, I forgot to reply to this. We haven't put any work specifically into getting OffscreenCanvas to work. I never tried it but thought it would work with WGPUSurfaceDescriptorFromCanvasHTMLSelector which calls findCanvasEventTarget which has special logic for OffscreenCanvases:

$findCanvasEventTarget: function(target) {

However it looks like this is only for transferControlToOffscreen and not for raw OffscreenCanvases.

Thanks for reporting your workaround!

@lisanlow
Copy link
Author

lisanlow commented Sep 14, 2022

@kainino0x Thanks for your attention on this issue.

I just realized that the approach that I described above with specialHTMLTargets is mentioned in emscripten documentation.

I assume that its well verified working with WebGL and it's great that this works seamlessly for WebGPU for me :)

@lisanlow
Copy link
Author

lisanlow commented Sep 19, 2022

@kainino0x This ASSERT line is failing for me when working with offscreen canvas in debug build (works well in release build).
https://github.com/emscripten-core/emscripten/blob/main/src/library_webgpu.js#L2412

Any chance that its possible to update this line for the check to allow canvas of offscreen (non-html) type?

@kainino0x
Copy link
Collaborator

@lisanlow Of course! Thanks for finding that bug. #17889

@lisanlow
Copy link
Author

@lisanlow Of course! Thanks for finding that bug. #17889

@kainino0x Thanks for the prompt fix! Really appreciate it.

@alienself
Copy link

alienself commented Apr 21, 2023

I am facing a similar issue: #19225

I would like to run webgpu off the main thread in a separate thread while rendering on an offscreen canvas passed from the main thread.

@kainino0x Is this possible with emscripten? I am using proxy to pthread but i am unable to retrieve the canvas context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants