Add GPUCommandEncoder.updateBuffer for embedding small buffer updates.

[kdashg]

---

Preview | Diff

[Kangz]

Apart from being closer to Vulkan, I'm not sure what the improvement is compared to writeBuffer:

• writeBuffer is less constrained.
• writeBuffer doesn't require allocating storage for the data for an unknown duration, and everything can be just streamed.
• writeBuffer doesn't make GPUCommandEncoders hold on to data in addition to commands.

[kvark]

That approach is very similar to #154, which we discussed at length at San Diego F2F. The points about returning ArrayBuffer objects obviously don't apply to this one, but concerns about lifetimes that are mentioned here by @Kangz still do.

[Kangz]

The API we have at the moment for WebGPU has a nice property of increasing in complexity as you want to extract the most of it, but works good enough if you do the simple things. writeBuffer is another step in that direction, but inlineUpdateBuffer isn't in my opinion.

inlineUpdateBuffer can cause the application to break in the wild while it worked on the developer's machine because all of a sudden some data became big enough. @jdashg mentioned in the call that this is similar to the max texture size limits, but I think there are two difference: inlineUploadBuffer doesn't have a limit, and texture sizes don't tend to very as much as, say, the size of model data that's put in an inlineUpdateBuffer.

Also inlineUpdateBuffer is the simple option that developers will be looking to use, and the natural thing to do when wanting to upload more data will be to call it multiple times. And doing so will result in surprisingly bad performance. Sure we can have console warnings, but for an important usecase like this one, it's just better to give developers a good enough options that works good enough and doesn't have footguns.

Also inlineUpdateBuffer essentially forces 4 copies:

• JS ArrayBuffer to shmem
• shmem to an temporary allocation that lives next to the GPU process object for a GPUCommandBuffer
• that allocation to staging memory
• staging memory to the final place

Due to its streaming and "instantaneous" nature, writeToBuffer skips the temporary allocation, getting to 3 copies, and can even be streamed into GPU-visible shmem, reducing copies to 2.

[Kangz]

Closing now that #708 is landed

[kdashg]

We may still want this later.