Wumpf 988716943f Zero init textures (#1688)
* 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
2021-10-28 09:15:53 -04:00
2021-10-07 19:15:49 -04:00
2021-09-15 14:46:01 -04:00
2021-10-08 07:34:15 +02:00
2021-06-19 21:06:08 +03:00
2021-10-28 09:15:53 -04:00
2021-10-28 09:15:53 -04:00
2021-10-28 09:15:53 -04:00
2021-10-07 19:15:49 -04:00
2021-10-28 09:15:53 -04:00
2021-10-04 08:47:13 -04:00
2021-09-13 23:57:33 -04:00
2021-10-12 12:22:49 -04:00
2021-06-18 13:40:31 -04:00
2021-06-18 13:40:31 -04:00
2021-10-07 19:15:49 -04:00
2020-04-06 08:55:39 -04:00

wgpu

Matrix Space Dev Matrix  User Matrix Build Status codecov.io

wgpu is a cross-platform, safe, pure-rust graphics api. It runs natively on Vulkan, Metal, D3D12, D3D11, and OpenGLES; and on top of WebGPU on wasm.

The api is based on the WebGPU standard. It serves as the core of the WebGPU integration in Firefox, Servo, and Deno.

Repo Overview

The repository hosts the following libraries:

  • Crates.io docs.rs - User facing Rust API.
  • Crates.io docs.rs - Internal WebGPU implementation.
  • Crates.io docs.rs - Internal unsafe GPU API abstraction layer.
  • Crates.io docs.rs - Rust types shared between all crates.
  • Crates.io - WebGPU implementation for the Deno JavaScript/TypeScript runtime

The following binaries:

  • cts_runner - WebGPU Conformance Test Suite runner using deno_webgpu.
  • player - standalone application for replaying the API traces.
  • wgpu-info - program that prints out information about all the adapters on the system or invokes a command for every adapter.

For an overview of all the components in the gfx-rs ecosystem, see the big picture.

Getting Started

Rust

Rust examples can be found at wgpu/examples. You can run the examples with cargo run --example name. See the list of examples. For detailed instructions, look at our Get Started wiki.

If you are looking for a wgpu tutorial, look at the following:

C/C++

To use wgpu in C/C++, you need wgpu-native.

Others

If you want to use wgpu in other languages, there are many bindings to wgpu-native from languages such as Python, D, Julia, Kotlin, and more. See the list.

Community

We have the Matrix space Matrix Space with a few different rooms that form the wgpu community:

  • Dev Matrix - discussion of the library's development.
  • User Matrix - discussion of using the library and the surrounding ecosystem.
  • Random Matrix - discussion of everything else.

Wiki

We have a wiki that serves as a knowledge base.

Supported Platforms

API Windows Linux & Android macOS & iOS
Vulkan
Metal
DX12 (W10 only)
DX11 🚧
GLES3 🆗

= First Class Support — 🆗 = Best Effort Support — 🚧 = Unsupported, but support in progress

Environment Variables

All testing and example infrastructure shares the same set of environment variables that determine which Backend/GPU it will run on.

  • WGPU_ADAPTER_NAME with a substring of the name of the adapter you want to use (ex. 1080 will match NVIDIA GeForce 1080ti).
  • WGPU_BACKEND with a comma separated list of the backends you want to use (vulkan, metal, dx12, dx11, or gl).
  • WGPU_POWER_PREFERENCE with the power preference to choose when a specific adapter name isn't specified (high or low)

When running the CTS, use the variables DENO_WEBGPU_ADAPTER_NAME, DENO_WEBGPU_BACKEND, DENO_WEBGPU_POWER_PREFERENCE.

Testing

We have multiple methods of testing, each of which tests different qualities about wgpu. We automatically run our tests on CI if possible. The current state of CI testing:

Backend/Platform Status
DX12/Windows 10 ✔️ (over WARP)
DX11/Windows 10 🚧 (over WARP)
Metal/MacOS (no CPU runner)
Vulkan/Linux 🆗 (cts hangs)
GLES/Linux (egl fails init)

Core Test Infrastructure

All framework based examples have image comparison tested against their screenshot.

To run the test suite on the default device:

cargo test --no-fail-fast

There's logic which can automatically run the tests once for each adapter on your system.

cargo run --bin wgpu-info -- cargo test --no-fail-fast

Then to run an example's image comparison tests, run:

cargo test --example <example-name> --no-fail-fast

Or run a part of the integration test suite:

cargo test -p wgpu -- <name-of-test>

If you are a user and want a way to help contribute to wgpu, we always need more help writing test cases.

WebGPU Conformance Test Suite

WebGPU includes a Conformance Test Suite to validate that implementations are working correctly. We can run this CTS against wgpu.

To run the CTS, first you need to check it out:

git clone https://github.com/gpuweb/cts.git
cd cts
# works in bash and powershell
git checkout $(cat ../cts_runner/revision.txt)

To run a given set of tests:

# Must be inside the cts folder we just checked out, else this will fail
cargo run --manifest-path ../cts_runner/Cargo.toml --frozen -- ./tools/run_deno --verbose "<test string>"

To find the full list of tests, go to the online cts viewer.

The list of currently enabled CTS tests can be found here.

Coordinate Systems

wgpu uses the coordinate systems of D3D and Metal:

Render Depth Texture
render_coordinates depth_coordinates texture_coordinates
Description
No description provided
Readme 137 MiB
Languages
Rust 79.9%
WGSL 16.2%
HLSL 2%
GLSL 1.7%
JavaScript 0.2%