Thanks for putting this together, the proposal looks good. Have we also investigated the tradeoffs for an unbuffered alternative?

We didn't consider it. I don't think it makes much of a difference - either way, the operation occurs atomically at the unbuffered operation (be it texture.copyFromImageBitmap or queue.submit), and would have the same semantics (I think).

It would be nice to try to expand this to actual 3d sliced uploads later, but let's get this in first.

Done and rebased.

I think this is ready to be landed, the group agreed to this PR a while ago.

From the 2019-04-15 minutes tl;dr:

ImageBitmap #266

• Concern that the ImageBitmap needs to be remembered between encode and submission. Discussion around read-only and weak handles.
• ImageBitmap has to be not detached.
• People like the proposal (but no consensus recorded)

The alternative is for this copy to be outside of a command buffer (queue/device timeline). I think this is somewhat hard to spec without multiqueue spec.

There was some contingent, IIRC, who wanted to have versions of some copies outside of buffers. We should/will revisit moving this out if we do that.