wgpu
bgfx
wgpu | bgfx | |
---|---|---|
212 | 77 | |
14,362 | 15,794 | |
2.3% | 1.0% | |
9.9 | 9.1 | |
2 days ago | 7 days ago | |
Rust | C++ | |
Apache License 2.0 | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wgpu
-
Ask HN: Resources for General Purpose GPU development on Apple's M* chips?
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.
-
What's Next for WebGPU
This is in reference to [1].
[1] https://github.com/gfx-rs/wgpu/issues/6434
-
Repeatability: As Difficult as it is Important
> 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
-
Pygfx
Sorry, 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 the exact same underlying graphics 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://github.com/gfx-rs/wgpu
-
Q3 dev update for Graphite, a Blender-inspired 2D procedural design Rust app
Everything will be using compute shaders for the foreseeable future. [WGPU](https://wgpu.rs/) abstracts that to work with WebGPU on browsers, DirectX/Vulkan on Windows, Metal on Mac, and Vulkan on Linux and Android. There may be opportunities to explore vendor-specific options like CUDA in the far future to leverage a further increase in performance, but compute shaders are portable and nearly as good.
- How to get started in Graphics Programming in 2024?
-
A high-performance, zero-overhead, extensible Python compiler using LLVM
Instead of building their GPU support atop CUDA/NVIDIA [0], I’m wondering why they didn’t instead go with WebGPU [1] via something like wgpu [2]. Using wgpu, they could offer cross-platform compatibility across several graphics API’s, covering a wide range of hardware including NVIDIA GeForce and Quadro, AMD Radeon, Intel Iris and Arc, ARM Mali, and Apple’s integrated GPU’s.
They note the following [0]:
> The GPU module is under active development. APIs and semantics might change between Codon releases.
The thing is, based on the current syntax and semantics I see, it’ll almost certainly need to change to support non-NVIDIA devices, so I think it might be a better idea to just go with WebGPU compute pipelines sooner rather than later.
Just my two pennies…
[0]: https://docs.exaloop.io/codon/advanced/gpu
[1]: https://www.w3.org/TR/webgpu
[2]: https://wgpu.rs
-
SDL3 new GPU API merged
wgpu 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.
- First major release of gfx-rs/wgpu
-
I learned Vulkan and wrote a small game engine with it (in 3 months)
https://github.com/gfx-rs/wgpu?tab=readme-ov-file#tracking-t...
bgfx
-
Layers All the Way Down: The Untold Story of Shader Compilation
BGFX (https://github.com/bkaradzic/bgfx) uses a different approach. You basically write your shader in a GLSL-like language but it's all just (either very clever or very horrible) macro expansions that handles all the platform differences.
- Bgfx: Cross-platform, graphics API agnostic rendering library
-
SDL3 new GPU API merged
I previously integrated bgfx [1], which allows you to write graphics code and shaders once and supports consoles, with SDL2 stack and Swift [2]. It was quite a nice experience, especially for someone who had never worked with any of these tools before. I'm excited for SDL3 as it introduces console abstractions, eliminating the need for additional dependencies for the GPU API, especially for someone who casually experiments with graphics. Moreover, Godot officially supports the Steam Deck, and hopefully, more consoles will be supported in the future. On a related note, Miguel de Icaza is advocating for Swift adoption in Godot, and he is working on porting the editor to SwiftUI on iPad, which is quite interesting to see the progress [3].
[1] https://bkaradzic.github.io/bgfx/overview.html
[2] https://github.com/bgbernovici/myndsmith
[3] https://blog.la-terminal.net/xogot-code-editing/
-
I learned Vulkan and wrote a small game engine with it (in 3 months)
I'm curious why webgpu is receiving so much attention. There have been many low-level cross-platform graphics abstractions over the years. The bgfx [1] project had its first commit ~12 years ago and it's still going! It's much more mature than webgpu. I'm guessing being W3C backed is what's propelling it?
[1] https://github.com/bkaradzic/bgfx
-
Orthodox C++
I don't use orthodox C++, but the author of this is also the author of bgfx, which is a very popular graphics api abstraction. It runs on (and has commercial products on) Android, ios, Playstation, Xbox, PC, Mac, Linux, and wasm. While the coding style might be unpopular, it has successful projects.
https://github.com/bkaradzic/bgfx
- WebKit Switching to Skia for 2D Graphics Rendering
-
Is it possible and realistic to learn independent of an API?
Sort of, I'd recommend a modern higher level API. I'm not sure what the current recommended ones are (probably bgfx), but assuming the wrapper is "low level enough", then the concepts you learn are still going to apply.
-
Ask HN: Released games built on FOSS engines?
https://github.com/bkaradzic/bgfx for just that FOSS intermediate rendering library (includes Minecraft)
- Valve Says Counter-Strike 2 for macOS Not Happening, There Aren't Enough Players
-
The Ultimate Cross-Platform Rendering Engine?
BGFX: Pretty mature and easy to use with many backends.
What are some alternatives?
glow - GL on Whatever: a set of bindings to run GL anywhere and avoid target-specific code
The-Forge - The Forge Cross-Platform Framework PC Windows, Steamdeck (native), Ray Tracing, macOS / iOS, Android, XBOX, PS4, PS5, Switch, Quest 2
gfx - [maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
GLFW - A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input
vulkano - Safe and rich Rust wrapper around the Vulkan API
Ogre 3D - scene-oriented, flexible 3D engine (C++, Python, C#, Java)