wgpu/wgpu-hal

wgpu_hal: a cross-platform unsafe graphics abstraction

This crate defines a set of traits abstracting over modern graphics APIs, with implementations ("backends") for Vulkan, Metal, Direct3D, and GL.

wgpu_hal is 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.

The wgpu_hal crate's main design choices:

• Our traits are meant to be portable: proper use should get equivalent results regardless of the backend.

• Our traits' contracts are unsafe: implementations perform minimal validation, if any, and incorrect use will often cause undefined behavior. This allows us to minimize the overhead we impose over the underlying graphics system. If you need safety, the wgpu-core crate provides a safe API for driving wgpu_hal, implementing all necessary validation, resource state tracking, and so on. (Note that wgpu-core is designed for use via FFI; the wgpu crate provides more idiomatic Rust bindings for wgpu-core.) Or, you can do your own validation.

• In the same vein, returned errors only cover cases the user can't anticipate, like running out of memory or losing the device. Any errors that the user could reasonably anticipate are their responsibility to avoid. For example, wgpu_hal returns no error for mapping a buffer that's not mappable: as the buffer creator, the user should already know if they can map it.

• We use static dispatch. The traits are not generally object-safe. You must select a specific backend type like vulkan::Api or metal::Api, and then use that according to the main traits, or call backend-specific methods.

• We use idiomatic Rust parameter passing, taking objects by reference, returning them by value, and so on, unlike wgpu-core, which refers to objects by ID.

• We map buffer contents persistently. This means that the buffer can remain mapped on the CPU while the GPU reads or writes to it. You must explicitly indicate when data might need to be transferred between CPU and GPU, if wgpu_hal indicates that the mapping is not coherent (that is, automatically synchronized between the two devices).

• You must record explicit barriers between different usages of a resource. For example, if a buffer is written to by a compute shader, and then used as and index buffer to a draw call, you must use [CommandEncoder::transition_buffers] between those two operations.

• Pipeline layouts are explicitly specified when setting bind group. Incompatible layouts disturb groups bound at higher indices.

• The API accepts collections as iterators, 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.

Unfortunately, wgpu_hal's safety requirements are not fully documented. Ideally, all trait methods would have doc comments setting out the requirements users must meet to ensure correct and portable behavior. If you are aware of a specific requirement that a backend imposes that is not ensured by the traits' documented rules, please file an issue. Or, if you are a capable technical writer, please file a pull request!

Primary backends

The wgpu_hal crate has full-featured backends implemented on the following platform graphics APIs:

• Vulkan, available on Linux, Android, and Windows, using the ash crate's Vulkan bindings. It's also available on macOS, if you install MoltenVK.

• Metal on macOS, using the metal crate's bindings.

• Direct3D 12 on Windows, using the d3d12 crate's bindings.

Secondary backends

The wgpu_hal crate has a partial implementation based on the following platform graphics API:

• The GL backend is available anywhere OpenGL, OpenGL ES, or WebGL are available. See the gles module documentation for details.

You can see what capabilities an adapter is missing by checking the DownlevelCapabilities in [ExposedAdapter::capabilities], available from [Instance::enumerate_adapters].

The API is generally designed to fit the primary backends better than the secondary backends, so the latter may impose more overhead.

Debugging

Most of the information on the wiki Debugging wgpu Applications page still applies to this API, with the exception of API tracing/replay functionality, which is only available in wgpu-core.