WebGPU writeBuffer/writeTexture don't accept SharedArrayBuffer ([AllowShared])
Categories
(Core :: Graphics: WebGPU, defect)
Tracking
()
People
(Reporter: kainino, Unassigned, NeedInfo)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
859 bytes,
text/html
|
Details |
Steps to reproduce:
https://github.com/emscripten-core/emscripten/issues/23149
Call writeBuffer or writeTexture with a Uint8Array backed by a SharedArrayBuffer (shared Wasm heap).
A simple test case is attached (run it with npx servez --shared-array-buffers
or other server that sets COOP/COEP) but I will try to write a conformance test so we actually test this (see https://github.com/gpuweb/cts/issues/3241).
Actual results:
TypeError: GPUQueue.writeBuffer: ArrayBufferView branch of (ArrayBufferView or ArrayBuffer) can't be a SharedArrayBuffer or an ArrayBufferView backed by a SharedArrayBuffer
<anonymous> http://localhost:8081/:15
localhost:8081:17:11
TypeError: GPUQueue.writeTexture: ArrayBufferView branch of (ArrayBufferView or ArrayBuffer) can't be a SharedArrayBuffer or an ArrayBufferView backed by a SharedArrayBuffer
<anonymous> http://localhost:8081/:26
Reporter | ||
Updated•2 months ago
|
Reporter | ||
Comment 1•2 months ago
|
||
WebGPU bindings for Wasm (Emscripten and presumably any other bindings) run into this when running multithreaded, which uses SharedArrayBuffer for the Wasm heap.
It is possible for the bindings to work around by making a copy of the data in a non-shared ArrayBuffer before uploading, but this is costly, so it would be best if we don't add that workaround (since any code compiled with that version of the bindings will keep the workaround forever until it gets recompiled).
Reporter | ||
Comment 2•2 months ago
|
||
I'll note there are some other problems with writeBuffer already that are causing the conformance tests to fail: https://bugzilla.mozilla.org/show_bug.cgi?id=1835636
Comment 3•2 months ago
|
||
:jimb, can you comment to this bug?
Updated•1 month ago
|
Description
•