16 ms·

Low overhead C++ interface for Apple's Metal API

172 points by oumua_don17 5y ago

VHRanger 5y ago
I really think the future here is in MoltenVK becoming the default cross platform GPU API
- gjsman-1000 5y ago
  For everyone mad about Metal, remember: A. Metal came 2 years before Vulkan. B. Microsoft does their own proprietary API with DirectX. C. Metal is a high-level language, Vulkan is low-level. Apple wants you to use a high-level language so they have more flexibility in optimizing the low-level for you now and in the future, which Vulkan closes off more. D. Metal runs on iOS, iPadOS, and tvOS as well, not just macOS. It's a graphics API for all Apple platforms. E. Because of D, talent for Metal is much more likely to be found with mobile game developers than AAA studios. F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat.
  - bogwog 5y ago
    I'm less mad about Metal existing, and more mad about Apple deprecating/abandoning OpenGL. There was no good reason for that, especially for a company with their resources.
    - fwsgonzo 5y ago
      I agree. It's the worst decision so far that they've done. OpenGL may not be perfect, but it worked well everywhere. And what about all the thousands of programs that uses OpenGL? Even future programs may use OpenGL - it is not a legacy API.
      - pjmlp 5y ago
        Everywhere not really, given the lack of support for proper OpenGL on game consoles.
      - dvt 5y ago
        To be fair, I think just about everyone that has done any OpenGL programming absolutely hates it. It uses ancient paradigms that are confusing for neophytes and completely out of sync with modern programming practices. It's also essentially impossible to do multithreaded rendering.
      - daniel-thompson 5y ago
        > It's the worst decision so far that they've done. OpenGL may not be perfect, but it worked well everywhere. I agree with your sentiment. I like OpenGL quite a bit due to its ubiquity. From my perspective as a casual graphics dev, it's relatively easy to use OpenGL to get triangles on the screen, compared to Vulkan (although I know Vulkan has other benefits). > And what about all the thousands of programs that uses OpenGL? Judging on past behavior - Apple isn't shy about breaking compatibility with techs they're no longer interested in.
      - mrpippy 5y ago
        It may be deprecated, but there’s no sign that support will be removed from macOS (since lots of apps and games still use it). If they wanted to, the Apple Silicon transition would have been the time to remove it, but that didn’t happen. On Apple Silicon it’s enabled by an OpenGL->Metal translation layer.
        Klonoar 5y ago
        Where is this OpenGL->Metal translation layer documented? I've seen numerous mentions of it but no actual docs state it clearly. I believe it to be true, based on my own checking, but I'd love to have a link to point people to as this has come up a few times.
        adamnemecek 5y ago
        It’s not going to be documented.
        mrpippy 5y ago
        It’s not documented anywhere. OpenGL just works like it does on any other Mac, and you won’t notice it unless you find bugs in it (Wine has some oddball OpenGL checks that trigger a Metal assertion on Big Sur)
        Klonoar 5y ago
        Right, but my question is: do those checks only assert on Big Sur on M1, or is the mapping later from OpenGL -> Metal just Big Sur/Monterey regardless of platform? Just seems a bit odd to me they'd only do this on one architecture.
        babypuncher 5y ago
        I say this as an avid user of Apple hardware; I have no faith that they will really keep it around forever. They have shown very little willingness to maintain backwards compatibility with software for an extended period of time. Many games released for macOS less than a decade ago simply no longer function. Meanwhile, the Windows PC I built just a few years ago still runs software and games from 25 years ago. This is why I mostly refuse to buy games for my Apple hardware. Until Apple makes some serious commitments (and shows evidence of following through with them), I will not view my MacBook as a viable gaming device. Right now, I'm not even convinced Rosetta 2 will last more than 6 or 7 years.
    - gjsman-1000 5y ago
      OpenGL is a little weird. Windows, for example, does not actually support OpenGL IIRC. It's just that Intel, AMD, and NVIDIA started including OpenGL drivers in their graphics drivers even though Microsoft still does not lift a finger to support OpenGL. [EDIT: Actually, they do, with the OpenGL compatibility pack at https://www.microsoft.com/en-us/p/opencl-and-opengl-compatibility-pack/9nqpsl29bfff?activetab=pivot:overviewtab https://www.microsoft.com/en-us/p/opencl-and-opengl-compatib.... It's new for Windows 10, and it only supports up to OpenGL 3.3, suspiciously around the same compatibility level as macOS...] MacOS, well, Apple got into a huge spat with NVIDIA in ~2012. Around the same time, actually, that Apple stopped updating OpenGL (though they wouldn't formally deprecate OpenGL until 2018). Part of me wonders if NVIDIA was writing the OpenGL for Apple, but then OpenGL just got put on the shelf after the spat. The result though is that neither Windows, nor Apple, supports OpenCL past 1.2 or OpenGL past 3.2/3.3. It's the GPU vendors that have been taking us further. [EDIT 2: Correction, macOS supports OpenGL 4.1, Windows tops out at 3.3 without GPU drivers if you have DirectX 12]
      - emersion 5y ago
        Vulkan and OpenGL are provided by drivers, not by the OS. It's a perfectly normal situation, what else _could_ Microsoft do? > OpenGL compatibility pack This is using the Mesa Gallium state tracker with a DirectX backend. It's not meant for vendors with a native OpenGL driver.
        gjsman-1000 5y ago
        Fair enough, but I guess my point is more that, technically speaking, Windows and MacOS are actually identical in their OpenGL and OpenCL support level. The only place this really shows up though in Windows is software rendering - which lacks OpenGL because Windows lacks OpenGL whereas Windows can software-render DirectX AFAIK. Apple didn't allow AMD though to continue updating OpenGL in their MacOS drivers, possibly because (I'm just speculating) they decided to invent Metal to replace OpenGL around the same time as their NVIDIA spat when they stopped updating OpenGL. Metal came out in 2014, the NVIDIA spat + OpenGL abandonment was 2012. Just my suspicion that MacOS's OpenGL is NVIDIA-based.
    - gfxgirl 5y ago
      There's plenty of reasons for it. For one, OpenGL is arguably a crap API. For another, even with billions of dollars resources are scarce. It's extremely hard to find graphics programmers that want to work on drivers vs work on games etc...
  - dhruvdh 5y ago
    Apple has had many years after Vulkan came out to support it alongside Metal or phase out Metal with MoltenVk but we all know that’s not going to happen.
    - jjtheblunt 5y ago
      Why would it happen if Metal is meant to support optimal performance on Apple hardware? I say that bearing in mind we're talking about battery powered hardware, which can not spend any extra cpu cycles on anything, period, without being berated in the press for short battery life compared to some competitor.
      - gjsman-1000 5y ago
        Besides that, remember that if you use Vulkan, you will almost certainly end-up with something that is very optimized for one platform, but won't immediately run well on alternative platforms (see games with their frequent updates for new CPU and GPU architectures). Apple runs Metal on AMD GPUs, Intel iGPUs, and their own in-house Apple GPUs. If you used Metal, you didn't really have to do much optimization to get close-to-the-best-possible performance on all three of these very-different architectures.
      - kcb 5y ago
        Many "native" Mac OS games are using MoltenVK. Obviously a translation layer is already not optimal for performance or efficiency.
    - giantrobot 5y ago
      > Apple has had many years after Vulkan came out to support it alongside Metal Why would they do that? By the time Vulcan came out they had years of engineering effort in Metal.
      - kcb 5y ago
        If Apple supported Vulkan it would pretty quickly be at parity with Linux for gaming. Proton/Wine/DXVK would actually make a new Macbook Pro a viable option for gaming.
  - caslon 5y ago
    "Microsoft does something bad and so anything Apple does that is bad is okay, because Microsoft also does it." I don't see the logic here.
  - vore 5y ago
    Inarguably though Apple not supporting Vulkan is a huge stumbling block for games on macOS -- even if the common engines support it, a lot of game studios who aren't using something off the shelf aren't likely to support a Mac-only target.
  - jms55 5y ago
    > C. Metal is a high-level language, Vulkan is low-level. Apple wants you to use a high-level language so they have more flexibility in optimizing the low-level for you now and in the future, which Vulkan closes off more. The problem is that historically, this is what's lead to tons of issues in games. Drivers make their own "optimizations" resulting in terrible performance for some task on one GPU, and great performance on another. Or instead of performance differences, it's outright bugs. Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them. So games often ship with terrible performance or bugs on various different GPUs. And it's often not the game's fault: are games really supposed to detect your exact GPU model, and change code paths to work around a driver bug? That's crazy. To combat this, GPU drivers often get updates after a game launch that fix the issues with performance/bugs for specific games at the driver level, when it detects that those games are running. So now drivers become a pile of game-specific hacks, making the problem even worse. This is the reason Vulkan is so low level. The goal is to make sure drivers don't get horribly bloated, and games aren't working around driver-specific bugs (they still happen, just hopefully less). And when games want to use specific GPU features for extra performance, instead of drivers trying to magically improve normal operations, they can make a vendor-specific extension providing the new functionality that games can opt into when the feature is detected (e.g., raytracing). That's part of why Vulkan has so many more extensions than OpenGL does. Vulkan may be low level, but it's intended to be so. By foregoing Vulkan support, Apple rejected any attempt at making a higher level API on top of Vulkan that would work on every system. Instead, WebGPU has to try and abstract over Vulkan/Metal/DirectX12 separately, which mostly works, but leads to a whole lot of clunk and longer development time than if Vulkan was the standard everywhere. That's not to say macOS should never have made Metal. But by not adding Vulkan support in addition later on, they're really hurting cross-platform compatibility. Sure, now Apple can optimize their platform to the best of their ability (theoretically). But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS.
    - gjsman-1000 5y ago
      "But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS." I don't know if I had this point edited in when you wrote this, but see point F: "F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat."
  - criddell 5y ago
    Could it make sense for Metal to be ported to other platforms? Vulkan has never clicked for me. I can cut and paste code to get something running but I don't really understand it. When you say Metal is high level, that's very appealing to me. > Metal is a high-level language, Vulkan is low-level. Wikipedia says Metal is low-level. What do you think accounts for the different description?
    - gjsman-1000 5y ago
      Probably differing definitions of "low level," levels being relative to what you are talking about. In terms of making a game it's "low level" but it's still a much "higher level" than Vulkan. An interesting discussion worth reading: https://developer.apple.com/forums/thread/38469 https://developer.apple.com/forums/thread/38469
    - raphlinus 5y ago
      I totally get where you're coming from, Metal is much easier to program than raw Vulkan. I think a Metal-like API over "modern" APIs could be a good thing. There are things like the Vulkan Memory Allocator that help, but among other things that makes integration of different modules harder; this is especially nice on Metal because you can just allocate your own stuff off MTLDevice. That said, there would be challenges, and big ones, the more you tried to make it actually Metal compatible. You'd need a C++ compiler for the shaders, and certain idioms (pointers, scalar types other than 32 bits) would be difficult to translate portably. And as adamnemecek points out, the role of a friendly cross-platform GPU layer is largely being occupied by WebGPU (wgpu in particular in Rust-land). That'll be very comfortable for people used to Metal, as there's been lots of input from Apple folks. However, WGSL is much lower level than Metal Shading Language, and there are lots of important capabilities (subgroups, etc) missing that Metal and other advanced (>DX11) APIs can do.
    - lucian1900 5y ago
      They are both low-level APIs relative to OpenGL. The difference is mostly that Metal doesn't expose GPU vendor details. Metal has sort of been ported to other platforms, WebGPU is almost a subset of it (albeit somewhat higher level). There's even wgpu to use it outside of a browser.
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    G. PlayStation doesn't do Vulkan H. Switch main API is NVN
  - babypuncher 5y ago
    > B. Microsoft does their own proprietary API with DirectX. DX12 may be proprietary and ship only with Windows, but GPU vendors are able to provide OpenGL and Vulkan support through their drivers. As a result, DirectX is an option, not a requirement. Metal is a requirement for 3D acceleration on Apple hardware.
    - DCKing 5y ago
      It's worth noting that all devices that you can buy with Windows on ARM - those running an ARM version of Windows 10/11 on a Qualcomm chip - don't have Vulkan drivers available. Just DirectX - and an OpenGL compatibility pack that runs OpenGL on top of Direct3D 12. Those same GPUs have perfectly functional Vulkan drivers on Android. I don't know what the problem is. Having Vulkan on Windows is more like a courtesy from Nvidia, AMD and Intel that Microsoft hasn't really blocked [1]. But it can't truly be relied on on Windows - other GPU vendors don't need to build it [2]. Presumably with that excuse, Microsoft has not allowed apps on the Windows Store that targeted a 3D API other than Direct3D - that stuff just would not work on Qualcomm devices and presumably other devices as well. [1]: If they were committed to being assholes about it they could force change as part of the WHQL problem, but it doesn't look like they are that committed. I'm not sure what they are committed to though. [2]: I.e. what if we get Windows laptops with Mediatek chips, or Microsoft and/or Apple revive some Bootcamp mechanism for Windows on Apple Silicon?
      - gjsman-1000 5y ago
        Like you said - Microsoft is just completely passive regarding Vulkan on Windows. It's up to the GPU vendors and driver makers, as long as DirectX isn't threatened. And on Xbox, DirectX is your only option, so if you want a nice clean Windows to/from Xbox port, writing for DirectX just makes sense. As for #2, Qualcomm (according to new reports) has an exclusivity deal for Windows on ARM that is expiring soon. But Microsoft would have to work with Apple and allow drivers to be written for the M1. Craig Federighi of Apple said they would be fine with Windows on M1 but Microsoft wasn't at the time. Though, to be honest, even if the exclusivity deal expires, I don't see Microsoft being excited about Windows on the M1. It only serves to embarrass their own products.
  - smoldesu 5y ago
    How is any of this an excuse for them not to also offer support for Vulkan? If Metal is so great and offers that many advantages, then developers would choose it. Unless Metal can't stand on it's own merits, I don't see a problem here.
  - ninepoints 5y ago
    > F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat. With much pain. Have you seen the shader pipeline we have to deal with going from HLSL to Metal? And no, translating the entire body of shader work to MSL is not an option.
    - skohan 5y ago
      What's the pain point here? Can't you go HLSL -> SPIR-V -> MSL with SPIR-V Cross?
      - ninepoints 5y ago
        Yes... do you know how long this takes for, say, a modest 100k shaders?
  - kcb 5y ago
    Ok so where is the reason Apple can't add Vulkan support to Mac OS?
    - jmull 5y ago
      I don't understand why they would. They don't control the API - not what is in it, the direction it is going, nor when it is updated. That means they can't integrate it tightly with their OSs. Not from a tech standpoint and not from a release standpoint. 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. It would seem much better if some other group -- one with an actual stake or interest in it -- would take this on. Not sure who that would be because there doesn't seem to be a good enough reason for any group to do it. Most game engines probably want to go directly on top of Metal -- they already provide an abstraction layer and probably don't want to have an intermediate one. 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. Not sure who else there possibly is.
      - kcb 5y ago
        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. These are not publicly documented or AFAIK exposed on Mac OS so only Apple would be capable of creating a proper Vulkan driver. > They don't control the API - not what is in it, the direction it is going, nor when it is updated. That means they can't integrate it tightly with their OSs. Not from a tech standpoint and not from a release standpoint. What if I told you I can transfer a file between my Mac and PC using software built into Mac OS from a standard controlled by Microsoft. > 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 the dev team is 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 https://github.com/KhronosGroup/MoltenVK Plenty of "native" Mac games can't be bothered to utilize Metal directly and just use this instead. This generally results in less than optimal performance or efficiency. > 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 because it sells GPUs and it is exactly how its done on Windows. Back when Nvidia worked on Mac OS they implemented CUDA and OpenGL on Mac.
  - jayd16 5y ago
    >F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat. Unity has a Metal target, but its not like you can just ignore it exists after you enable it. I'd much rather write to a single API than many targets, even if Unity makes it possible to do so.
    - rahkiin 5y ago
      You cannot ‘just’ target Vulkan and then assume it works everywhere any Vulkan is supported. There are differences between vulkan implementations and like OpenGL it has a lot og optional parts. Some vulkan code can work on an Amd card but throw validation errors on an nvidia card And vulkan does not support some methods that e.g. metal has natively (and vice versa of course)
- nice_byte 5y ago
  not likely. the more likely scenario is webGPU becoming one, and i'm mad about it because they couldn't use spir-v for shaders, for legal reasons.
  - 1_player 5y ago
    Legal reasons? I read that Apple pushed against SPIR-V in webGPU because they use something else in Metal. I might be mistaken.
    - nice_byte 5y ago
      there is some sort of legal dispute between apple and khronos resulting in apple not really wanting to touch khronos ip. on a technical level, translating spir-v to msl is a solved problem.
- boardwaalk 5y ago
  Vulkan becoming the default cross platform GPU API, while using MoltenVK on Apple operating systems, may be a more accurate way of saying this.
- adamnemecek 5y ago
  There's also WebGPU. wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) is really nice.
  - skohan 5y ago
    WebGPU is a different animal from Vulkan/Metal. It's more like an updated OpenGL than a true low-level graphics API. It's also pretty far from being ready for prime-time if I understand correctly.
    - adamnemecek 5y ago
      The API is essentially metal.
      - ksec 5y ago
        ( LOL two people reading the same 5 days old thread and replying around the same time. ) I assume you mean Mini-Metal? Pretty sure WebGPU has a much smaller surface than Metal. But do correct me if I am wrong.
  - mschuetz 5y ago
    WebGPU is essentially a mobile-phone graphics API, as it focuses support towards the lowest common denominator (both in hardware, and the underlying graphics APIs). Similarly to WebGL before, it will always be half a decade to decade behind desktop graphics. The API itself is great, but the artificially imposed limitations are really really restrictive.
