HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gfx-rs
wgpu
Rust2019–2026
gfx-rs / wgpu

wgpu

A cross-platform, safe, pure-Rust graphics API.

49Distinct people
70Mentions
0Explicit recommenders
18.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A cross-platform, safe, pure-Rust graphics API.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year70 dated mentions

Observed mentions: 2019-03-07 11:23:42 UTC to 2026-09-30 12:39:01 UTC.

051015202019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 20 mentions; 1 submissions, 19 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 9 mentions; 2 submissions, 7 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC716
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC17017
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC20119
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC927
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC514

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
wgpu wgpu is a cross-platform, safe, pure-Rust graphics API. It runs natively on Vulkan, Metal, D3D12, and OpenGL; and on top of WebGL2 and WebGPU on wasm. The API is based on the WebGPU standard, but is a fully native Rust library. It serves as the core of the WebGPU integration in Firefox, Servo, and Deno. Getting Started See our examples online at https://wgpu.rs/examples/. You can see the Rust sources at examples and run them directly with cargo run --bin wgpu-examples <example>. Learning wgpu If you are new to wgpu and graphics programming, we recommend starting with Learn Wgpu. Additionally, WebGPU Fundamentals is a tutorial for WebGPU which is very similar to our API, minus differences between Rust and Javascript. Documentation Guides We ship a set of documentation modules with information on useful architecture patterns, debugging tips, and more getting started information. Need Help? Want to Contribute? The wgpu community uses Matrix and Discord to discuss. - discussion of wgpu's development. - discussion of using the library and the surrounding ecosystem. - Dedicated support channel on the Rust Gamedev Discord. Other Languages To use wgpu in C or dozens of other languages, look at wgpu-native. These are C bindings to wgpu and has an up-to-date list of libraries bringing support to other languages. Learn WebGPU (for C++) is a good resource for learning how to use wgpu-native from C++. Quick Links Docs Examples Changelog v30 v30 v30 trunk trunk trunk Contributors are welcome! See CONTRIBUTING.md for more information. Supported Platforms API Windows Linux/Android macOS/iOS Web (wasm) Vulkan ✅ ✅ 🌋 Metal ✅ DX12 ✅ OpenGL 🆗 (GL 3.3+), or 📐 🆗 (GL ES 3.0+) 📐 🆗 (WebGL2) WebGPU ✅ ✅ = First Class Support 🆗 = Downlevel/Best Effort Support 📐 = Requires the ANGLE translation layer (GL ES 3.0 only). On macOS/iOS, use the angle feature. On Windows, gles uses WGL by default; build with cfg(windows_angle) to use ANGLE instead. 🌋 = Requires the MoltenVK translation layer 🛠️ = Unsupported, though open to contributions Environment Variables Testing, examples, and ::from_env() methods use a standardized set of environment variables to control wgpu's behavior. WGPU_BACKEND with a comma-separated list of the backends you want to use (vulkan, metal, dx12, or gl). WGPU_ADAPTER_NAME with a case-insensitive substring of the name of the adapter you want to use (ex. 1080 will match NVIDIA GeForce 1080ti). WGPU_DX12_COMPILER with the DX12 shader compiler you wish to use (dxc, static-dxc, or fxc). Note that dxc requires dxcompiler.dll (min v1.8.2502) to be in the working directory, and static-dxc requires the static-dxc crate feature to be enabled. Otherwise, it will fall back to fxc. See the documentation for more environment variables. When running the CTS, use the variables DENO_WEBGPU_ADAPTER_NAME, DENO_WEBGPU_BACKEND, DENO_WEBGPU_POWER_PREFERENCE, DENO_WEBGPU_DX12_COMPILER, and DENO_WEBGPU_STRICT_COMPLIANCE. Repo Overview For an overview of all the components in the gfx-rs ecosystem, see the big picture. MSRV policy TL;DR: If you're using wgpu, our MSRV is 1.87. If you're running our tests or examples, our MSRV is 1.95. We will avoid bumping the MSRV of wgpu without good reason, and such a change is considered breaking. Specific Details Due to complex dependants, we have three MSRV policies: wgpu's MSRV is 1.87 wgpu-core (and hence wgpu-hal, naga, naga-types and wgpu-types)'s MSRV is 1.87. The rest of the workspace has an MSRV of 1.95. It is enforced on CI (in "/.github/workflows/ci.yml") with the WGPU_MSRV, CORE_MSRV, and REPO_MSRV variables, respectively. This version can only be upgraded in breaking releases, though we release a breaking version every three months. The following rules apply: The wgpu-core crate should never require an MSRV ahead of Firefox's MSRV for nightly builds, as determined by the value of MINIMUM_RUST_VERSION in python/mozboot/mozboot/util.py. The wgpu crate should never require an MSRV ahead of Servo's MSRV, as determined by the value of their rust-version declaration in Cargo.toml The repository MSRV should never require an MSRV higher than stable - 3. For example, if stable is at 1.97, the repository MSRV should be no higher than 1.94. This is to allow people who are using a decently-updated OS-provided rust to be able to build our repository. Consider cross checking with NixOS, though this is not required. Testing and Environment Variables Information about testing, including where tests of various kinds live, and how to run the tests. Tracking the WebGPU and WGSL draft specifications The wgpu crate is meant to be an idiomatic Rust translation of the WebGPU API. That specification, along with its shading language, WGSL, are both still in the "Working Draft" phase, and while the general outlines are stable, details change frequently. Until the specification is stabilized, the wgpu crate and the version of WGSL it implements will likely differ from what is specified, as the implementation catches up. Exactly which WGSL features wgpu supports depends on how you are using it: When running as native code, wgpu uses Naga to translate WGSL code into the shading language of your platform's native GPU API. Naga is working on catching up to the WGSL specification, with bugs tracking various issues, but there is no concise summary of differences from the specification. When running in a web browser (by compilation to WebAssembly) without the "webgl" feature enabled, wgpu relies on the browser's own WebGPU implementation. WGSL shaders are simply passed through to the browser, so that determines which WGSL features you can use. When running in a web browser with wgpu's "webgl" feature enabled, wgpu uses Naga to translate WGSL programs into GLSL. This uses the same version of Naga as if you were running wgpu as native code.
Read the full README on GitHub

