FYI, WebGL does this with (ArrayBufferView, srcOffset, length). This is also fine, it just makes it unclear whether srcOffset and length are in units of bytes or multiples of BYTES_PER_ELEMENT.

I remembered BufferSource was a thing, and updated accordingly.

Thinking about it more it doesn't really make sense to pass ArrayBuffers into these entry points, since ArrayBuffers don't semantically expose access to their contents (a view is required). Updated.

BufferSource would be easier for the WebAssembly case, since the WebAssembly.Memory object contains a plain ArrayBuffer with no views. Wrapping the wasm memory in an ArrayBufferView is annoying because the view needs to be cached to avoid garbage, but the view becomes detached when wasm memory grows, so there needs to be a check if the cache is still valid every time it's used.

ArrayBufferViews are not great for packed buffers, where you will be using DataView to fill in the contents.

In practice, IIRC, Emscripten always keeps around one of each type of view into it's entire heap, and does reset them when the heap grows. It uses these views every time it needs to access the heap from JS, because it's the only way.

Good point about DataView (which is especially useful for uniform buffers). I thought of it before but forgot when I made this change. Still, semantically I think it makes more sense to make a view into the buffer behind the DataView, for the reasons above. Or allow DataView to be passed in here.

OTOH if we get rid of setSubData then it's moot; DataView isn't particularly useful for SPIR-V code.

To me, I see the ArrayBuffer as an opaque blob of data (void*), and the view as a pointer into that data (float*, uint32_t*). This analogy is stretched a bit since views can view partial ArrayBuffer contents through the offset/length parameters, yet there's no way to slice an ArrayBuffer without copying (a very unfortunate omission, in my opinion). Vertex buffers are a case where you might have 3 F32 fields for position, six SNORM16 fields for normal/tangent/bitangent pairs, two UN16 fields for texture coordinate, four U8 fields for color, etc. Similarly with texture data, or bytecode, etc. There's no consistent view into that data from an ArrayBufferView. Will SPIR-V module creation demand a Uint32Array, since everything is packed in 32-bit words? And before you laugh, WebGL requires this for texture uploads today -- you have to pass a Int16Array for a 16-bit signed integer texture, a Float32Array for floating-point textures, etc.

You can always access the underlying ArrayBuffer from a view for free, but creating the view to wrap a view is garbage. So I would much prefer ArrayBuffer.

Allowing only ArrayBuffer would be kind of unwieldy; if you do have an ArrayBufferView, it requires unpacking it into (ArrayBuffer, offset, size) manually in JS.

Also, if createShaderModule only takes ArrayBuffer and not ArrayBufferView, we have to add the offset and size arguments to GPUShaderModuleDescriptor, and, again, users have to unpack them manually. As I said above, since the cost of createShaderModule is already so high, I think I'd prefer to stick with the web platform's existing primitives and take only ArrayBufferView. I actually would be fine with requiring this to be Uint32Array, as it is semantically correct.

And if setSubData is gone (it kind of seems like it's going that way), this is the only entry point left for now.

Sounds good then; thanks. Didn't realize that setSubData was heavily on the chopping block.

Thanks for all your input. I'll be sure to re-raise this if we don't remove it.

@kainino0x can you rebase this? Also shouldn't the variant for SPIR-V be Uint32Array?

Rebased.
I think you're right, we should use Uint32Array here - it semantically makes sense, as I said above.

But that said, I recall WebGL was adding entry points for (ArrayBuffer, offset) to make things work better when resizing WASM heaps. Should we take that approach? (cc @kenrussell)

Chatted with Ken about this and we decided it's best to keep things simple for now and use Uint32Array+offset. In the future we might want to change it to BufferSource+offset, which would be a generalization.

Er, per my previous comments, the cost of createShaderModule is so high compared with the cost of garbage collecting one Uint32Array wrapper, that it's nicer to just pass Uint32Array here instead of Uint32Array+offset+length.

Ready for review/landing. Note this PR now only affects ShaderModuleDescriptor (as setSubData is gone), and only the SPIR-V version of it.