DYNAMIC_INDEXING is checked by default, since WGPU doesn't allow for any kind of specialization constants and constant indexing is nigh useless. STORAGE_RESOURCE_BINDING_ARRAY is enabled iff the device supports: - both or neither of uniform and buffer arrays with dynamic indexing; - both or neither of sampled and storage images with dynamic indexing. NONUNIFORM_INDEXING is enabled iff for ALL types of descriptor arrays *that are supported for dynamic indexing*, nonuniform indexing is also allowed. These flags have a limitation in that some platforms (eg. https://vulkan.gpuinfo.org/displayreport.php?id=11692#features_core_12) may support a strange subset of those features (example device supporting non-uniform indexing for textures and storage buffers, but NOT for storage textures or uniform buffers). In that case feature will be reported as missing, even though it is partially present. In the author's opinion, this flag set is convenient for the users to query; however, due to aforementioned limitations, it would be desirable to obtain statistics about "edge-case" platforms and what percentage of reports they comprise.
wgpu-hal is an explicit low-level GPU abstraction powering wgpu-core. It's a spiritual successor to gfx-hal, but with reduced scope, and oriented towards WebGPU implementation goals.
It has no overhead for validation or tracking, and the API translation overhead is kept to the bare minimum by the design of WebGPU. This API can be used for resource-demanding applications and engines.
Usage notes
All of the API is unsafe. Documenting the exact safety requirements for the
state and function arguments is desired, but will likely be incomplete while the library is in early development.
The returned errors are only for cases that the user can't anticipate, such as running out-of-memory, or losing the device. For the counter-example, there is no error for mapping a buffer that's not mappable. As the buffer creator, the user should already know if they can map it.
The API accept iterators in order to avoid forcing the user to store data in particular containers. The implementation doesn't guarantee that any of the iterators are drained, unless stated otherwise by the function documentation. For this reason, we recommend that iterators don't do any mutating work.
Debugging
Most of the information in https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications still applies to this API, with an exception of API tracing/replay functionality, which is only available in wgpu-core.