mirror of
https://github.com/encounter/dawn-cmake.git
synced 2025-07-29 08:25:39 +00:00
8cc6205bf7
Normal behavior of ApiObjectBase's APIRelease() which only locks the
device when last ref dropped is not thread safe if the object is cached
as raw pointers by the device. Example of cached objects: bind group
layout, pipeline, sampler, shader module.
The following scenario could happen:
- thread A:
- shaderModuleA.APIRealease()
- shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
- going to call shaderModuleA.LockAndDeleteThis().
- thread B:
- device.CreateShaderModule().
- lock()
- device.GetOrCreateShaderModule()
- shaderModuleA is in the cache, so return it.
- unlock()
- thread A:
- starting to call shaderModuleA.LockAndDeleteThis()
- lock()
- erase shaderModuleA from the cache.
- delete shaderModuleA.
- unlock()
This CL disables caching when ImplicitDeviceSynchronization is turned on
until we find a better solution.
Bug: dawn:1769
Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
32 lines
1.7 KiB
Markdown
32 lines
1.7 KiB
Markdown
# Implicit Device Synchronization
|
|
|
|
`implicit-device-sync` is an experimental feature that offers multithreading support for `dawn_native`.
|
|
|
|
Additional functionality:
|
|
- `wgpu::Device` and most of its child objects are safe to be used on multiple threads, including:
|
|
- `wgpu::Queue`.
|
|
- `wgpu::BindGroup`.
|
|
- `wgpu::BindGroupLayout`.
|
|
- `wgpu::Buffer`. See Notes.
|
|
- `wgpu::Texture`.
|
|
- `wgpu::TextureView`.
|
|
- `wgpu::ComputePipeline`.
|
|
- `wgpu::RenderPipeline`.
|
|
- `wgpu::PipelineLayout`.
|
|
- `wgpu::Sampler`.
|
|
- `wgpu::ShaderModule`.
|
|
- `wgpu::SwapChain`.
|
|
- These objects are *not* safe to be used concurrently:
|
|
- `wgpu:CommandEncoder`.
|
|
- `wgpu:ComputePassEncoder`.
|
|
- `wgpu:RenderPassEncoder`.
|
|
- `wgpu:RenderBundleEncoder`.
|
|
- Except that the creation, referencing, releasing and destruction of these objects are guaranteed to be thread safe.
|
|
|
|
|
|
Notes:
|
|
- This feature is experimental, meaning currently it has some limitations:
|
|
- For `wgpu::Buffer` to be safe on multiple threads. Proper manual synchronization must be done by users to ensure that the buffer is not currently being mapped and being used by any render/compute pass encoder at the same time on different threads.
|
|
- Enabling this feature will disable the compatibility between `wgpu::BindGroupLayout`. That means the two different `wgpu::BindGroupLayout` objects created with equivalent `wgpu::BindGroupLayoutDescriptor` won't be considered "group-equivalent" anymore. You can only use a `wgpu::BindGroup` with a `wgpu::RenderPipeline`/`wgpu::ComputePipeline` if they are both created with the same `wgpu::BindGroupLayout`.
|
|
- Consider using `wgpu::RenderPipeline::GetBindGroupLayout()`/`wgpu::ComputePipeline::GetBindGroupLayout()` when creating a `wgpu::BindGroup`.
|