metal-rs | objc4 | |
---|---|---|
5 | 2 | |
522 | 6 | |
1.7% | - | |
5.7 | 0.0 | |
4 days ago | almost 3 years ago | |
Rust | Objective-C++ | |
Apache License 2.0 | GNU General Public License v3.0 or later |
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-rs
-
What's the best way to learn Metal?
I found working in rust with these bindings much easier https://github.com/gfx-rs/metal-rs
-
Unified memory on M1 macs
An alternative would be to use rust bindings for metal with gfx-rs/metal-rs. There is a metal compute example in the examples folder.
-
Low overhead C++ interface for Apple's Metal API
Thanks very much for this detailed information, it's very helpful. I've filed https://github.com/gfx-rs/metal-rs/issues/222 to track it in the Rust ecosystem side.
- Conditionally run some parts of build.rs
objc4
-
Low overhead C++ interface for Apple's Metal API
> The specific method that's causing me trouble right at the moment is "computeCommandEncoder"
Yeah, it looks like there's no way to avoid autorelease here.
> It looks like objc_retainAutoreleasedReturnValue might be exactly what I'm looking for, even if it isn't 100% guaranteed; if I'm understanding, it would be safe, and wouldn't actually leak as long as you had an autorelease pool somewhere in the chain.
Indeed it would be safe and wouldn't leak, but the optimization is very much not guaranteed. It's based on the autorelease implementation manually reading the instruction at its return address to see if it's about to call objc_retainAutoreleaseReturnValue. See the description here:
https://github.com/apple-opensource/objc4/blob/a367941bce42b...
In fact – I did not know this before just now – on every arch other than x86-64 it requires a magic assembly sequence to be placed between the call to an autoreleasing method and the call to objc_retainAutoreleaseReturnValue.
It looks like swiftc implements this by just emitting LLVM inline asm blocks:
%6 = call %1* bitcast (void ()* @objc_msgSend to %1* (i8*, i8*, %0*)*)(i8* %5, i8* %3, %0* %4) #4
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.
metal-cpp - Metal-cpp is a low-overhead C++ interface for Metal that helps developers add Metal functionality to graphics apps, games, and game engines that are written in C++.
wgpu - Cross-platform, safe, pure-rust graphics api.
clspv - Clspv is a compiler for OpenCL C to Vulkan compute shaders
rust-bindgen - Automatically generates Rust FFI bindings to C (and some C++) libraries.