31ac63ce3e
If [`VK_LAYER_KHRONOS_validation`] is present, and it supports [`VK_EXT_validation_features`], we can configure it with another instance creation info. element of type [`VkValidationFeaturesEXT`] to enable GPU-based validation. Wire `InstanceFlags::GPU_BASED_VALIDATION` to do this in the Vulkan backend. It's even already finding issues in our `examples` and other tests! But…we'd like to handle those later, since this is so important for users. So, I've broken that out to separate issues. The instances we're aware of: * `water` is running into sync. validation issues: see <https://github.com/gfx-rs/wgpu/issues/5231> * `wgpu_test::shader::struct_layout::uniform_input` is failing to instrument shaders now; see <https://github.com/gfx-rs/wgpu/issues/5245> It is apparent from this and the [DX12 implementation of GPU-based validation] that we will need to communicate clearly to users that `InstanceFlags::GPU_BASED_VALIDATION` implies `InstanceFlags::VALIDATION`. Not all backends enforce this yet; I have [split out this work][follow-up for flag implication]. Note that `VK_EXT_validation_features` has been deprecated in favor of the more general layer configuration mechanism offered by [`VK_EXT_layer_settings`]. [DX12 implementation of GPU-based validation]: https://github.com/gfx-rs/wgpu/pull/5146 [`VK_EXT_layer_settings`]: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_layer_settings.html [`VK_EXT_validation_features`]: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_validation_features.html [`VK_LAYER_KHRONOS_validation`]:https://vulkan.lunarg.com/doc/sdk/1.3.275.0/linux/khronos_validation_layer.html [`VkValidationFeaturesEXT`]: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkValidationFeaturesEXT.html [follow-up for flag implication]: https://github.com/gfx-rs/wgpu/pull/5232 |
||
|---|---|---|
| .. | ||
| examples | ||
| src | ||
| build.rs | ||
| Cargo.toml | ||
| LICENSE.APACHE | ||
| LICENSE.MIT | ||
| README.md | ||
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 accepts 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.