- From: Corentin Wallez <cwallez@google.com>
- Date: Thu, 9 Nov 2017 16:38:01 -0800
- To: public-gpu <public-gpu@w3.org>
- Cc: Bradley Nelson <bradnelson@google.com>
- Message-ID: <CAGdfWNNX_YJz6rY_G3c1t+2znT6sckwQVqRW8v6ooZVveUfw6w@mail.gmail.com>
Hey all, Here's notes from what I remember of the meeting we had with the WASM CG at TPAC. Feel free to add to it if I missed something important. - Small introduction of WebGPU and the topics we'd like to talk about. Slides <https://docs.google.com/presentation/d/1eRh6I50U02CvNXTuRYnos3kMz98B2Y208LYbImwxgI4/> . - Discussion of low-overhead bindings - Exactly addressed by the Host Bindings proposal <https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md>, that also addresses JS interop. Basically select Web platform objects would be mapped to integer handles in WASM and automatically converted from/to JS objects when calling into/out of WASM. The handles would be in a new WebAssembly table. - In emscriptem headers for WebGPU some function calls will have special attributes that make them call into the Web engine directly without going through JS. - Fast Javascript style "bag of property" initializers would be possible with some additional WASM table magic but there's unresolved questions regarding how it would work for extensions that add new properties to the bag. - Enum / bitfields as arguments should work fine. - Callbacks into WASM are a bit of a slow path. Discussion of additional WASM table magic to make them efficient. The table might need to store a userdata pointer in addition to a function pointer. - Multithreading - In WASM starting a thread works by creating a Web Worker, sending it the SharedArrayBuffer for the main memory and starting the module again on the same SharedArrayBuffer. - It isn't clear yet how it will interact with the "host bindings" proposal. WebGPU objects could be tagged as "shareable" in which case the host binding table would be shareable too, and could be sent along with the SharedArrayBuffer. - Some WebGPU objects like queues will be callable anytime from any thread and will have a mutex internally. - Some objects could be stuck on one thread by having the host binding table not shared. between workers. - Command buffer building will not be possible on multiple threads in parallel but they will often be built and submitted on different threads. Possibilities to make this happen are: - Have the builder thread "send" the command buffer to the submission thread after it is built. - Make the command buffer building commands check they are on the correct thread and trap otherwise. - Have a command buffer builder object that's not shareable and have built command buffers shareable (ok since they are immutable at that point). - Suggestion that command buffer creation could use an in-memory command buffer format so that there is a single "CommandBuffer Build(void*ptr, size_t len)". - Memory mapping in the WASM memory space. - To achieve the minimum number of copies when uploading / downloading to the GPU, WebGPU would love to be able to map memory directly into the WASM heap. For example an application could decompress data directly into a GPU-visible buffer. - For reasons, only file descriptors can be mapped this way, not arbitrary pointers. Also this is not possible on Windows because the OS might reuse the virtual memory without warning. (WebGPU would be a good use-case to push Microsoft to change that) - So the mapping APIs will need to be transparent to whether actual mapping is used, or copies performed by the browser. - We'll also need to make sure to avoid races with the GPU, WebGPU has ideas on how to do that. - Also the browser doesn't know which memory is free in the WASM heap so things would be more like the following in WASM (could be made transparent by emscriptem): - void* ptr = malloc(size); - buffer.WouldYouKindlyMapHere(ptr, size); - Do stuff with ptr - buffer.Unmap(); - free(ptr);
Received on Friday, 10 November 2017 00:38:51 UTC