And OpenCL too. This is terrible. I was thinking about adding GPU support to a numerical simulator I am working on, and I was planning to have nice cross-platform support with OpenCL. Whelp, that's no longer the case. My code is in C++, and I refuse to use proprietary, vendor-locked, Objective-C-only Metal. If people want GPU support, they'll just have to use Linux, which doesn't artificially constrain you with corporate frameworks.
Apple lost interest in OpenCL after learning Khronos wasn't steering it into the direction they wanted it to go.
For example, Metal compute shaders are C++14 and Khronos only adopted C++ in OpenCL after the beating they took from CUDA, which supported it since the beginning.
>My code is in C++, and I refuse to use proprietary, vendor-locked, Objective-C-only Metal. If people want GPU support, they'll just have to use Linux, which doesn't artificially constrain you with corporate frameworks.
Well, some people refuse to use non-platform-native lowest-common-denominator libs, so there's that too...
one possibility for cross platform gpu is webgpu. the people working on it seem to be planning to have a c or c++ level standalone library. behind the scenes it will be directx/metal/vulkan
Apple/Google/Microsoft/Mozilla and others are all participating
Does this imply Apple is planning to continue support for OpenGL informally/externally, the way that X Window support is through xQuartz, perhaps via an external Mesa-based library?
And maybe the same informal/external support model for OpenCL?
Performance will be diminished but not extinguished.
FWIW, they've only deprecated it, meaning no new updates. They haven't removed it from the platform. Furthermore, desktop OpenGL seems like it's dead anyway, given that Vulkan has replaced it.
People just getting into a field like to run code on their personal machines. This can be quite relevant when your code gets a 50X speedup from running on GPU.
This is sort of like saying "people only do web serving workloads on Linux, we don't need web servers to run on Apple machines" to me.
Not necessarily. Many media editing apps use OpenCL to speed up processing. I know Capture One uses OpenCL, and I think Adobe's Lightroom and Photoshop use it also. At this point even Pixelmator and less well known alternatives use OpenCL, too.
Sadly, most companies won't have any choice but to port their app to Apple's proprietary APIs. It's really a net loss for consumers because most of these devs have better things to spend their time on than Apple breaking compatibility on a whim.
I mean, if you're already running decent code or already have extremely good tooling where small examples can be easily sent to other machines. Additionally, debugging code running on other machines is also a huge pain in the ass vs. being able to step through it directly, locally.
Almost all of my (and my lab's) time is spent tinkering with small numerical examples before sending it off to one of the lab machines to run overnight, and using the GPU on the MBP through OpenCL is a huge advantage.
This is just quibbling, but 1) you can write Metal code with Swift as well as Objective-C (and that's not even vendor-locked; I'm doing Swift in Linux right now), and 2) you can write C++ in Objective-C.
I know this isn't what you're really complaining about, though.
The most common pattern I've seen with cross-platform stuff is a small Objective-C wrapper over MacOS APIs, which then gets called like C functions from pure C++ code.
Somehow this is directly related to the failure of desktop Linux.
The only successful variants of it, actually do constrain devs with either Web or Java corporate frameworks, with a very tiny subset of native code allowed to take part into the whole game.