What Hacker News says

17 sources
The "ergonomic" API is the Javascript API. Of course that is only usable from Javascript (ok, and Typescript). If you want to use WebGPU from as many languages as possible, a C API is pretty much the only option. There's also a C++ API, but just as with the JS API, this is limited to a single language. For usage from Rust you can also use gfx-rs/wgpu, which has a Rust-idiomatic API (e.g. see: https://github.com/gfx-rs/wgpu/blob/trunk/examples/hello-tri... - which to be honest doesn't look more "ergonomic" than the C API to me). Also, it's not like the C API is "unergonomic", it works with C99 designated initialization which makes it quite nice to use. The only downside is COM-style manual lifetime management via ref/release calls, but if you are used to Direct3D that's a no-brainer (it works exactly the same), and the C++ API has RAII wra
Read the rest
ppers for this stuff.
In Capturing the WebGPU Ecosystem
Funnily enough, we've never actually been on WebGL! The runtime's built against wgpu [0], which is an abstraction layer that supports the native rendering APIs, WebGPU, and yes, WebGL. However, our renderer was built with native capabilities in mind (compute shaders!), so we would have had to rewrite it to support WebGL. We decided we'd keep up with WebGPU and see where it takes us :) In the future, we may write a fallback renderer that's compatible with WebGL/older GPUs, but we wanted to focus on getting our existing renderer working first. [0]: https://github.com/gfx-rs/wgpu
In Show HN: Ambient, a multiplayer game engine and platform using WASM/WebGPU/Rust
I double checked, and our rendering library _does_ partially supports DX11, as well as Angle, which lets you run the GLES3 backend on top of Angle on top of GLES2/DX11. They tend to be fairly buggy and incomplete, though. Arguably only usable for simple 2D games. There's been no real demand or contributors to improve it, but it's open source so there's no reason you or anyone else could stamp out the bugs https://github.com/gfx-rs/wgpu#supported-platforms.
In The anatomy of a Godot API call
WGPU is just finishing up a major reorganization of locking and internal memory management, going from a global lock to fine-grained Arc reference counts.[1] Change log, just posted a few minutes ago: "Arcanization of wgpu core resources: Removed 'Token' and 'LifeTime' related management, removed 'RefCount' and 'MultiRefCount' in favour of using only 'Arc' internal reference count, removing mut from resources and added instead internal members locks on demand or atomics operations, resources now implement Drop and destroy stuff when last 'Arc' resources is released, resources hold an 'Arc' in order to be able to implement Drop, resources have an utility to retrieve the id of the resource itself, removed all guards and just retrive the 'Arc' needed on-demand to unlock registry of resources asap removing locking from hot paths." From a perf
Read the rest
ormance standpoint, I'm much more concerned about being able to get all the CPUs working on the problem than slight improvements in per-CPU performance. My metaverse viewer has slow frames because loading content into the GPU from outside the rendering thread blocks the rendering thread. All that "ARCcanization" should fix that. (I'm a user of WGPU, not one of its developers.) [1] https://github.com/gfx-rs/wgpu/pull/3626/files/5b34df5a2e6f9...
In Making C++ safe without borrow checking, reference counting, or tracing GC
WebGPU can be used outside of the browser through native libraries: https://github.com/gfx-rs/wgpu https://dawn.googlesource.com/dawn (these are the libraries that are used in Firefox and Chrome to provide the WebGPU implementation, don't know if Apple/WebKit also has open-sourced theirs) Some non-browser WASM runtimes also have WebGPU support already, but unfortunately only for offscreen rendering or compute tasks (e.g. for writing cross-platform windowed apps as WASM blobs, there's a window system glue layer missing).
In I want to talk about WebGPU
Gecko engine looks pretty healthy to me overall. And WebGPU in particular is the least of a concern, given that Firefox's implementation is based on wgpu [1], which has great community and a lot of users within and outside of Rust ecosystem. I'm confident Firefox can ship it soon (tm). [1] https://github.com/gfx-rs/wgpu
In WebGPU Fundamentals
There are a number of up-and-coming Rust-based frameworks in this niche: - https://github.com/iced-rs/iced (probably the most usable today) - https://github.com/vizia/vizia - https://github.com/marc2332/freya - https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record) What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have: - https://github.com/rust-windowing/winit (cross-platform window creation) - https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12) - https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu
Read the rest
) - https://github.com/DioxusLabs/taffy (UI layout algorithms) - https://github.com/pop-os/cosmic-text (text rendering and editing) - https://github.com/AccessKit/accesskit (cross-platform accessibility APIs) In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)
In XUL Layout is gone

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.