- deleted 5y ago
  [deleted]
blovescoffee 5y ago
Will this help to get pytorch targetting metal?
posharma 5y ago
What about binary compatibility?
- jcelerier 5y ago
  the world is a much better place without it
- pjscott 5y ago
  This library is header-only, and should have the same binary compatibility as using the Objective C framework directly.
comex 5y ago
Interesting; I was wondering if they had added some magic feature to Clang to enable Objective-C in pure C++ mode, but no, it really is C++. It just directly calls the Objective-C runtime functions like sel_registerName, objc_lookUpClass, objc_msgSend, etc. The expensive lookups like sel_registerName are performed in initializers of global variables, whereas for 'real' Objective-C code the dynamic linker does essentially the same job itself. I believe this has the disadvantage that unused selectors can't be fully optimized out, as C++ doesn't allow removing global initializers even if the global in question is unused. Therefore, any program that includes this library will, at initialization time, look up all ~1100 selectors defined in the library, regardless of which ones the program actually uses. But besides that, this approach may have equal performance to native Objective-C. Also - throwing a zip file over the fence, really? Can't you put it on GitHub?
- waynecochran 5y ago
  Objective-C++ is already supported so this is not a big step to bridge from C++ to Objective-C.
- raphlinus 5y ago
  Along similar lines, from my skim of the README, it also seems like deallocated things are not actually released until the return from the nearest autorelease block, which is not exactly convenient for Rust (and it's not properly safe either without at least an extra retain). I always imagined that when you call through Swift it's a more native memory management interface, but perhaps it's also the same Obj-C layer under the hood.
  - ash_gti 5y ago
    The c++ wrappings break ARC, so if you use this library you'll have to manually retain/release any object. The autorelease pool is helpful if you autorelease an object but you'll need to manually manage the memory when using this set of helpers. In obj-c or swift, ARC would handle that for you, so this makes the memory management aspect of using Metal a bit more of a headache.
nice_byte 5y ago
github mirror: https://github.com/bkaradzic/metal-cpp https://github.com/bkaradzic/metal-cpp i'm planning to use this to rewrite the metal backend of my rhi abstraction.
CyberRabbi 5y ago
Soon: low overhead C++ interface for all of UIKit and Foundation.
- Klonoar 5y ago
  Potentially the smartest way to start phasing out Objective-C. I'd be down, even though I still love ObjC.
- checker659 5y ago
  And AppKit!! Don't forget AppKit!
- dgellow 5y ago
  That would be awesome!
jokoon 5y ago
yeah I guess most devs would rather use C++ than objective c.
vimy 5y ago
Everyone here seems focused on Metal as a graphics api for games. It’s also Apple’s answer to CUDA. Still a work in progress but each release they’re adding more (advanced) compute APIs. Metal is important for their AI plans. For that reason alone we will never see it be replaced by Vulkan.
- mangix 5y ago
  Vulkan has VulkanCompute.
- skohan 5y ago
  I think the challenge here is that you need buy-in from industry pros to make this really worth it. The platform can be best-in-class from a hardware/API perspective, but if no tools exist using in it, why am I going to give up my CUDA-based workflow to spend way more effort re-inventing the wheel on mac? I could imagine an open platform supplanting CUDA in the long term from a cost-optimization angle, especially on server workloads, but I just don't see serious work moving from one closed platform to a smaller closed platform.
flying_sheep 5y ago
I paid ~100 dollars to buy songs in Taiko no Tatsujin in iOS 4 via In-App Purchase. But around 2 years later they axed the game and I have no way to download it again. First I can still recover it via iTunes backup. But later when iOS 7 is published, the backup just couldn't run anymore. It was just gone. I should have owned them if I pay that amount of money :-/ It was a very fun game.
- extrememacaroni 5y ago
  There's people who pay tens of thousands of dollars on Genshin Impact and the game will be removed from the store at some point too and the things they spent money on will be gone. You don't own things from the store :\

172 points by oumua_don17 5y ago

VHRanger 5y ago

I really think the future here is in MoltenVK becoming the default cross platform GPU API

gjsman-1000 5y ago
For everyone mad about Metal, remember: A. Metal came 2 years before Vulkan. B. Microsoft does their own proprietary API with DirectX. C. Metal is a high-level language, Vulkan is low-level. Apple wants you to use a high-level language so they have more flexibility in optimizing the low-level for you now and in the future, which Vulkan closes off more. D. Metal runs on iOS, iPadOS, and tvOS as well, not just macOS. It's a graphics API for all Apple platforms. E. Because of D, talent for Metal is much more likely to be found with mobile game developers than AAA studios. F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat.
- bogwog 5y ago
  I'm less mad about Metal existing, and more mad about Apple deprecating/abandoning OpenGL. There was no good reason for that, especially for a company with their resources.
  - fwsgonzo 5y ago
    I agree. It's the worst decision so far that they've done. OpenGL may not be perfect, but it worked well everywhere. And what about all the thousands of programs that uses OpenGL? Even future programs may use OpenGL - it is not a legacy API.
    - pjmlp 5y ago
      Everywhere not really, given the lack of support for proper OpenGL on game consoles.
    - dvt 5y ago
      To be fair, I think just about everyone that has done any OpenGL programming absolutely hates it. It uses ancient paradigms that are confusing for neophytes and completely out of sync with modern programming practices. It's also essentially impossible to do multithreaded rendering.
    - daniel-thompson 5y ago
      > It's the worst decision so far that they've done. OpenGL may not be perfect, but it worked well everywhere. I agree with your sentiment. I like OpenGL quite a bit due to its ubiquity. From my perspective as a casual graphics dev, it's relatively easy to use OpenGL to get triangles on the screen, compared to Vulkan (although I know Vulkan has other benefits). > And what about all the thousands of programs that uses OpenGL? Judging on past behavior - Apple isn't shy about breaking compatibility with techs they're no longer interested in.
    - mrpippy 5y ago
      It may be deprecated, but there’s no sign that support will be removed from macOS (since lots of apps and games still use it). If they wanted to, the Apple Silicon transition would have been the time to remove it, but that didn’t happen. On Apple Silicon it’s enabled by an OpenGL->Metal translation layer.
      - Klonoar 5y ago
        Where is this OpenGL->Metal translation layer documented? I've seen numerous mentions of it but no actual docs state it clearly. I believe it to be true, based on my own checking, but I'd love to have a link to point people to as this has come up a few times.
        adamnemecek 5y ago
        It’s not going to be documented.
        mrpippy 5y ago
        It’s not documented anywhere. OpenGL just works like it does on any other Mac, and you won’t notice it unless you find bugs in it (Wine has some oddball OpenGL checks that trigger a Metal assertion on Big Sur)
        Klonoar 5y ago
        Right, but my question is: do those checks only assert on Big Sur on M1, or is the mapping later from OpenGL -> Metal just Big Sur/Monterey regardless of platform? Just seems a bit odd to me they'd only do this on one architecture.
      - babypuncher 5y ago
        I say this as an avid user of Apple hardware; I have no faith that they will really keep it around forever. They have shown very little willingness to maintain backwards compatibility with software for an extended period of time. Many games released for macOS less than a decade ago simply no longer function. Meanwhile, the Windows PC I built just a few years ago still runs software and games from 25 years ago. This is why I mostly refuse to buy games for my Apple hardware. Until Apple makes some serious commitments (and shows evidence of following through with them), I will not view my MacBook as a viable gaming device. Right now, I'm not even convinced Rosetta 2 will last more than 6 or 7 years.
  - gjsman-1000 5y ago
    OpenGL is a little weird. Windows, for example, does not actually support OpenGL IIRC. It's just that Intel, AMD, and NVIDIA started including OpenGL drivers in their graphics drivers even though Microsoft still does not lift a finger to support OpenGL. [EDIT: Actually, they do, with the OpenGL compatibility pack at https://www.microsoft.com/en-us/p/opencl-and-opengl-compatibility-pack/9nqpsl29bfff?activetab=pivot:overviewtab https://www.microsoft.com/en-us/p/opencl-and-opengl-compatib.... It's new for Windows 10, and it only supports up to OpenGL 3.3, suspiciously around the same compatibility level as macOS...] MacOS, well, Apple got into a huge spat with NVIDIA in ~2012. Around the same time, actually, that Apple stopped updating OpenGL (though they wouldn't formally deprecate OpenGL until 2018). Part of me wonders if NVIDIA was writing the OpenGL for Apple, but then OpenGL just got put on the shelf after the spat. The result though is that neither Windows, nor Apple, supports OpenCL past 1.2 or OpenGL past 3.2/3.3. It's the GPU vendors that have been taking us further. [EDIT 2: Correction, macOS supports OpenGL 4.1, Windows tops out at 3.3 without GPU drivers if you have DirectX 12]
    - emersion 5y ago
      Vulkan and OpenGL are provided by drivers, not by the OS. It's a perfectly normal situation, what else _could_ Microsoft do? > OpenGL compatibility pack This is using the Mesa Gallium state tracker with a DirectX backend. It's not meant for vendors with a native OpenGL driver.
      - gjsman-1000 5y ago
        Fair enough, but I guess my point is more that, technically speaking, Windows and MacOS are actually identical in their OpenGL and OpenCL support level. The only place this really shows up though in Windows is software rendering - which lacks OpenGL because Windows lacks OpenGL whereas Windows can software-render DirectX AFAIK. Apple didn't allow AMD though to continue updating OpenGL in their MacOS drivers, possibly because (I'm just speculating) they decided to invent Metal to replace OpenGL around the same time as their NVIDIA spat when they stopped updating OpenGL. Metal came out in 2014, the NVIDIA spat + OpenGL abandonment was 2012. Just my suspicion that MacOS's OpenGL is NVIDIA-based.
  - gfxgirl 5y ago
    There's plenty of reasons for it. For one, OpenGL is arguably a crap API. For another, even with billions of dollars resources are scarce. It's extremely hard to find graphics programmers that want to work on drivers vs work on games etc...
- dhruvdh 5y ago
  Apple has had many years after Vulkan came out to support it alongside Metal or phase out Metal with MoltenVk but we all know that’s not going to happen.
  - jjtheblunt 5y ago
    Why would it happen if Metal is meant to support optimal performance on Apple hardware? I say that bearing in mind we're talking about battery powered hardware, which can not spend any extra cpu cycles on anything, period, without being berated in the press for short battery life compared to some competitor.
    - gjsman-1000 5y ago
      Besides that, remember that if you use Vulkan, you will almost certainly end-up with something that is very optimized for one platform, but won't immediately run well on alternative platforms (see games with their frequent updates for new CPU and GPU architectures). Apple runs Metal on AMD GPUs, Intel iGPUs, and their own in-house Apple GPUs. If you used Metal, you didn't really have to do much optimization to get close-to-the-best-possible performance on all three of these very-different architectures.
    - kcb 5y ago
      Many "native" Mac OS games are using MoltenVK. Obviously a translation layer is already not optimal for performance or efficiency.
  - giantrobot 5y ago
    > Apple has had many years after Vulkan came out to support it alongside Metal Why would they do that? By the time Vulcan came out they had years of engineering effort in Metal.
    - kcb 5y ago
      If Apple supported Vulkan it would pretty quickly be at parity with Linux for gaming. Proton/Wine/DXVK would actually make a new Macbook Pro a viable option for gaming.
