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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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

70 sources
Amusingly, some of this is technically already happening. The shaders pass through downstream compilers that complain if they see what they determine to be a no-op infinite loop. To prove to the compilers that the loop terminates, most WebGPU implementations inject a u64 counter (technically a vec2<u32>) that counts down from u64:MAX and terminates the loop once it reaches 0. But that's such a large amount to count that the WindowServer is long gone. Fun discussion on this PR for wgpu, a Rust implementation of WebGPU: https://github.com/gfx-rs/wgpu/issues/6572
In The Deathray: A simple way for an untrusted site to freeze a Mac
That's a fun read. I use WGPU, but from Rust, which has a roughly similar library.[1] There are three levels of shims between the user application and the GPU - WGPU, the Vulkan library, and the Vulkan driver for the GPU. This varies a bit with the platform. None of these do much work. They mostly move data around. To draw something, with modern basic 3D graphics, the application creates a mesh object, which is a few big arrays. There are vertices with X, Y and Z coordinates, triplets of vertex indices to define triangles, and some other info. You create texture objects, which are just 2D pictures in memory. Each object has a transform, a 4x4 matrix that transforms it into world space, and finally there's a camera transform which projects the scene onto the flat screen. And you provide some shader programs which run on the GPU to process
Read the rest
that data. All that data is moved, usually unmodified, into the GPU. Or placed where the GPU can reach it, in systems with "integrated graphics". The GPU's hardware and firmware then take that data and draw it. So what are WGPU and the Vulkan layers doing? Managing memory, time and safety. They're responsible for allocating GPU memory, interlocking against changing data in the GPU while the GPU is doing something with it, and preventing cross-process memory accesses by keeping the GPU from doing things to memory of another process. This is more like the job of an operating system than a graphics program. These levels of the graphics stack don't do much graphics. The application says what to do in formats the GPU hardware understands. There's a lot of cross platform stuff going on. WGPU can support quite a few graphics back ends. Its native language is Vulkan, but Direct-X is supported to keep Microsoft happy, Metal is supported to keep Apple happy, Android is supported to keep Google happy, WebGPU is supported to keep browsers happy, and OpenGL is supported to keep people with old hardware happy. There are some lowest common denominator problems; Android and WebGPU use subsets of Vulkan and run a few years behind desktop. The back end is not hidden from the application. Some special cases have to be handled, one of them being "integrated graphics". Also, Vulkan has a huge list of optional features, many of which are not available on older platforms. WGPU doesn't hide that; it tells the application what's available and the application has to handle it or say it can't. It's all plumbing. [1] https://github.com/gfx-rs/wgpu
In Learn WebGPU for C++
rekireki·Dec 22, 2025Submission

Build Android apps using Rust and Iced

