4 ms·
Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mappi
by flohofwoe 1y ago
Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back.
Multiple WASM memories and Clang's/LLVM's address space feature sound like they should be able to solve that problem, but I'm not sure if it is as trivial as it sounds...
- whizzter 1y agoI'm just getting horrible segmenting and far-pointer vibes of the whole thing, been coding a classic Gameboy game for fun so fiddling with memory mappings is part of the "fun" but for anything non-constrained I'd hate that. We buried far pointers with DOS and Win16 for a good reason..
- flohofwoe 1y agoI'd take segment-pointers over copying megabytes of memory around anyday though ;) It's not much different than dealing with all the alignment rules that are needed when arranging data for the GPU.
- dontlaugh 1y ago"Far" memory is already a central concept in modern GPU APIs. Not all GPUs naturally share memory with the CPU they're running against and handles for resources are a requirement.
- titzer 1y agoThere has been a discussion (https://github.com/WebAssembly/multi-memory/issues/45 https://github.com/WebAssembly/multi-memory/issues/45) on the toolchain support, but I'm not sure if there have been steps to use multiple address spaces to support Wasm multi-memory in LLVM yet.