- caslon 5y ago
  "Microsoft does something bad and so anything Apple does that is bad is okay, because Microsoft also does it." I don't see the logic here.
- vore 5y ago
  Inarguably though Apple not supporting Vulkan is a huge stumbling block for games on macOS -- even if the common engines support it, a lot of game studios who aren't using something off the shelf aren't likely to support a Mac-only target.
- jms55 5y ago
  > C. Metal is a high-level language, Vulkan is low-level. Apple wants you to use a high-level language so they have more flexibility in optimizing the low-level for you now and in the future, which Vulkan closes off more. The problem is that historically, this is what's lead to tons of issues in games. Drivers make their own "optimizations" resulting in terrible performance for some task on one GPU, and great performance on another. Or instead of performance differences, it's outright bugs. Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them. So games often ship with terrible performance or bugs on various different GPUs. And it's often not the game's fault: are games really supposed to detect your exact GPU model, and change code paths to work around a driver bug? That's crazy. To combat this, GPU drivers often get updates after a game launch that fix the issues with performance/bugs for specific games at the driver level, when it detects that those games are running. So now drivers become a pile of game-specific hacks, making the problem even worse. This is the reason Vulkan is so low level. The goal is to make sure drivers don't get horribly bloated, and games aren't working around driver-specific bugs (they still happen, just hopefully less). And when games want to use specific GPU features for extra performance, instead of drivers trying to magically improve normal operations, they can make a vendor-specific extension providing the new functionality that games can opt into when the feature is detected (e.g., raytracing). That's part of why Vulkan has so many more extensions than OpenGL does. Vulkan may be low level, but it's intended to be so. By foregoing Vulkan support, Apple rejected any attempt at making a higher level API on top of Vulkan that would work on every system. Instead, WebGPU has to try and abstract over Vulkan/Metal/DirectX12 separately, which mostly works, but leads to a whole lot of clunk and longer development time than if Vulkan was the standard everywhere. That's not to say macOS should never have made Metal. But by not adding Vulkan support in addition later on, they're really hurting cross-platform compatibility. Sure, now Apple can optimize their platform to the best of their ability (theoretically). But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS.
  - gjsman-1000 5y ago
    "But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS." I don't know if I had this point edited in when you wrote this, but see point F: "F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat."
