Stream: git-wasmtime

Topic: wasmtime / issue #7193 Importing host memory as `Memory` ...

Wasmtime GitHub notifications bot (Oct 09 2023 at 01:17):

i509VCB opened issue #7193:

Feature

Allow wasmtime to create memory from a host pointer.

Benefit

Mainly to avoid copies where the store cannot own the memory.

In my use case I'd like to avoid an additional copy when writing into a wgpu buffer that is exposed inside of wasm.

In this case I can't assume any old host allocated buffer will work because the driver may need to allocate host memory in a specific way to allow the memory to be uploaded to the GPU. For OpenGL I have no control over how the GPU upload buffer memory is allocated and as such would always need a copy. For Vulkan there is an exception, but can't blindly assume it's possible to get memory from wasm and use it right in vulkan for buffer upload.[^vk_exception]

As a result of these limitations I would need to do a copy anyways.

Implementation

The proposed API could look something like this (in Rust)

impl Memory {
    pub unsafe fn import_memory(store: impl AsContextMut, ty: MemoryType, pointer: *mut u8) -> Result<Memory> { ... }
}

This would be an unsafe API since the wasm runtime would need exclusive access of the memory (which can't really be guaranteed on every platform). Also the caller must ensure the pointer is valid as long as wasm is able to access that memory.

Because the memory was allocated by the host, wasmtime can't resize the memory itself. This means that Memory::grow would need to unconditionally fail. What I'm not sure about is freeing a Memory instance from the host. This would probably also be unsafe.

There is also the question of whether wasmtime can architecturally handle this type of API without some internal reworks.

Alternatives

I can't think up any other alternatives to this problem except for additional copies. The fact that the graphics API must allocate memory

[^vk_exception]: For Vulkan it is possible to use VK_EXT_external_memory_host. This however comes with some restrictions: alignment being the main one (which is probably fine given wasm needs 64k blocks of memory). However not every hardware vendor can implement that extension. Intel, Broadcom and Qualcomm seem to be incapable of supporting it while some older AMD and Nvidia hardware can't implement it.

Wasmtime GitHub notifications bot (Oct 09 2023 at 03:16):

alexcrichton commented on issue #7193:

Would the MemoryCreator API suit your needs?

Wasmtime GitHub notifications bot (Oct 09 2023 at 03:24):

i509VCB commented on issue #7193:

Would the MemoryCreator API suit your needs?

Hmm I guess I haven't heard of that API.

I think I might be able to get away with it, sure a little overallocation here and there to handle the reserved and guard sizes.

Although the issue of being able to revoke memory from the runtime still is an issue but it's less involved with the initial topic of this issue

Wasmtime GitHub notifications bot (Oct 09 2023 at 13:45):

alexcrichton commented on issue #7193:

I'd recommend trying to use that if you can, but in general implementing your own linear memory is quite tricky and it'll likely be much eaiser to implement a copy. There's a number of requirements about the behavior of a wasm linear memory which make it not necessarily easy to do something like this.

Last updated: Nov 22 2024 at 17:03 UTC