Previously we would always assume that if the driver supported a Vulkan
version it would also support extensions that were promoted in that
version. This is not a spec requirement, so instead try to load the core
entrypoints, and only if the version is not available, load the
extension entrypoints.
Also renames VulkanFunction members that are from promoted extension to
not have a vendor prefix.
Also tag the promoted extensions that are the same in a core version as
available when that core version is available. This simplifies checking
for features in the Vulkan backend.
Bug:
Change-Id: I0817c01b8838ba26070858abb0cbed030e3291df
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/16040
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: David Turner <digit@google.com>
Also fixes some warnings when compiling with GCC
Bug: dawn:333
Change-Id: Ib597bb3b950476279a1e20e3556765ec9f1db697
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15960
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Falling-back to direct allocation ensures allocation failure returns OOM.
If no OOM, the resource could be left then used while in an invalid state.
BUG=chromium:1045811,chromium:1047220,chromium:1047048
Change-Id: I927962b1dc6a7422a7d6eac114d82f28a42794a2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15600
Commit-Queue: Bryan Bernhart <bryan.bernhart@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
signatures of Vulkan functions, changing their ABI and making us
incompatible with real drivers. This removes that magic, and replaces it
with an explicit wrapper, VkHandle, which has much of the same
functionality as the original VkNonDispatchableHandle.
It adds definitions for dawn_native::vulkan::VkBuffer et al, which
shadow the native ::VkBuffer et al. This retains type safety throughout
the Vulkan backend without changing every single usage.
Notably, the following things had to change:
- An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
arrays. This is implemented as a reinterpret_cast, which is still
safe as the new VkHandle still has the same memory layout properties
as VkNonDispatchableHandle did.
- When pointing to a VkHandle as an output pointer, it's now necessary
to explicitly get the native ::VkBuffer (via operator*) and point to
it.
Previously reviewed on:
https://dawn-review.googlesource.com/c/dawn/+/15580
Bug: chromium:1046362
Change-Id: I7d34ec38a805025f92165ea9a7ee07ae5c182076
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15641
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
This reverts commit 4e17d5c2483b63d4863162d692a1a961d1dcb958.
Reason for revert: broken on chromeos
Original change's description:
> Remove VK_DEFINE_NON_DISPATCHABLE_HANDLE magic, use explicit VkHandle wrapper
>
> Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
> signatures of Vulkan functions, changing their ABI and making us
> incompatible with real drivers. This removes that magic, and replaces it
> with an explicit wrapper, VkHandle, which has much of the same
> functionality as the original VkNonDispatchableHandle.
>
> It adds definitions for dawn_native::vulkan::VkBuffer et al, which
> shadow the native ::VkBuffer et al. This retains type safety throughout
> the Vulkan backend without changing every single usage.
>
> Notably, the following things had to change:
> - An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
> arrays. This is implemented as a reinterpret_cast, which is still
> safe as the new VkHandle still has the same memory layout properties
> as VkNonDispatchableHandle did.
> - When pointing to a VkHandle as an output pointer, it's now necessary
> to explicitly get the native ::VkBuffer (via operator*) and point to it.
>
> Bug: chromium:1046362
> Change-Id: I9c5691b6e295aca1b46d4e3d0203956e4d570285
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15580
> Reviewed-by: Austin Eng <enga@chromium.org>
> Reviewed-by: Kai Ninomiya <kainino@chromium.org>
> Commit-Queue: Kai Ninomiya <kainino@chromium.org>
TBR=cwallez@chromium.org,kainino@chromium.org,enga@chromium.org
Change-Id: I500df2e34fd0f245ad04c517ff028ddd7bb5a2bf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1046362
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15620
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
signatures of Vulkan functions, changing their ABI and making us
incompatible with real drivers. This removes that magic, and replaces it
with an explicit wrapper, VkHandle, which has much of the same
functionality as the original VkNonDispatchableHandle.
It adds definitions for dawn_native::vulkan::VkBuffer et al, which
shadow the native ::VkBuffer et al. This retains type safety throughout
the Vulkan backend without changing every single usage.
Notably, the following things had to change:
- An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
arrays. This is implemented as a reinterpret_cast, which is still
safe as the new VkHandle still has the same memory layout properties
as VkNonDispatchableHandle did.
- When pointing to a VkHandle as an output pointer, it's now necessary
to explicitly get the native ::VkBuffer (via operator*) and point to it.
Bug: chromium:1046362
Change-Id: I9c5691b6e295aca1b46d4e3d0203956e4d570285
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15580
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
BUG=dawn:325
Change-Id: I66bed7fec65cadecc956878bf11fc204b66ad195
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15500
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
The state-tracking of the webgpu.h swapchain is a bit complicated
because contrary to implementation-based swapchains, they have more
guarantees and a "replacing mechanism". For example instead of hoping
the implementation-based swapchain resize automatically, the
surface-based swapchain needs to be replaced by a new swapchain and
invalidated.
This mechanism of invalidation also needs to be triggered when the last
reference to the surface is lost because we don't want to risk the
application destroying the window from under us.
Adds tests for all the cases of invalidation I could think of apart from
device loss.
Bug: dawn:269
Change-Id: Id515dbb640e13c6e30bb1f1e93b8e54f1e2bba4b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15400
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
If Device creation fails, several things are just partially initialized
and the destroy sequence crashes dereferencing null data.
This commit marks the Vulkan device as lost until after it is created.
This avoids parts of the destroy sequence which are unecessary since
the Device was never successfully created and no commands are in flight.
Bug: chromium:1043095
Change-Id: I8e121709fa19b215e118a615b639380d1db1f3f2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15460
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
There was a typo in macro name used to do platform detection.
Bug:
Change-Id: I81958419b4283d1d0498f5edc48efc385a648e09
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15440
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This commit changes wgpu::Device::CreateSwapChain to take an additional
wgpu::Surface argument. Passing nullptr is enough to stay on the
previous swapchain implementation, until the new one is ready.
In order to support both the "old" implementation-based swapchains and
the "new" surface-based swapchains. SwapChainBase is now split into
three abstract classes:
- SwapChainBase that has a virtual method for each of the
wgpu::SwapChain methods.
- OldSwapChainBase that corresponds to the implementation-based
swapchains.
- NewSwapChainBase that will contain the surface-based swapchain
implementation and will eventually just be renamed to SwapChainBase.
The interaction of the surface-based swapchains with the Surface objects
aren't implemented yet, neither are the swapchain methods. Only creation
works.
Validation tests for surface-based swapchain creation are added in the
end2end test target because they need to create OS windows.
Bug: dawn:269
Change-Id: I7e07d6c666479867b9a16d7b1b8c181d5dbd69a0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15281
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This includes moving the destruction of vkDevice from Destroy to the
Device Destructor since we need vkDevice to destroy child objects.
Bug: dawn:68
Change-Id: Id477206b2e3f80138b3708eedcee073303f1b696
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15220
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Natasha Lee <natlee@microsoft.com>
This may be a short term solution before linking our own version
of the Vulkan Loader.
Bug: dawn:283
Change-Id: Ifeddeaa5170bccc912c61059071a83c2b5fd9524
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15121
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Handle DeviceLostCallback once DeviceLost error occurs.
Disallow any other commands or actions on device to happen after device
has been lost.
Bug: dawn:68
Change-Id: Icbbbadf278cae5e6213050d00439118789c863dc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12801
Commit-Queue: Natasha Lee <natlee@microsoft.com>
Reviewed-by: Austin Eng <enga@chromium.org>
BUG=dawn:274
Change-Id: Ia7bfc96a2a85bff5b30065e7b985e0d84c8dcd4b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15120
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
The dawn_native::Adapter::GetPCIInfo/GetBackendType/GetDeviceType
methods are now deprecated in favor of a method returning a webgpu.h
AdapterProperties structure. Deprecated function are still available to
avoid breaking Chromium or Skia compilation.
This reduces the difference between dawn.json and webgpu.h
BUG=dawn:160
Change-Id: Ib68fe1c4d1d87676c01c212c91f80fdd26056c56
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14541
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Allocating buffers with sizes close to UINT64_MAX caused issues in all
Vulkan drivers. See https://gitlab.khronos.org/vulkan/vulkan/issues/1904
for more context. Do early validation to prevent such cases from
reaching the driver.
Bug: dawn:241
Fixed: dawn:241
Change-Id: I7edbb25999b4c11767047518b69edc1fa624cd3b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14641
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This will enable fuzzing the Vulkan backend with randomly injected
errors to help ensure the backend properly handles all errors. It also
redefines VkResult in the dawn_native::vulkan namespace such that a
VkResult cannot be used unless it is explicitly wrapped.
Bug: dawn:295
Change-Id: I3ab2f98702a67a61afe06315658a9ab76ed4ccc3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14520
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
To help with Device Loss, this splits Device backend destructors
to WaitForIdleForDestruction and Destroy.
WaitForIdleForDestruction waits for GPU to finish, checks errors and gets
ready for destruction.
Destroy is used to clean up and release resources used by device,
does not wait for GPU or check errors.
Bug: dawn:68
Change-Id: I054fd735e8d5b289365604209f38e616c723a4e7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14560
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Commit-Queue: Natasha Lee <natlee@microsoft.com>
The LogMessage::LogMessage constructor was redefining a symbol that
exists in re2 inside of Chromium. So we namespace Log inside dawn:: to
avoid the conflict.
BUG=dawn:302
Change-Id: Ida349208e2c6fe9ac032e1bd8cd442dff0b3f6bc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14320
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This change implements Vulkan backend for readonly storage buffer. It
also adds a few end2end tests to verify the implementation.
BUG=dawn:180
Change-Id: I0d680654fa490192c357eccdcdce8e56a8037bce
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14200
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
The Vulkan spec mandates support for only one or the other, which is
why we have the concept of a depth24plus format. This also adds a Toggle
to test both formats in DepthStencilStateTests.
Finally this renames ForceWorkarounds to ForceToggles because toggles
can be more than just workarounds.
BUG=dawn:286
Change-Id: I5b5dc582ffd4ee61c51e3e75563aec815c580511
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14103
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: David Turner <digit@google.com>
On Android iostream doesn't appear in logcat, the system log that's
often used for printf debugging. Introduce Chromium/ANGLE like logging
that looks like the following:
InfoLog() << stuff << stuff;
This makes sure the message is put in logcat on Android and removes
static initializers from <iostream>
BUG=dawn:286
Change-Id: Ie0d018f49bcac1a7b740739a6e59d45ae6728638
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14102
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This is the first step for having a fully operational SPVC usage
path. This version of SPVC integration uses SPVC for setting up the
options to the compiler, but a lot of the actual interaction with
spirv-cross is done in Dawn, just via SPVC's compiler object.
Future CLs will migrate more of the spirv-cross interaction to using
the SPVC API, eventually removing the need for Dawn to know about
spirv-cross.
BUG=dawn:288
Change-Id: I68e0773f910d7fe967235b6987b3debe1d13883f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14143
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Contrary to Linux, libvulkan.so on Android doesn't have the additional
.1 at the end (libvulkan.so.1 on Linux)
BUG=dawn:286
Change-Id: I22f06121b81e0fe08faae7d105a7c2094e788184
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14104
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The Vulkan specification requires that GRAPHICS and COMPUTE queue
support transfer operations, but it doesn't require them to expose the
TRANSFER flag. Make Dawn not require that flag so it can find a
universal queue on Adreno drivers.
BUG=dawn:286
Change-Id: Id4811e2077b27aa7db5ce554a4fd919c3cdcdb96
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14101
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This adds swiftshader as a dependency of Dawn, and when it is present
dawn_use_swiftshader=true will force usage of it. (due to a Vulkan
loader limitation we can't have both regular drivers and swiftshader in
the same VkInstance).
BUG=dawn:283
Change-Id: Ib94f4dcca652eb380e994f007cdcfb145b1a5102
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13440
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This CL implements the MemoryService for importing memory and
creating VkImages from a dma-buf handle. Under the hood, it uses the
VK_EXT_external_memory_dma_buf and
VK_EXT_image_drm_format_modifier extensions to find a memory type
that supports dma-buf import. In addition, the extensions are also
used to properly specify the stride and tiling of the dma-buf to
vkAllocateMemory and vkCreateImage.
BUG=chromium:996470
Change-Id: Ie72d73117a4cbafcb40468aab0952b783351d499
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13785
Commit-Queue: Brian Ho <hob@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This CL adds an API to import a dma-buf into Dawn as a WGPUTexture.
We also add a descriptor type enum to the base
ExternalImageDescriptor struct. This is because all memory import
code (e.g. MemoryService, Texture::CreateFromExternal) takes the
a base ExternalImageDescriptor as a parameter. The dma-buf external
memory and image services, however, will need to downcast to
ExternalImageDescriptorDmaBuf to access import parameters like
stride. Explicitly adding a type enum will let us more safely verify
the type before downcasting.
BUG=chromium:996470
Change-Id: I2d9883a15e9059a91f2c7bdb7a96d74373e18c56
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13782
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Brian Ho <hob@chromium.org>
This CL introduces SupportsCreateImage and CreateImage to the
external memory service API to provide different implementations for
creating VkImages for different types of external image handles.
While opaque FD and Zircon seem to share the same vkCreateImage
implementation, dma-buf import will require the use of the
VkImageDrmFormatModifierExplicitCreateInfoEXT [1] struct (among
other differences) with vkCreateImage.
[1] https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkImageDrmFormatModifierExplicitCreateInfoEXT.html
BUG=chromium:996470
Change-Id: I3eb11f8877d4465f5fcdd4089d5fdd8acbc1da10
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13781
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Brian Ho <hob@chromium.org>
This CL adds a few Vulkan extensions to be used for importing
dma-bufs as VkImages.
In particular, we need:
- VK_EXT_external_memory_dma_buf
- VK_EXT_image_drm_format_modifier
BUG=chromium:996470
Change-Id: I7a3dfd0184177c756b07613fbfe140506f54584c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13783
Commit-Queue: Brian Ho <hob@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL is part of a chain of CLs that imports dma-bufs as VkImages
to support WebGPU on Chrome OS.
There are currently two steps for importing external memory into
Vulkan:
1. DeviceVk::ImportExternalImage: calls into
MemoryServiceOpaqueFD::ImportMemory which in turn calls into
vkAllocateMemory and outputs a VkDeviceMemory handle to the
imported memory.
2. TextureVk::CreateFromExternal: creates the actual TextureVk
object, creates the VkImage, and binds the VkDeviceMemory from
ImportExternalImage to the VkImage.
For dma-buf support, however, we need to re-order these two steps
because importing dma-buf memory requires a handle to the VkImage
that will alias it [1].
This CL splits these two steps into three steps to ensure we create
the VkImage first so we can use it in vkAllocateMemory:
1. TextureVk::CreateFromExternal: creates the TextureVk and
VkImage (no longer concerns itself with vkBindImageMemory).
2. DeviceVk::ImportExternalImage: now takes the VkImage as input
but is otherwise unchanged.
3. TextureVk::BindExternalMemory: calls vkBindImageMemory with
handles to VkDeviceMemory and VkImage.
[1] https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkMemoryDedicatedAllocateInfo.html
BUG=chromium:996470
Change-Id: Id2d5951e9b573af79c44ce8c63be5210a279f946
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13780
Commit-Queue: Brian Ho <hob@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This seems to be a regression introduced by CL:12022, where the
previously recorded semaphores are leaked while resetting the recording
context. The Vulkan validation layers will complain about this when
running the Linux-only image wrapping tests. Also, the semaphores are
queued for deletion with the right serial now.
Bug: dawn:19, dawn:150
Change-Id: I50fd46ca9de9199b29be2f85d5e9bd7394a10f1a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13420
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Jiajie Hu <jiajie.hu@intel.com>
This was unnecessary verbosity. Fix this by having the ProcTable
generator using type aliases so all types appear like they have
"Base".
BUG=
Change-Id: I8c472fb924f6ce739e4e41038452381b4f727a2b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/13442
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Deploy self-built Vulkan validation layers instead of system installed
one. And it will reuse third_party/angle's Vulkan validation layers if
building with chromium.
Bug: dawn:150
Change-Id: I94e26f7a152fb2a1c39bcb102d60024f4d65eee6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11120
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This changes puts descriptor pools in the BindGroupLayout so that they
can be reused between descriptors with the same layout.
This makes the DrawCallPerf.Run/Vulkan_NoReuseBindGroups benchmark go
from 1400ns to 800ns per run.
BUG=dawn::256
Change-Id: Ia9baf7f998d9ff4d552e255c80069b67c6a9ac40
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12920
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
In WebGPU these are uint32_t because Vulkan accepts at most a 32-bit
unsigned integer.
Bug: dawn:22
Change-Id: Ia61cd710f80c19135ac215a9a93ef9a8f683bac2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12942
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This is a helper to allow a Dawn embedder to look up the Vulkan device
functions. Possibly remove when we design a cleaner way to share function
pointers.
Change-Id: I3ed92568e543c1aad9e0e64d72ad0990824640cb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12980
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
