-
Notifications
You must be signed in to change notification settings - Fork 916
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
Remoting layer #7
Comments
What would the remoting layer need to contain to support this? Does wgpu-native need to be aware whether IPC is being used? |
No, the native part doesn't need to know about remoting (I hope!). |
(copied from gitter) The way I see it working is:
|
The infrastructure is there. It's up for discussion and changes, but it's no longer in the theoretical stage. |
89: Adapter::get_info r=kvark a=paulkernfeld This more or less addresses gfx-rs#7. If the example is too trivial, I'm happy to remove it. Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
Fix release build
Relates gfx-rs#7
In order for this project to be used in Gecko we need to support the fact that WebGPU API bindings are on the content/script process, while the actual graphics context is on the GPU process.
Here comes the remoting layer. It's basically a native C-API library with same (or close) interface that routes the WebGPU calls across an IPC barrier. We may need multiple channels maintained simultaneously (Web worker communicating with the command pool on the GPU side when recording commands), but we can start with a single one (aka Google's "wire").
The text was updated successfully, but these errors were encountered: