Remoting layer

[kvark]

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

[grovesNL]

What would the remoting layer need to contain to support this? Does wgpu-native need to be aware whether IPC is being used?

[kvark]

No, the native part doesn't need to know about remoting (I hope!).
We can start it by just sending messages across ipc_channel. One of the first steps would be to send over whole passes instead of individual commands.

[kvark]

(copied from gitter) The way I see it working is:

• wgpu-remote will create client and server parts, linked by an actual IPC channel (or multiple of them - up to implementation details)
• the client side will expose C-API entry points to be called by Gecko bindings (on script/content side). These can actually match the APIs we expose to native, which is kinda weirdly need but not required.
• the server side will listen for IPC and do actual calls into wgpu-native

[kvark]

The infrastructure is there. It's up for discussion and changes, but it's no longer in the theoretical stage.