People have already mentioned Metal, but if you want cross platform, https://github.com/gfx-rs/wgpu has a vulkan-like API and cross compiles to all the various GPU frameworks. I believe it uses https://github.com/KhronosGroup/MoltenVK to run on Macs. You can also see the metal shader transpilation results for debugging.
In Ask HN: Resources for general purpose GPU development on Apple's M* chips?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
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
- rust-windowing/winit · linked in 4 of the same discussions
- bevyengine/bevy · linked in 2 of the same discussions
- emilk/egui · linked in 2 of the same 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.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 20 | 1 | 19 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 9 | 2 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 1 | 4 |
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 GitHubWhat Hacker News says
20 sourcesnightly with webgpu enabled gets farther, but still fails.
Uncaptured WebGPU error: Shader module creation failed: Parsing error
Encountered one or more errors while creating shader module "Update Lights Shader Module"
WebGPU compilation info for shader module "Update Lights Shader Module" (1 error(s), 0 warning(s), 0 info)
Shader 'Update Lights Shader Module' parsing error: unknown attribute: 'must_use'
┌─ wgsl:44:4
│
44 │ @must_use
│ ^^^^^^^^ unknown attribute
Uncaptured WebGPU error: ShaderModule with 'Update Lights Shader Module' label is invalid
looks like this happens for most of the shaders.
edit: seems to be related to this issue https://github.com/gfx-rs/wgpu/issues/5186
In Show HN: WebGPU Tech DemoHello https://xkcd.com/927
There's also WESL that aims to extend WGSL with modules and generics:
https://github.com/wgsl-tooling-wg/wesl-spec
and there's Naga project that can translate WGSL to other languages:
https://github.com/gfx-rs/wgpu/tree/trunk/naga
In The Slang Shading LanguageThis is in reference to [1].
[1] https://github.com/gfx-rs/wgpu/issues/6434
In What's Next for WebGPU> Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state.
Yes.
This has had a devastating effect on Rust 3D graphics. The main crate for doing 3D graphics in Rust is WGPU. WGPU supports not just WebGPU, but Android, Vulkan, Metal, Direct-X 12, and OpenGL. It makes them all look much like Vulkan. Bevy, Rend3, and Renderling, the next level up, all use WGPU. It's so convenient.
WGPU has lowest common denominator support. If WebGPU can't do something inside a browser, then WGPU probably can't do it on other platforms which could handle it. So WGPU makes your gamer PC perform like a browser or a phone. No bindless, no mul
Read the rest
tiple queues, and somewhat inefficient binding and allocation.
This is one reason we don't see high-performance games written in Rust.
After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026. I'm not sure that game dev in Rust has that much runway left. Three major projects have been cancelled and the main site for Rust game dev stopped updating in June 2024.[2]
[1] https://github.com/gfx-rs/wgpu/issues/6434
[2] https://gamedev.rs/
> Did they actually write that somewhere?
wgpu.rs for comments about "general purpose", "modern" is my own interjection, and [1] about the difference in priorities between the WGPU maintainers and (funnily enough) you.
I do believe a cross-platform and modern interface is difficult to square with high performance. I don't think either side is wrong to choose the priorities it has, but someone will be underserved. They probably need far more manpower/talent than they have to improve performance proportionately.
[1] https://github.com/gfx-rs/wgpu/discussions/5525
In Repeatability: As Difficult as it is ImportantSorry, I'll try to be clearer. QRhi docs[1] say "The Qt Rendering Hardware Interface is an abstraction for hardware accelerated graphics APIs, such as, OpenGL, OpenGL ES, Direct3D, Metal, and Vulkan." And PySide6 includes a (python) wrapper for QRhi[2]. Meanwhile, pygfx builds on wgpu-py[3] which builds on wgpu[4] which is a "is a cross-platform, safe, pure-rust graphics API. It runs natively on Vulkan, Metal, D3D12, and OpenGL".
So, from the standpoint of someone using PySide6, QRhi and pygfx seem to be alternative paths to doing GPU-enabled rendering, on the exact same range of GPU APIs.
Thus my question: How do they compare? How should I make an informed comparison between them?
[1] https://doc.qt.io/qt-6/qrhi.html
[2] https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/QRhiWidget...
[3] https://github.com/pygfx/wgpu-py/
[4] https://
Read the rest
pygfx/pygfx: https://github.com/pygfx/pygfx :
> Pygfx (pronounced “py-graphics”) is built on wgpu, enabling superior performance and reliability compared to OpenGL-based solutions.
pygfx/wgpu-py:
https://github.com/pygfx/wgpu-py/ :
> A Python implementation of WebGPU
gfx-rs/wgpu:
https://github.com/gfx-rs/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. It serves as the core of the WebGPU integration in Firefox and Deno
In Pygfxwgpu supports WebGPU: https://github.com/gfx-rs/wgpu :
> While WebGPU does not support any shading language other than WGSL, we will automatically convert your non-WGSL shaders if you're running on WebGPU.
In SDL3 new GPU API mergedFirst major version release of gfx-rs/wgpu
3 points · Open discussion> wgpu in Firefox
Ah, sorry, I didn't know that, thanks. On Chrome it uses either WebGL2 or WebGPU.
When running in a web browser (by compilation to WebAssembly) without the "webgl" feature enabled, wgpu relies on the browser's own WebGPU implementation.
https://github.com/gfx-rs/wgpu?tab=readme-ov-file#tracking-t...
In I learned Vulkan and wrote a small game engine with itShort version: hope, yes. Obtain now, no.
Long version: https://github.com/gfx-rs/wgpu/discussions/5525
There's a lock stall around resource allocation. The asset-loading threads can stall out the rendering thread.
I can see this in Tracy profiilng, but don't fully understand the underlying problem. Looks like one of three locks in WGPU, and I'm going to have to build WGPU with more profiling scopes to narrow the problem.
Very few people have gotten far enough with 3D graphics in Rust to need this.
Most Rust 3D graphics projects are like the OP's here - load up a mostly static scene and do a little
with it. If you load all the content before displaying, and don't do much dynamic modification beyond moving items around, most of the hard problems can be bypassed. You can move stuff just by changing its transform - that's cheap. So you can d
Read the rest
o a pretty good small-world game without hitting these problems. Scale up to a big world that won't all fit in the GPU at once, and things get complicated.
I'm glad to hear from someone else who's trying to push on this. Write me at "nagle@animats.com", please.
For a sense of what I'm doing: https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ
Do you know if these things I found offer any hope for being able to continue rendering a scene smoothly while we handle GPU memory management operations on worker threads?
https://gfx-rs.github.io/2023/11/24/arcanization.html
https://github.com/gfx-rs/wgpu/issues/5322
In I learned Vulkan and wrote a small game engine with itWgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu
In Linux When?This is a pretty good answer: https://github.com/gfx-rs/wgpu/tree/trunk/wgpu-hal
The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
In Linux When?Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.