988716943f
* Added tests for texture zero init sadly, they are typically passing even if texture zero init isn't doing its job However, they form nice isolated examples for testing out texture initialization It could be possible to dirty texture memory prior to ensure zero init did the job * texture init tracker * tracking texture init requirements for bind group, transfer and rendertarget * texture clears for texture init * queue submit * write_texture * Enforce presence of either render target or copy_dst flag * clear render targets also with using buffer copies enforce COPY_DST usage now on all textures * adjust ImageSubresourceRange.layer_range calculation for 3D textures init_tracker has now a `discard` function to get single data points back to uninitialized use new standardized partition_point function * track init state for discarded textures from renderpasses missing: * init on the fly if discarded is found within command buffer * handle discarding only stencil or only depth * added tests for zero init after discard * tracking discarded surfaces now in separate struct, piping all inits through utility function allows to resolve discard/init_action interactions * Move various memory init code to separate mod CommandBufferTextureMemoryActions is now fully encapsulated * implemented discard init fixups for everything but renderpass * render passes also cause now discard fixups * fixup_discarded_surfaces takes now an iterator instead of Drain * Add memory init test for discarding depth targets * handle divergently discarded depth/stencil target * comment & clippy fixes * fix collect_zero_buffer_copies_for_clear_texture yielding block breaking copies * [pr feedback] minor cleanup in zero_init_texture_after_discard, `use` hygenie * [pr feedback] fix bug in ImageSubresourceRange range utils * [pr feedback] fix texture tracker check, bundle transition_texture on init, cleanups * Implemented drop for InitTrackerDrain * remove incorrect comment about extents in add_pass_texture_init_actions * Fix unit test & clippy issues in init_tracker
wgpu-rs is an idiomatic Rust wrapper over wgpu-core. It's designed to be suitable for general purpose graphics and computation needs of Rust community.
wgpu-rs can target both the natively supported backends and WASM directly.
See our gallery and the wiki page for the list of libraries and applications using wgpu-rs.
Usage
How to Run Examples
All examples are located under the examples directory.
These examples use the default syntax for running examples, as found in the Cargo documentation. For example, to run the cube example:
cargo run --example cube
The hello* examples show bare-bones setup without any helper code. For hello-compute, pass 4 numbers separated by spaces as arguments:
cargo run --example hello-compute 1 2 3 4
The following environment variables can be used to configure how the framework examples run:
-
WGPU_BACKENDOptions:
vulkan,metal,dx11,dx12,gl,webgpuIf unset a default backend is chosen based on what is supported by your system.
-
WGPU_POWER_PREFOptions:
low,highIf unset a low power adapter is preferred.
-
WGPU_ADAPTER_NAMESelect a specific adapter by specifying a substring of the adapter name.
Run Examples on the Web (wasm32-unknown-unknown)
See wiki article.
Shaders
WGSL is the main shading language of WebGPU.
Users can run the naga binary in the following way to convert their SPIR-V shaders to WGSL:
cargo run -- <input.spv> <output.wgsl>
In addition, SPIR-V can be used by enabling the spirv feature and GLSL can be enabled by enabling the glsl feature at the cost of slightly increased build times.