- criddell 5y ago
  Could it make sense for Metal to be ported to other platforms? Vulkan has never clicked for me. I can cut and paste code to get something running but I don't really understand it. When you say Metal is high level, that's very appealing to me. > Metal is a high-level language, Vulkan is low-level. Wikipedia says Metal is low-level. What do you think accounts for the different description?
  - gjsman-1000 5y ago
    Probably differing definitions of "low level," levels being relative to what you are talking about. In terms of making a game it's "low level" but it's still a much "higher level" than Vulkan. An interesting discussion worth reading: https://developer.apple.com/forums/thread/38469 https://developer.apple.com/forums/thread/38469
  - raphlinus 5y ago
    I totally get where you're coming from, Metal is much easier to program than raw Vulkan. I think a Metal-like API over "modern" APIs could be a good thing. There are things like the Vulkan Memory Allocator that help, but among other things that makes integration of different modules harder; this is especially nice on Metal because you can just allocate your own stuff off MTLDevice. That said, there would be challenges, and big ones, the more you tried to make it actually Metal compatible. You'd need a C++ compiler for the shaders, and certain idioms (pointers, scalar types other than 32 bits) would be difficult to translate portably. And as adamnemecek points out, the role of a friendly cross-platform GPU layer is largely being occupied by WebGPU (wgpu in particular in Rust-land). That'll be very comfortable for people used to Metal, as there's been lots of input from Apple folks. However, WGSL is much lower level than Metal Shading Language, and there are lots of important capabilities (subgroups, etc) missing that Metal and other advanced (>DX11) APIs can do.
  - lucian1900 5y ago
    They are both low-level APIs relative to OpenGL. The difference is mostly that Metal doesn't expose GPU vendor details. Metal has sort of been ported to other platforms, WebGPU is almost a subset of it (albeit somewhat higher level). There's even wgpu to use it outside of a browser.
- deleted 5y ago
  [deleted]
- pjmlp 5y ago
  G. PlayStation doesn't do Vulkan H. Switch main API is NVN
- babypuncher 5y ago
  > B. Microsoft does their own proprietary API with DirectX. DX12 may be proprietary and ship only with Windows, but GPU vendors are able to provide OpenGL and Vulkan support through their drivers. As a result, DirectX is an option, not a requirement. Metal is a requirement for 3D acceleration on Apple hardware.
  - DCKing 5y ago
    It's worth noting that all devices that you can buy with Windows on ARM - those running an ARM version of Windows 10/11 on a Qualcomm chip - don't have Vulkan drivers available. Just DirectX - and an OpenGL compatibility pack that runs OpenGL on top of Direct3D 12. Those same GPUs have perfectly functional Vulkan drivers on Android. I don't know what the problem is. Having Vulkan on Windows is more like a courtesy from Nvidia, AMD and Intel that Microsoft hasn't really blocked [1]. But it can't truly be relied on on Windows - other GPU vendors don't need to build it [2]. Presumably with that excuse, Microsoft has not allowed apps on the Windows Store that targeted a 3D API other than Direct3D - that stuff just would not work on Qualcomm devices and presumably other devices as well. [1]: If they were committed to being assholes about it they could force change as part of the WHQL problem, but it doesn't look like they are that committed. I'm not sure what they are committed to though. [2]: I.e. what if we get Windows laptops with Mediatek chips, or Microsoft and/or Apple revive some Bootcamp mechanism for Windows on Apple Silicon?
    - gjsman-1000 5y ago
      Like you said - Microsoft is just completely passive regarding Vulkan on Windows. It's up to the GPU vendors and driver makers, as long as DirectX isn't threatened. And on Xbox, DirectX is your only option, so if you want a nice clean Windows to/from Xbox port, writing for DirectX just makes sense. As for #2, Qualcomm (according to new reports) has an exclusivity deal for Windows on ARM that is expiring soon. But Microsoft would have to work with Apple and allow drivers to be written for the M1. Craig Federighi of Apple said they would be fine with Windows on M1 but Microsoft wasn't at the time. Though, to be honest, even if the exclusivity deal expires, I don't see Microsoft being excited about Windows on the M1. It only serves to embarrass their own products.
- smoldesu 5y ago
  How is any of this an excuse for them not to also offer support for Vulkan? If Metal is so great and offers that many advantages, then developers would choose it. Unless Metal can't stand on it's own merits, I don't see a problem here.
- ninepoints 5y ago
  > F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat. With much pain. Have you seen the shader pipeline we have to deal with going from HLSL to Metal? And no, translating the entire body of shader work to MSL is not an option.
  - skohan 5y ago
    What's the pain point here? Can't you go HLSL -> SPIR-V -> MSL with SPIR-V Cross?
    - ninepoints 5y ago
      Yes... do you know how long this takes for, say, a modest 100k shaders?
- kcb 5y ago
  Ok so where is the reason Apple can't add Vulkan support to Mac OS?
  - jmull 5y ago
    I don't understand why they would. They don't control the API - not what is in it, the direction it is going, nor when it is updated. That means they can't integrate it tightly with their OSs. Not from a tech standpoint and not from a release standpoint. 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. It would seem much better if some other group -- one with an actual stake or interest in it -- would take this on. Not sure who that would be because there doesn't seem to be a good enough reason for any group to do it. Most game engines probably want to go directly on top of Metal -- they already provide an abstraction layer and probably don't want to have an intermediate one. 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. Not sure who else there possibly is.
    - kcb 5y ago
      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. These are not publicly documented or AFAIK exposed on Mac OS so only Apple would be capable of creating a proper Vulkan driver. > They don't control the API - not what is in it, the direction it is going, nor when it is updated. That means they can't integrate it tightly with their OSs. Not from a tech standpoint and not from a release standpoint. What if I told you I can transfer a file between my Mac and PC using software built into Mac OS from a standard controlled by Microsoft. > 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 the dev team is 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 https://github.com/KhronosGroup/MoltenVK Plenty of "native" Mac games can't be bothered to utilize Metal directly and just use this instead. This generally results in less than optimal performance or efficiency. > 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 because it sells GPUs and it is exactly how its done on Windows. Back when Nvidia worked on Mac OS they implemented CUDA and OpenGL on Mac.
- jayd16 5y ago
  >F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat. Unity has a Metal target, but its not like you can just ignore it exists after you enable it. I'd much rather write to a single API than many targets, even if Unity makes it possible to do so.
  - rahkiin 5y ago
    You cannot ‘just’ target Vulkan and then assume it works everywhere any Vulkan is supported. There are differences between vulkan implementations and like OpenGL it has a lot og optional parts. Some vulkan code can work on an Amd card but throw validation errors on an nvidia card And vulkan does not support some methods that e.g. metal has natively (and vice versa of course)