Some time ago I decided to try building an Android app using Rust. After a few weeks I got it working. There was a new iced release recently, so I've just updated the example to new iced and wgpu. I'd like to share my experience to attract more attention to Rust on Android. First things, I want to thank all the people who work on the foundational crates and tools such as: - https://github.com/rust-mobile/android-activity - https://github.com/jni-rs/jni-rs - https://github.com/gfx-rs/wgpu - https://github.com/rust-windowing/winit - and many others When I started I had to learn what tools and examples already exist. Luckily, there's a good set of examples using both NativeActivity and GameActivity: https://github.com/rust-mobile/rust-android-examples The basic approach is that we take android-activity, winit and wgpu and that's it. On top o
Read the rest
f that you can find a few egui examples in the rust-android-examples repo. Alright, so after I've got the basic examples running, I wanted to combine them with iced. Iced is a crossplatform gui library focusing on desktop and web. The mobile support is explicitly a non-goal, as far as I can tell at the moment of writing. Yet, there's an issue where some people posted their experiments. That's how I knew it was possible: https://github.com/iced-rs/iced/issues/302 There's a way to integrate iced in wgpu applications, so called integration example: https://github.com/iced-rs/iced/tree/0.14.0/examples/integra... Above I mentioned that using winit and wgpu in combination with android-activity is enough to build the app. Putting together 1 + 1 I got 2: let's use iced integration example with android-activity. It was quite easy to compile with almost no errors. First issue I encountered is that there was no text rendered. I solved this by loading fonts the way it was shown here: https://github.com/pop-os/cosmic-text/issues/243#issue-21899... Then I patched a few widgets to add touch support. And that's it. My role here was to take all the prior work and combine it together in a way that there's a working example. Some other ways of building Android apps using Rust: - xilem has an explicit goal to support mobile https://github.com/linebender/xilem - egui supports mobile https://github.com/emilk/egui - game engines such as Fyrox and Bevy support mobile: - https://github.com/FyroxEngine/Fyrox - https://github.com/bevyengine/bevy - pretty much anything built on top of winit and wgpu All of the above is related to building native apps using either NativeActivity or GameActivity. I'm leaving webview out of scope of current post. What about iOS? As far as I know it should be similar or maybe simpler compared to Android. I haven't built it yet, but the next time I have a sizeable amount of free time, I'll try to make it work. The plan is the same: pick winit, wgpu, iced integration example, mix it together until it works. It'll require the same trick to load fonts, and maybe something else, but no visible blockers as of now. Once again, thanks to all the people who made it possible and I wish you have a great time building mobile apps with Rust!
173 points · Open discussion
I didn't even notice who I was replying to at first - so let me start by saying thank you for Ghostty. I spend a great deal of my day in it, and it's a beautifully put together piece of software. I appreciate the work you do and admire your attitude to software and life in general. Enjoy your windfall, ignore the haters, and my best wishes to you and your family with the upcoming addition. The project I'm mostly working on uses the wgpu crate, https://github.com/gfx-rs/wgpu, which may be of interest if writing cross-platform GPU code. (Though obviously if using Rust, not Zig). With it my project easily runs on Windows (via DX12), Linux (via Vulkan), macOS (via Metal), and directly on the web via Wasm/WebGPU. It is a "lowest common denominator", but good enough for most use-cases. That said, ever with simple shaders I had to implement some
Read the rest
workarounds for Xcode issues (e.g. https://github.com/gfx-rs/wgpu/issues/8111). But still vastly preferable to other debugging approaches and has been indispensable in tracking down a few bugs.
In AMD GPU Debugger
This comparison is kind of sloppy, though. OpenGL on the desktop needs to be compared to a concrete WebGPU implementation. While it still lags behind state of the art, `wgpu` has many features on desktop that aren't in the standard. For example, they've started working on mesh shaders too: https://github.com/gfx-rs/wgpu/issues/7197. If you stick to only what's compatible with WebGL2 on the desktop you'd face similar limitations.
In OpenGL: Mesh shaders in the current year
Rust GPU libraries such as wgpu and ash rely on external libraries such as vulkan-loader to load the actual ICDs, but for some reason Rust people really love dlopening them instead of linking to them normally. Then it's up to the consumer to configure their linker flags correctly so RPATH gets set correctly when needed, but because most people don't know how to use their linker, they usually end up with dumb hacks like these instead: https://github.com/Rust-GPU/rust-gpu/blob/87ea628070561f576a... https://github.com/gfx-rs/wgpu/blob/bf86ac3489614ed2b212ea2f...
In Rust running on every GPU
From Steve Wittens, a well respected graphics hacker, and maker of the excellent Use.GPU. https://acko.net/tv/usegpu/ . I'm mostly posting to expand context, and sprinkle in a couple light options. > Bindless resources are an absolute necessity for the modern style of rendering with nanite and raytracing. Yeah, for real. Looking at the November 2024 post "What's next for WebGPU" and HN comments, bindless is pretty high up there! There's a high level field survey & very basic proposal (in the hackmd link), and wgpu seems to be filling in the many gaps and seemingly quite far along in implementation. Not seeing any signs yet that the broader WebGPU implementors/spec folks are involved or following along, but at least wgpu is very cross platform & well regarded. https://developer.chrome.com/blog/next-for-webgpu https://news.ycombinator.com/i
Read the rest
tem?id=42209272 https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA https://hackmd.io/@cwfitzgerald/wgpu-bindless https://github.com/gfx-rs/wgpu/issues/3637 https://github.com/gpuweb/gpuweb/issues/380 > Would you like to render high quality lines or points? Sorry, it's not been a priority to make that simple. Better go study up on SDFs and beziers. I realize lines and font rendering are an insanely complex fields, and that OpenGL offering at least lines and Vulkan not sure feels like a slap in the face. The work being done by groups like https://linebender.org/ is intense. Overall though that intensity makes me question the logic of trying to include it, wonders whether fighting to specify something that clearly we don't have full mastery over makes sense: even the very best folks are still improving the craft. We could specify an API without specifying an exact implementation, without conformance tests, perhaps, but that feels like a different risk. Maybe having to reach for a library that does the work reflects where we are, causes the iteration & development we sort of need? > actually producing a lit, shaded and occlusioned image with PBR, indirect lighting, antialiasing and postfx I admit to envying the ambition to make this simple, to have such a great deep knowledge as Steve and to think such hard things possible. I really really am so thankful and hope funding can continue for the incredibly hard work of developing webgpu specs & implementations, and wgpu. As @animats chimes in in the HN submission, bindless in particular is quite a crisis, which either will enable the web to go forward, or remain a lasting real barrier to the web's growth. Really seems to be the tension of Steve's opening position: > WebGPU is both years too late, and just a bit early. Wheras WebGL was OpenGL circa 2005, WebGPU is native graphics circa 2015.
In Shipping WebGPU on Windows in Firefox 141

Showing the 15 most recent of 70 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.