objc4
MoltenVK
| objc4 | MoltenVK | |
|---|---|---|
| 2 | 103 | |
| 6 | 4,548 | |
| - | 1.3% | |
| 0.0 | 9.0 | |
| almost 3 years ago | 5 days ago | |
| Objective-C++ | Objective-C++ | |
| GNU General Public License v3.0 or later | 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.
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
MoltenVK
- MoltenVK is a layered implementation of Vulkan 1.2
-
Valve Says Counter-Strike 2 for macOS Not Happening, There Aren't Enough Players
https://github.com/KhronosGroup/MoltenVK
Translating between rendering APIs is not really the problem. The GPU design is more different than the API is.
-
Meta Releases Intermediate Graphics Library
Khronos maintains MoltenVk though, which is "official" as it gets: https://github.com/KhronosGroup/MoltenVK
...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), Microsoft doesn't support Vulkan either ;)
-
I love the ally, but fuck Windows
MoltenVK implements large parts of Vulkan on top of Metal for Apple systems. It isn't full Vulkan but it makes porting Vulkan games to OS X easier.
- Apple releases a Game Porting Tool, based on open-source platform Wine, which can translate DirectX 12 into Metal 3, a potentially massive step for Mac gaming
- Apple’s Game Porting Toolkit is Wine
-
CrossOver announces DirectX 12 support coming to macOS this summer
That's cool. Maybe I haven't thought enough about this. Let me check it out. FWIW it's this PR that you are referring to I think: https://github.com/KhronosGroup/MoltenVK/pull/1815/
-
Apple Begins Testing Speedy M3 Chips as It Pursues Mac Comeback
For Metal specifically, they could adopt and contribute to Vulkan and get access to a lot more software. Right now you need to use a compatibility layer, and surely Apple could just support both APIs natively with much lower overhead. But they don't, because it nudges developers to stick to the Apple ecosystem instead of being able to support multiple platforms.
-
What do we miss to play DirectX 12 Games on Mac?
At the moment the most promising thing is MoltenVK (DX12 -> DXVK -> Vulkan -> MoltenVK -> Metal), but the development is not that quick mainly because there aren't tons of developer that works at the same time on the project. It's not actually a Metal related problem at the moment (they have a road map of things that they can be achieved with Metal 3 like Mesh shader and Geometry shader).
-
Is there a good reason to not allow vulkan on macos as another option?
What you asked is already existed for at least 8 years. Yeah EIGHT years. It's called "MoltenVK". So far it's the only implementation of Vulkan for macOS. Basically it's a wrapper that runs on top of Metal API.
What are some alternatives?
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++.
DXVK-macOS - Vulkan-based implementation of D3D10 and D3D11 for macOS / Wine
metal-rs - Rust bindings for Metal
clspv - Clspv is a compiler for OpenCL C to Vulkan compute shaders
MoltenGL
wgpu - Cross-platform, safe, pure-rust graphics api.
FF14-MAC_ModSupport - Alternative method of running FFXIV on Mac with Mod Support.
dxvk - Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine
dxvk-async
Vita3K - Experimental PlayStation Vita emulator
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 iOS and macOS.