Devices

GPUDevice is a "reference" to an internal concept, "device".
The device is internally synchronized.

GPUDevice is "serializable" (with forStorage = false), so it can be sent via postMessage. It is not transferable.
When it's serialized, a pointer to its "device" is sent.
When it's deserialized, a GPUDevice(Ref?) with the same "device" is created.

Error stack state is per (device, realm) pair.

Encoders

GPUCommandEncoder
GPUComputePassEncoder
GPURenderPassEncoder

These are neither transferable nor serializable.

Other objects

Mutable resources:

GPUBuffer
GPUTexture
GPUFence

Containers (objects referencing mutable resources):

GPUTextureView
GPUBindGroup
GPUCommandBuffer
GPURenderBundle

Immutable (immutable resources or immutable objects not referencing mutable resources):

GPUSampler
GPUShaderModule
GPUComputePipeline
GPURenderPipeline
GPUPipelineLayout
GPUBindGroupLayout

(Please mention if I've misclassified any of these.)

Alternative 1

All of these objects are transferable, but not serializable.

Problem: Say you have a GPUBuffer B, and two GPUBindGroup BG1 and BG2
that contain B. How do you transfer them?
Transferring BG1 would have to also detach B.

Options when BG1 is transfered but BG2 is not:

Implicitly detach B. Loses the reference to B, so it can't be destroyed.
Make B internally held by BG1 so that B must be in the transfer list too.
Make B visibly referenced by BG1 so that B must be in the transfer list too.

All of these options implicitly destroy BG2.

Things get quite complex once you need to transfer a GPUCommandBuffer, all of the GPUBindGroups it uses, and all of the GPUBuffers and GPUTextures they use.

Alternative 2

All of these objects are serializable, but not transferable.

Problem: Now all objects can be accessed from multiple threads in parallel (including map, destroy, etc.) It becomes necessary to implicitly synchronize between threads in order to be able to use them safely. Race conditions become more likely.

Alternative 3

Mutable resources are transferable.
Containers are neither transferable nor serializable.
Immutable objects are serializable.

Problem: This allows for threaded resource initialization, and potentially for threaded submission of command buffers to queues, but it doesn't allow creating command buffers on threads and then transferring them to another thread for submit.

Conclusion

The best idea I've come up with so far is Alternative 2.

Create a proposal for multi-worker #354

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions