tree 41c9f7c31fa7a2285de6b7c71d41669f436779e1
parent 53a0aae32a0ad1c67e8de6f98500504878473465
author Austin Eng <enga@chromium.org> 1708635202 +0000
committer Dawn LUCI CQ <dawn-scoped@luci-project-accounts.iam.gserviceaccount.com> 1708635202 +0000

remove global device lock for host-mapped-pointer buffers

This makes creation of these buffers thread-safe without
taking the global device lock. Note that destroying the
device while creating any resource is still not safe.

Tested on Linux with TSAN, that the implementation is
data-race free.

On d3d12, buffer creation:
 - uses the D3D12 device, which is thread-safe
 - uses the ResidencyManager which is MutexProtected
 - reads lots of device info/toggles; which are immutable
   after creation

On d3d12, buffer destruction
 - uses the deallocation queue which is MutexProtected
 - uses the callback task queue which is MutexProtected

On metal, buffer creation
 - uses the MTLDevice which is already thread-safe

On metal, buffer description
 - uses the callback task queue which is MutexProtected

On Vulkan, buffer creation
 - allocates with the VkDevice, which is thread-safe
 - reads lots of device state which is immutable after
   creation
 - uses the resource memory allocator which is MutexProtected

On vulkan, buffer destruction
 - uses the resource memory allocator which is MutexProtected
 - uses the fenced deleter which is MutexProtected
 - uses the callback task queue which is MutexProtected

Bug: dawn:1662
Change-Id: Ib0962a5f8afcc4b80a8f3d759d8ad80bf28c8094
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/175208
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>