metal-cpp
wgpu
metal-cpp | wgpu | |
---|---|---|
16 | 212 | |
317 | 14,497 | |
2.5% | 1.8% | |
3.3 | 9.9 | |
7 months ago | 6 days ago | |
C++ | Rust | |
Apache License 2.0 | Apache License 2.0 |
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.
metal-cpp
-
Nitro: A fast, lightweight 3MB inference server with OpenAI-Compatible API
My understanding is the proliferation of “XYZ-cpp” AI frameworks is due to the c++ support in Apple’s gpu library ‘Metal’, and the popularity of apple silicon for inference (and there are a few technical reasons for this): https://developer.apple.com/metal/cpp/
-
Show HN: C-ocoa, Write iOS/macOS apps in any language, with a generated C API
This is basically also what the "official" C++ API for Metal does (https://developer.apple.com/metal/cpp/), it's an automatically generated bindings wrapper which calls into ObjC runtime functions.
I also dabbled a bit with this idea by parsing clang AST-dumps of macOS system headers:
https://github.com/floooh/objc-ast-experiments
Unfortunately this is very brittle, and also broke on ARM CPUs, I guess the shim code needs some ABI adjustments (famously, objc_msgSend has multiple "ABI shapes": https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...).
-
What's the best way to learn Metal?
There's official C++-interface: https://developer.apple.com/metal/cpp/
- What are some alternatives to OpenGL for Mac
- Opinion for graphic api's?
-
A brief interview with Tcl creator John Ousterhout
It doesn't matter if the project driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/).
In the future, the question won't be "what language do I need to learn to code on this platform", but instead "are there language bindings for my favourite language".
- Cross platform low level graphics API suitable for game development?
-
GCC now includes Modula-2 and Rust. Do they work on OpenBSD?
this? https://developer.apple.com/metal/cpp/
Doesn't it just use objc/runtime.h and if anything is missing you can just add your custom api calls?
-
A learning path for Vulkan that focuses on concepts?
Metal has C++ bindings (which cover a full app lifecycle so you don’t have to touch Objective-C/Swift at all) but they’re based on the Objective-C memory model. There are some helper structs mimicking shared pointers, but you’ll still need to understand the basics of how an autorelease pool is used to avoid memory leaks and/or bad access crashes.
-
CTO of Azure declares C++ "deprecated"
On https://developer.apple.com/metal/cpp/ check Foundation folder and all those nice Object::sendMessage().
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...
What are some alternatives?
MoltenVK - MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
glow - GL on Whatever: a set of bindings to run GL anywhere and avoid target-specific code
metal-rs - Deprecated Rust bindings for Metal
gfx - [maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
clspv - Clspv is a compiler for OpenCL C to Vulkan compute shaders
vulkano - Safe and rich Rust wrapper around the Vulkan API