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

gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.

Creative & MediaSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
19Distinct people
21Mentions
0Explicit recommenders
5.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.

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, 5:04:57 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 year21 dated mentions

Observed mentions: 2014-11-15 01:01:43 UTC to 2020-05-06 12:47:00 UTC.

024682014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020

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
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC110
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC606
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC817
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202

What Hacker News says

21 sources
grovesNL·May 6, 2020
It might be really difficult to avoid runtime shader translation without some other solution (e.g. populating pipeline caches ahead of time). For example, to provide MSL, there needs to be assumptions about exactly which MSL version is supported, all possible values of specialization constants if the MSL version is less than 1.2, all the details of which pipeline layouts will be used at runtime, etc. and all of these also have to match the internal logic used in Dawn or wgpu. There's some more discussion about this in gfx and wgpu, e.g. https://github.com/gfx-rs/gfx/issues/3117#issuecomment-57045...
In Point of WebGPU on Native
kvark·May 6, 2020
Shipping compiled shaders is a feature request that pops up from time to time in gfx-rs land [1]. So far, we have been skeptical about this. Something like a serializable pipeline cache would help, but not entirely solve the shipping binary size. Although, is it really important? "Hello Triangle" may be a few megs, but the code for shader translation is a constant addition to it, so extrapolating this 5.2Mb value is not useful. Currently, both Dawn and wgpu-native use SPIRV-Cross for translation of shaders. The plan is for both is to migrate to in-house translation. In case of wgpu, that would be Naga [2]. Sometime in the future, you could be able to include it with only WGSL -> AIR (Apple's shader IR) code path compiled in, without anything else. Could be good enough for the code size? :) [1] https://github.com/gfx-rs/gfx/issues/3117
Read the rest
[2] https://github.com/gfx-rs/naga
In Point of WebGPU on Native
modeless·Sep 12, 2019
You can still kind of have that experience by using ANGLE[1] as your OpenGL implementation. It lets you use the same dialect of OpenGL ES on Windows, Linux, Mac, and Android, with consistent behavior across platforms. ANGLE is the base of the WebGL implementation in Chrome. For WebGPU, we (Google) are working on a new native library called Dawn[2] that will fill the same role that ANGLE does for WebGL. I'm personally hopeful that Dawn itself can eventually be useful as a cross platform graphics abstraction for native apps as well as web apps. There's also Mozilla's gfx-rs[3] in the same space. [1] https://github.com/google/angle [2] https://dawn.googlesource.com/dawn [3] https://github.com/gfx-rs/gfx
In WebGPU and WSL in Safari
Svoka·Apr 1, 2019
MoltenGL proprietary and not the only implementation of the GL library on top of modern APIs. There's also ANGLE. It worked pretty OK-ish in my project running OpenGL game on Windows Phone 8. I was using Microsoft's fork [2]. Another alternative is GLOVE [3], which is a software OpenGL on top of Vulkan. Another interesting project is WebGPU [4] which targets to provide Vulkan-like APIs across various platforms in browsers. As it's offshoot which is not quite related is GFX-rs, which became a cross-platform Rust library providing low level graphics API (HAL layer). looking forward seeing ANGLE getting Metal backend, which been just a promise so far. [1] https://github.com/google/angle [2] https://github.com/Microsoft/angle [3] https://think-silicon.com/products/software/glove/ [4] https://en.wikipedia.org/wiki/WebGPU [5] https://github.com
Read the rest
/gfx-rs/gfx
In OpenTTD Compiled to WebAssembly
artursapek·Apr 1, 2019
A viable alternative is Rust + OpenGL, using gfx[1]. I've had success cross-compiling one Rust codebase to Windows, Mac, and Linux native applications that can render OpenGL graphics. I even got the compilation for all three targets working from within a single docker image, meaning the build can easily be set up in any modern CI system. [1] https://github.com/gfx-rs/gfx
In OpenTTD Compiled to WebAssembly
kodablah·Mar 7, 2019
> The code runs on a variety of platforms [...] eventually the Web (when the browsers gain support for the API, which is also in our scope of work). Have the big three confirmed intent to support WebGPU? Also, what is the state of WebGL backend support for gfx-rs? I'm watching [0] eagerly. That would be a great practical step towards gfx-rs in browsers today. 0 - https://github.com/gfx-rs/gfx/pull/2554
In The rise of wgpu
lambda·Jun 6, 2018
They do make some money on Macs, and Mac software, but not nearly as much as on iOS. Providing macOS gives a developer and designer platform for iOS. That is really important for them. So Metal being available on macOS is important for that reason. But it's also important in that the Mac platform is still important, just not nearly as important as iOS. OpenGL doesn't really have much of a future. Everyone is moving towards the next generation frameworks. It just happens that there was a lot of uncertainty about whether OpenGL could adapt or whether there would be a successor, and during that time Apple decided to invest in developing Metal. It wasn't until a couple of years later than Vulkan was released. In the meantime, Apple has built up quite a lot of tooling around Metal. And it's not like it's that difficult to write cross platform
Read the rest
apps that target the Mac. If you write against major engines, they will already have support for the different backends. If you are writing your own software, you can still target OpenGL, or you can target Vulkan and use MoltenVK to run it on macOS. And for the next several years, people writing portable software are going to have to either just target OpenGL, for compatibility with older graphics cards, or maintain at least two backends, OpenGL and Vulkan. Given that lots of games target DirectX first, and consider any of the cross-platform frameworks a porting effort, Apple probably doesn't consider it a big loss to add one more platform that needs to be ported to. What's going to wind up happening is more software like ANGLE (https://github.com/google/angle), MoltenVK (https://github.com/KhronosGroup/MoltenVK), and gfx-rs (https://github.com/gfx-rs/gfx and https://github.com/gfx-rs/portability, see http://gfx-rs.github.io/2018/04/09/vulkan-portability.html for details) for providing one set of abstractions on top of several different backends.
In Deprecation of OpenGL and OpenCL
moosingin3space·Jun 4, 2018
If you're programming in Rust, you can just use `gfx-rs`'s HAL[1]. This is designed to be a Vulkan-like API that works on top of Vulkan, Metal, D3D12, or OpenGL. If you aren't in Rust, just use Vulkan. There are high-performance wrappers for it in various stages of development, such as MoltenVK[2] for macOS and iOS, and VulkanOnD3D12[3] for UWP. Non-UWP Windows, Linux, and Android should support Vulkan natively through their GPU drivers. [1]: https://github.com/gfx-rs/gfx [2]: https://github.com/KhronosGroup/MoltenVK [3]: https://github.com/Chabloom/VulkanOnD3D12
In Apple introduces macOS Mojave

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