nice_byte 5y ago
not likely. the more likely scenario is webGPU becoming one, and i'm mad about it because they couldn't use spir-v for shaders, for legal reasons.
- 1_player 5y ago
  Legal reasons? I read that Apple pushed against SPIR-V in webGPU because they use something else in Metal. I might be mistaken.
  - nice_byte 5y ago
    there is some sort of legal dispute between apple and khronos resulting in apple not really wanting to touch khronos ip. on a technical level, translating spir-v to msl is a solved problem.
boardwaalk 5y ago
Vulkan becoming the default cross platform GPU API, while using MoltenVK on Apple operating systems, may be a more accurate way of saying this.
adamnemecek 5y ago
There's also WebGPU. wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) is really nice.
- skohan 5y ago
  WebGPU is a different animal from Vulkan/Metal. It's more like an updated OpenGL than a true low-level graphics API. It's also pretty far from being ready for prime-time if I understand correctly.
  - adamnemecek 5y ago
    The API is essentially metal.
    - ksec 5y ago
      ( LOL two people reading the same 5 days old thread and replying around the same time. ) I assume you mean Mini-Metal? Pretty sure WebGPU has a much smaller surface than Metal. But do correct me if I am wrong.
- mschuetz 5y ago
  WebGPU is essentially a mobile-phone graphics API, as it focuses support towards the lowest common denominator (both in hardware, and the underlying graphics APIs). Similarly to WebGL before, it will always be half a decade to decade behind desktop graphics. The API itself is great, but the artificially imposed limitations are really really restrictive.
deleted 5y ago
[deleted]

blovescoffee 5y ago

Will this help to get pytorch targetting metal?

posharma 5y ago

What about binary compatibility?

jcelerier 5y ago
the world is a much better place without it
pjscott 5y ago
This library is header-only, and should have the same binary compatibility as using the Objective C framework directly.

comex 5y ago

Interesting; I was wondering if they had added some magic feature to Clang to enable Objective-C in pure C++ mode, but no, it really is C++. It just directly calls the Objective-C runtime functions like sel_registerName, objc_lookUpClass, objc_msgSend, etc. The expensive lookups like sel_registerName are performed in initializers of global variables, whereas for 'real' Objective-C code the dynamic linker does essentially the same job itself. I believe this has the disadvantage that unused selectors can't be fully optimized out, as C++ doesn't allow removing global initializers even if the global in question is unused. Therefore, any program that includes this library will, at initialization time, look up all ~1100 selectors defined in the library, regardless of which ones the program actually uses. But besides that, this approach may have equal performance to native Objective-C. Also - throwing a zip file over the fence, really? Can't you put it on GitHub?

waynecochran 5y ago
Objective-C++ is already supported so this is not a big step to bridge from C++ to Objective-C.
raphlinus 5y ago
Along similar lines, from my skim of the README, it also seems like deallocated things are not actually released until the return from the nearest autorelease block, which is not exactly convenient for Rust (and it's not properly safe either without at least an extra retain). I always imagined that when you call through Swift it's a more native memory management interface, but perhaps it's also the same Obj-C layer under the hood.
- ash_gti 5y ago
  The c++ wrappings break ARC, so if you use this library you'll have to manually retain/release any object. The autorelease pool is helpful if you autorelease an object but you'll need to manually manage the memory when using this set of helpers. In obj-c or swift, ARC would handle that for you, so this makes the memory management aspect of using Metal a bit more of a headache.

nice_byte 5y ago

github mirror: https://github.com/bkaradzic/metal-cpp https://github.com/bkaradzic/metal-cpp i'm planning to use this to rewrite the metal backend of my rhi abstraction.

CyberRabbi 5y ago

Soon: low overhead C++ interface for all of UIKit and Foundation.

Klonoar 5y ago
Potentially the smartest way to start phasing out Objective-C. I'd be down, even though I still love ObjC.
checker659 5y ago
And AppKit!! Don't forget AppKit!
dgellow 5y ago
That would be awesome!

jokoon 5y ago

yeah I guess most devs would rather use C++ than objective c.

vimy 5y ago

Everyone here seems focused on Metal as a graphics api for games. It’s also Apple’s answer to CUDA. Still a work in progress but each release they’re adding more (advanced) compute APIs. Metal is important for their AI plans. For that reason alone we will never see it be replaced by Vulkan.

mangix 5y ago
Vulkan has VulkanCompute.
skohan 5y ago
I think the challenge here is that you need buy-in from industry pros to make this really worth it. The platform can be best-in-class from a hardware/API perspective, but if no tools exist using in it, why am I going to give up my CUDA-based workflow to spend way more effort re-inventing the wheel on mac? I could imagine an open platform supplanting CUDA in the long term from a cost-optimization angle, especially on server workloads, but I just don't see serious work moving from one closed platform to a smaller closed platform.

flying_sheep 5y ago

I paid ~100 dollars to buy songs in Taiko no Tatsujin in iOS 4 via In-App Purchase. But around 2 years later they axed the game and I have no way to download it again. First I can still recover it via iTunes backup. But later when iOS 7 is published, the backup just couldn't run anymore. It was just gone. I should have owned them if I pay that amount of money :-/ It was a very fun game.

extrememacaroni 5y ago
There's people who pay tens of thousands of dollars on Genshin Impact and the game will be removed from the store at some point too and the things they spent money on will be gone. You don't own things from the store :\