Our great sponsors
-
> 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 -
Thanks, this is helpful. The specific method that's causing me trouble right at the moment is "computeCommandEncoder"[1], which is a method off MTLCommandBuffer, and I think not in the "new" class. In the Rust bindings[2], this is just a msg_send! and from what I can tell is getting an autoreleased reference, not a retained one.
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. However, I'm not seeing a binding to it in the objc crate[3]. Sounds like maybe I should file an issue?
[1]: https://developer.apple.com/documentation/metal/mtlcommandbu...
[2]: https://github.com/gfx-rs/metal-rs/blob/master/src/commandbu...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
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++.
github mirror: https://github.com/bkaradzic/metal-cpp
i'm planning to use this to rewrite the metal backend of my rhi abstraction.
-
-
For OpenCL on DX12, the test suite doesn't pass yet. Every Khronos OpenCL 1.2 CTS test passes on at least one hardware driver, but there's none that pass them all. That is why CLon12 isn't submitted to Khronos's compliant products list yet.
The pointer semantics that Vulkan has aren't very amenable to implementing a compliant OpenCL implementation on top of. There are also some other limitatons: https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu....
-
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.
They would because it would mean more software support.
Proper support for Vulkan would not be an abstraction layer. Metal is not the language of the hardware, GPUs operate on assembly like instructions.
> Supporting it in MacOS would mean just having a team working for Khronos, implementing Vulkan on top of MacOS's actual graphics API, Metal, and releasing when they could.
This is like saying because Mac and Safari support HTML 5 its like they have a team working for W3C. Khronos group is a standards organization not generally the implementer.
> Not sure who that would be because there doesn't seem to be a good enough reason for any group to do it.
https://github.com/KhronosGroup/MoltenVK
> GPU makers, even at the best of times, have never been interested, and, of course, they can look forward to zero Mac business in the near future, so that isn't going to change.
GPU makers are plenty interested as that is who implements Vulkan on Windows. Back when Nvidia worked on Mac OS they implemented CUDA and OpenGL on Mac.
