Memory models of WebAssembly and Vulkan are not similar. WebAssembly uses "linear memory", a continuous range of memory, while Vulkan driver allocates "mapped" chunks of memory accessable by both CPU and GPU that are usually outside of WebAssembly's memory.
Webrogue uses VK_EXT_external_memory_host extension to make driver use parts of WebAssembly's linear memory, but a) this extension may be missing, and b) even if it is present, it may be unsupported by some Vulkan memory types.
So Webrogue has a "shadow memory" feature. It's simply an memory region without read or write permissions inside of linear memory. When guest tries to read from or write to this region, a segfault occurs, but it is caught by signal handler. This signal handler grants read and write permissions to this memory and copies data from actual memory allocated by Vulkan outside of linear memory, and then returns. When guest invokes any Vulkan routine (not any in fact, as it happens only when gfxstream commit happens), Webrogue copies data from shadow memory back to actual Vulkan memory and revokes read and write permissions.
This fallback solution work, but there are a few things that need investigation:
- Is it correct from Vulkan's point of view? What if Vulkan driver modifies some data in host-visible memory while shadow memory is readable and writable?
- What happens when multiple threads try to write to non-writable shadow memory? Yeah, one thread would cause segfault and trigger signal handler as excepted, but what about other threads? There is a short period of time when signal handler made memory readable & writable, but not copied data to it yet. Maybe other threads should be paused by epoch interruption for that time?
- These copies back and forth do decrease performance, but how significantly?
- What else can be done to avoid using shadow memory? Maybe obtain dmabuf fd and map it once again if possible? Does it worth it?
Memory models of WebAssembly and Vulkan are not similar. WebAssembly uses "linear memory", a continuous range of memory, while Vulkan driver allocates "mapped" chunks of memory accessable by both CPU and GPU that are usually outside of WebAssembly's memory.
Webrogue uses VK_EXT_external_memory_host extension to make driver use parts of WebAssembly's linear memory, but a) this extension may be missing, and b) even if it is present, it may be unsupported by some Vulkan memory types.
So Webrogue has a "shadow memory" feature. It's simply an memory region without read or write permissions inside of linear memory. When guest tries to read from or write to this region, a segfault occurs, but it is caught by signal handler. This signal handler grants read and write permissions to this memory and copies data from actual memory allocated by Vulkan outside of linear memory, and then returns. When guest invokes any Vulkan routine (not any in fact, as it happens only when gfxstream commit happens), Webrogue copies data from shadow memory back to actual Vulkan memory and revokes read and write permissions.
This fallback solution work, but there are a few things that need investigation: