6 ms·

I'd really enjoy a detailed writeup on why the graphics industry has been so fragmented. I'm not a graphics programmer myself, but from the outside looking in,

I'd really enjoy a detailed writeup on why the graphics industry has been so fragmented. I'm not a graphics programmer myself, but from the outside looking in, OpenGL looks like it has fallen victim to design-by-committee. If I had to guess, the "big" players want to propose changes to the API which are closely reflect ideal usage of their own hardware. This typically upsets another big player, so the compromise is that both changes get added to OpenGL and the users are caught in the crossfire. I think in an ideal world, Vulkan would have arrived years earlier and became the central standard that succeeded where OpenGL failed. However, Vulkan is the phoenix which arose from the ashes of AMD's Mantle API in the mid 2010s. Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. It seems they've made this gamble with graphics and their structuring their machine learning ecosystem to be quite similar. From a computer architect's point of view, seeing all of this diversity reminds me of the days of the console wars. Architects were willing to make crazy (at the time) design choices with their system architecture and developers were expected to learn how to leverage it to the best of their ability. Hopefully someone with more experience than I can comment on whether these educated guesses amount to anything.

saagarjha 6y ago
> Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. Note that Metal preceded Vulkan.
- robert_foss 6y ago
  Actually, Vulkan was created by AMD (under the name Mantle) in 2013. Apple surely was aware of this, yet wanted to go their own way.
  - pjmlp 6y ago
    When Mantle was created Vulkan wasn't in sight. Mantle became Vulkan when Khronos realized they weren't going to be able to deliver anything worthwhile using, and AMD gently gave Mantle to Khronos . Metal was already on their way when this decision took place.
  - flohofwoe 6y ago
    IFIR at the time when Metal was released (or at least well into development) it wasn't at all clear what Vulkan would look like or that it would be derived from Mantle. Also Apple didn't exactly go their own way (in the sense of inventing something entirely different). Metal v1 looks a lot like a "next gen D3D11". The only thing that was clear at the time was that the GL programming model had to be abandondend, but better APIs than GL already existed on PC and game consoles to steal good ideas from.
  - kalleboo 6y ago
    Wasn’t Mantle AMD-proprietary? So Apple couldn’t use it anyway, since iOS devices don’t use AMD GPUs
    - masklinn 6y ago
      Yes. AMD announced Mantle late 2013, Apple announced Metal early 2014 with initial release mid-2014, AMD stopped development of Mantle as Khronos announced the Vulkan project in mid-2015 (and the first release of Vulkan was in 2016). AMD was the first out of the gate, but the API style was really in the air at that point e.g. Dx12 was also announced in early 2014 though only released in mid-2015. The high-level OpenGL API style had been getting really long in the tooth by that point, GPUs were diverging more and more from it (requiring more and more complex drivers in order to bridge the divide) and the stateful nature of OGL really hadn't aged well.
  - coldtea 6y ago
    >Apple surely was aware of this, yet wanted to go their own way. First, well, AMD wanted to go their own way (designing their own thing in Mantle), so why not Apple? Second, the year Metal appeared publicly wasn't the year Metal was designed in Apple. It was released in 2014 -- so it could very well preceed Mantle by a lot.
  - unsigner 6y ago
    This has a kernel of truth in it, but only a tiny kernel. Mantle was much, much simpler than what eventually was shipped as Vulkan 1.0. When mobile vendors got onto the bandwagon, it turned into the monstrosity it is today.
  - dmitriid 6y ago
    > Apple surely was aware of this, yet wanted to go their own way. Mantle was a proprietary API promised to work on AMD cards only. The work on it started in 2013. Apple released version 1 of metal in June 2014. So, they'd already spent at least a year working on it. So why would they want to somehow go ahead with something proprietary that AMD was developing at the same time? Khronos groups announced they were going to work on the next generation graphics API in July 2014 (a full month after the release of Metal v1). AMD donated Mantle to Khronos in 2015, a full year after Metal v1. --- There are reasons why Apple went with Metal, and they make a lot of sense: OpenGL was a disaster. Any improvements to it would require immense effort, and fighting against Khronos committees. OpenGL ES was only marginally better and only marginally better suited for mobile devices. So why would not Apple develop their own low-level graphics API for their own devices?
    - Someone 6y ago
      To add some links to this: https://en.wikipedia.org/wiki/Mantle_(API) https://en.wikipedia.org/wiki/Mantle_(API) says (note 1) that AMD announced working with DICE on Mantle end of September 2013. Metal’s first release was in June 2014 (https://en.wikipedia.org/wiki/Metal_(API) https://en.wikipedia.org/wiki/Metal_(API) ) It certainly doesn’t look like AMD started working on a new API long before Apple did.
  - deleted 6y ago
    [deleted]
  - Jasper_ 6y ago
    A team of small engineers inside AMD created Mantle, and AMD management did fuck-all with it; they donated it to Khronos for Vulkan, but some lawyers got involved and patent claims held up the release for a few years (Vulkan being late? That's AMD's fault!) So the team that mostly created Mantle left AMD, got hired by Apple, where they built Mantle 2.0, aka Metal.
pjmlp 6y ago
Besides Metal preceding Vulkan, Vulkan has already turned into the same extension hell as OpenGL. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php
- account42 6y ago
  What is the "hell" here? Just the fact that extensions exist? From where I'm standing the only real problem with extensions in OpenGL is that they are all enabled by default so it's easy to accidentally rely on one that happens to be supported by the hardware/driver you are testing on. This is not the case with Vulkan where you explicitly need to ask for the extensions you want.
  - pjmlp 6y ago
    The fact that the code ends up with so many execution paths, that it is hardly any better than having plugin abstraction rendering layer using the native 3D API for each target platform. And everyone ends up writing their own extension loading framework anyway, because feature X differs on extensions across GPUs and the same high level call should be orthogonal to the loaded extension.
    - Jasper_ 6y ago
      To be clear, pjmlp, I don't think you've ever written a Vulkan app, ever. You don't need an "extension loading framework" on Vulkan (you might be confusing something like volk with that), since the loader is standardized, and a lot of the extensions are for very minor things or IHV moon-shot ideas, or are rolled into the maintenance extension. Vulkan has a lot of faults, but this is such a weird complaint.
      - pjmlp 6y ago
        Since we are pulling credentials here, I have written enough of Metal, OpenGL, OpenGL ES, DirectX (5 - 12), WebGL, XNA, Unit, Java3D, M3G, PHIGS, Glide, Amiga and PC demoscene low level coding, to be able to evaluate Vulkan when going through books like Vulkan Cookbook and NVidia GTC sessions, but yeah, maybe I just don't get it.
auggierose 6y ago
I don't know Vulkan. But from what I've heard, including this blog post, Metal is an easier to use API. I find Metal very easy to use, but still allowing for many very important optimizations. So I am glad Apple made Metal! As for fragmentation ... Yeah, it would be nice if Metal would be supported on Windows and on Android. Not really Apple's fault it isn't.
- FpUser 6y ago
  >"...it would be nice if Metal would be supported on Windows and on Android. Not really Apple's fault it isn't." Is it Microsoft's fault that DX12 is not supported on Apple?
  - auggierose 6y ago
    Not saying it is. Don't know DX12 either. But back when I was programming on Windows I hated its API's, so I would probably not be a big user of DX12 on Mac anyway.
    - auggierose 6y ago
      Anyway. It seems to me that WebGPU will lead to a consolidation of these different technologies in the medium to long term.
      - FpUser 6y ago
        That is assuming that native applications will die and everything moves to a browser. While browser based apps have their ever widening place I do not really see them displacing everything else. And if it happens we will have one giant monoculture. Googles's wet dream. I am not really looking forward to such an outcome.
        auggierose 6y ago
        No, I am not assuming that. Instead I think, once this is a common technology available on the net, it will also become compatible on the desktop as time goes by.
yokaze 6y ago
Not sure, if I am terrible more experienced, but it aligns from what I've heard. But another point I would add to OpenGL: Legacy. Yes, with later versions, there was a way to migrate away from legacies like stippled line, but the very same legacy was used by CAD programs, which did not want to do away with everything and redo everything from scratch, so it had to be dragged along too. OpenGL Drivers had to be very complex. If you reached that point, than it is usually easier to do from scratch and clearly break the legacy use-cases. > Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. Funnily enough, I would say Apple was doing best when they stopped doing that. (Classic MacOS -> Intel, MacOSX, Objective-C, TCP, NFS, USB...)
greggman3 6y ago
why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. Why would we have one GPU API?
- pjc50 6y ago
  We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.
  - coldtea 6y ago
    >We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. And we get the joy of Electron...
  - dindresto 6y ago
    Fortunately, WebGPU is on the horizon to fix this mess. And before someone links the relevant XKCD comic, I'll do it myself: https://xkcd.com/927/ https://xkcd.com/927/
    - pjmlp 6y ago
      Given the adoption rate of WebGL 2.0 (including the issues with blacklisting drivers), the current state of WebGL 2.0 compute, I don't have high hopes for a 3D API where the shading language is yet to be defined.
      - dindresto 6y ago
        Well, (un)fortunately WebGL 2.0 adoption is mainly blocked by Apple. And as Apple is one of the driving forces behind WebGPU, I expect it to be adopted by Safari faster.
dmitriid 6y ago
> I'd really enjoy a detailed writeup on why the graphics industry has been so fragmented. An old comment on SO dives into OpenGL vs Direct3D: https://softwareengineering.stackexchange.com/a/88055 https://softwareengineering.stackexchange.com/a/88055 > Thus, Apple chose to do what Apple does best: eschew common standards When Apple released Metal, OpenGL had already been an unusable mess, and Vulkan had not even begun to be a thing. Vulkan began as a project a month after first version of Metal was released.
- thewebcount 6y ago
  Yeah, and didn't Apple even work with Khronos (and other vendors) to come up with a "next gen OpenGL"? But after literally years of nothing materializing, they just kind of said, "Forget it" and made the API they needed? At least I recall something like that happening. I thought they gave it an honest try but it didn't get any momentum.
fsloth 6y ago
The ecosystem is fragmented for historical reasons. Wikipedia pages of each API explain the historical context of each. The main reasons there has not been a big push to create only one graphics API are: 1. it's hard after the genie of many API:s is out of the bottle (why should i port my code) 2. Surprisingly, the benefits would not be that huge (IMO) - compared to the enormous amount of energy this would take. The graphics data the different API:s consume is more or less the same. Since it's eventually fed to the same hardware. So for an engine a large part of the non-trivial code is actually graphics backend agnostic. All of the API:s basically 1. select whether to draw to onscreen or texture 2. load triangles 3. load shader program which a) modifies vertices of triangles (projection etc) b) computes pixel color for each sample in triangle 4. load variables and textures that are used as input to the shader program 5. draw. The shader code has different languages but all of them are more or less isomorphic. The above is a ELY 5 trivialization, but the gist of it is more or less so. The difficult part actually is managing the state of any complex graphics program, not getting the graphics to the screen. So, first you need to learn a graphics API and think that's hard. Not so! What's actually hard is then figuring out how to make any coherent application around that.
matsemann 6y ago
I think this answer some of your questions about the history of OpenGL and how it became so fragmented: https://softwareengineering.stackexchange.com/a/88055/51669 https://softwareengineering.stackexchange.com/a/88055/51669
GuB-42 6y ago
> OpenGL looks like it has fallen victim to design-by-committee It totally was when OpenGL was controlled by the ARB. ARB stands for "Architecture Review Board", even the name screamed "designed by committee". In the end, you couldn't do much without proprietary extensions, except using Direct3D... After transfer the Khronos Group, it went better. Still a committee, but at least, the spec is not completely out of touch with modern hardware. I don't know about Metal but Vulkan is not a replacement for OpenGL. It is a low level API, made so that engines like Unreal or Unity can have a lot of control and keep overhead to a minimum. However, it is absolutely terrible for small projects. It takes several pages of code to draw your first triangle. According to the article, it looks like Metal is somewhere between OpenGL and Vulkan: lower level than OpenGL and easier to use than Vulkan. It doesn't look like Apple is doing crazy stuff with its hardware, but because they don't need to be portable, they can provide a simpler API compared to Vulkan which need to support all kinds of hardware and platforms. I am not against Metal, however, I hate Apple for deprecating OpenGL. You used to have 3 options 1- Use an engine, and let it deal with all the rendering API stuff. 2- If you have a smallish project and want to do your own engine, use OpenGL. 3- If you are an engine developer, you make it so that it can support the best API for the system you are targeting, it can be Vulkan, Metal, DirectX 12,... and keep OpenGL for compatibility. Now, option 1 is not portable anymore, and for option 3, you don't have a quasi-universal fallback anymore. MoltenGL/MoltenVK may be an option, but that's not ideal.
- pjmlp 6y ago
  Option 1 is as portable as ever, all major engines support all relevant 3D APIs, including Metal. Option 2 was never an option for most consoles (check which ones are listed at Khronos). Option 3, as per option 2 never had much gain on quasi universal API.

saagarjha 6y ago

> Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. Note that Metal preceded Vulkan.

robert_foss 6y ago
Actually, Vulkan was created by AMD (under the name Mantle) in 2013. Apple surely was aware of this, yet wanted to go their own way.
- pjmlp 6y ago
  When Mantle was created Vulkan wasn't in sight. Mantle became Vulkan when Khronos realized they weren't going to be able to deliver anything worthwhile using, and AMD gently gave Mantle to Khronos . Metal was already on their way when this decision took place.
- flohofwoe 6y ago
  IFIR at the time when Metal was released (or at least well into development) it wasn't at all clear what Vulkan would look like or that it would be derived from Mantle. Also Apple didn't exactly go their own way (in the sense of inventing something entirely different). Metal v1 looks a lot like a "next gen D3D11". The only thing that was clear at the time was that the GL programming model had to be abandondend, but better APIs than GL already existed on PC and game consoles to steal good ideas from.
- kalleboo 6y ago
  Wasn’t Mantle AMD-proprietary? So Apple couldn’t use it anyway, since iOS devices don’t use AMD GPUs
  - masklinn 6y ago
    Yes. AMD announced Mantle late 2013, Apple announced Metal early 2014 with initial release mid-2014, AMD stopped development of Mantle as Khronos announced the Vulkan project in mid-2015 (and the first release of Vulkan was in 2016). AMD was the first out of the gate, but the API style was really in the air at that point e.g. Dx12 was also announced in early 2014 though only released in mid-2015. The high-level OpenGL API style had been getting really long in the tooth by that point, GPUs were diverging more and more from it (requiring more and more complex drivers in order to bridge the divide) and the stateful nature of OGL really hadn't aged well.
- coldtea 6y ago
  >Apple surely was aware of this, yet wanted to go their own way. First, well, AMD wanted to go their own way (designing their own thing in Mantle), so why not Apple? Second, the year Metal appeared publicly wasn't the year Metal was designed in Apple. It was released in 2014 -- so it could very well preceed Mantle by a lot.
- unsigner 6y ago
  This has a kernel of truth in it, but only a tiny kernel. Mantle was much, much simpler than what eventually was shipped as Vulkan 1.0. When mobile vendors got onto the bandwagon, it turned into the monstrosity it is today.
- dmitriid 6y ago
  > Apple surely was aware of this, yet wanted to go their own way. Mantle was a proprietary API promised to work on AMD cards only. The work on it started in 2013. Apple released version 1 of metal in June 2014. So, they'd already spent at least a year working on it. So why would they want to somehow go ahead with something proprietary that AMD was developing at the same time? Khronos groups announced they were going to work on the next generation graphics API in July 2014 (a full month after the release of Metal v1). AMD donated Mantle to Khronos in 2015, a full year after Metal v1. --- There are reasons why Apple went with Metal, and they make a lot of sense: OpenGL was a disaster. Any improvements to it would require immense effort, and fighting against Khronos committees. OpenGL ES was only marginally better and only marginally better suited for mobile devices. So why would not Apple develop their own low-level graphics API for their own devices?
  - Someone 6y ago
    To add some links to this: https://en.wikipedia.org/wiki/Mantle_(API) https://en.wikipedia.org/wiki/Mantle_(API) says (note 1) that AMD announced working with DICE on Mantle end of September 2013. Metal’s first release was in June 2014 (https://en.wikipedia.org/wiki/Metal_(API) https://en.wikipedia.org/wiki/Metal_(API) ) It certainly doesn’t look like AMD started working on a new API long before Apple did.
- deleted 6y ago
  [deleted]
- Jasper_ 6y ago
  A team of small engineers inside AMD created Mantle, and AMD management did fuck-all with it; they donated it to Khronos for Vulkan, but some lawyers got involved and patent claims held up the release for a few years (Vulkan being late? That's AMD's fault!) So the team that mostly created Mantle left AMD, got hired by Apple, where they built Mantle 2.0, aka Metal.

pjmlp 6y ago

Besides Metal preceding Vulkan, Vulkan has already turned into the same extension hell as OpenGL. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php

account42 6y ago
What is the "hell" here? Just the fact that extensions exist? From where I'm standing the only real problem with extensions in OpenGL is that they are all enabled by default so it's easy to accidentally rely on one that happens to be supported by the hardware/driver you are testing on. This is not the case with Vulkan where you explicitly need to ask for the extensions you want.
- pjmlp 6y ago
  The fact that the code ends up with so many execution paths, that it is hardly any better than having plugin abstraction rendering layer using the native 3D API for each target platform. And everyone ends up writing their own extension loading framework anyway, because feature X differs on extensions across GPUs and the same high level call should be orthogonal to the loaded extension.
  - Jasper_ 6y ago
    To be clear, pjmlp, I don't think you've ever written a Vulkan app, ever. You don't need an "extension loading framework" on Vulkan (you might be confusing something like volk with that), since the loader is standardized, and a lot of the extensions are for very minor things or IHV moon-shot ideas, or are rolled into the maintenance extension. Vulkan has a lot of faults, but this is such a weird complaint.
    - pjmlp 6y ago
      Since we are pulling credentials here, I have written enough of Metal, OpenGL, OpenGL ES, DirectX (5 - 12), WebGL, XNA, Unit, Java3D, M3G, PHIGS, Glide, Amiga and PC demoscene low level coding, to be able to evaluate Vulkan when going through books like Vulkan Cookbook and NVidia GTC sessions, but yeah, maybe I just don't get it.

auggierose 6y ago

I don't know Vulkan. But from what I've heard, including this blog post, Metal is an easier to use API. I find Metal very easy to use, but still allowing for many very important optimizations. So I am glad Apple made Metal! As for fragmentation ... Yeah, it would be nice if Metal would be supported on Windows and on Android. Not really Apple's fault it isn't.

FpUser 6y ago
>"...it would be nice if Metal would be supported on Windows and on Android. Not really Apple's fault it isn't." Is it Microsoft's fault that DX12 is not supported on Apple?
- auggierose 6y ago
  Not saying it is. Don't know DX12 either. But back when I was programming on Windows I hated its API's, so I would probably not be a big user of DX12 on Mac anyway.
  - auggierose 6y ago
    Anyway. It seems to me that WebGPU will lead to a consolidation of these different technologies in the medium to long term.
    - FpUser 6y ago
      That is assuming that native applications will die and everything moves to a browser. While browser based apps have their ever widening place I do not really see them displacing everything else. And if it happens we will have one giant monoculture. Googles's wet dream. I am not really looking forward to such an outcome.
      - auggierose 6y ago
        No, I am not assuming that. Instead I think, once this is a common technology available on the net, it will also become compatible on the desktop as time goes by.

yokaze 6y ago

Not sure, if I am terrible more experienced, but it aligns from what I've heard. But another point I would add to OpenGL: Legacy. Yes, with later versions, there was a way to migrate away from legacies like stippled line, but the very same legacy was used by CAD programs, which did not want to do away with everything and redo everything from scratch, so it had to be dragged along too. OpenGL Drivers had to be very complex. If you reached that point, than it is usually easier to do from scratch and clearly break the legacy use-cases. > Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. Funnily enough, I would say Apple was doing best when they stopped doing that. (Classic MacOS -> Intel, MacOSX, Objective-C, TCP, NFS, USB...)

greggman3 6y ago

why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. Why would we have one GPU API?

pjc50 6y ago
We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.
- coldtea 6y ago
  >We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences. And we get the joy of Electron...
- dindresto 6y ago
  Fortunately, WebGPU is on the horizon to fix this mess. And before someone links the relevant XKCD comic, I'll do it myself: https://xkcd.com/927/ https://xkcd.com/927/
  - pjmlp 6y ago
    Given the adoption rate of WebGL 2.0 (including the issues with blacklisting drivers), the current state of WebGL 2.0 compute, I don't have high hopes for a 3D API where the shading language is yet to be defined.
    - dindresto 6y ago
      Well, (un)fortunately WebGL 2.0 adoption is mainly blocked by Apple. And as Apple is one of the driving forces behind WebGPU, I expect it to be adopted by Safari faster.

dmitriid 6y ago

> I'd really enjoy a detailed writeup on why the graphics industry has been so fragmented. An old comment on SO dives into OpenGL vs Direct3D: https://softwareengineering.stackexchange.com/a/88055 https://softwareengineering.stackexchange.com/a/88055 > Thus, Apple chose to do what Apple does best: eschew common standards When Apple released Metal, OpenGL had already been an unusable mess, and Vulkan had not even begun to be a thing. Vulkan began as a project a month after first version of Metal was released.

thewebcount 6y ago
Yeah, and didn't Apple even work with Khronos (and other vendors) to come up with a "next gen OpenGL"? But after literally years of nothing materializing, they just kind of said, "Forget it" and made the API they needed? At least I recall something like that happening. I thought they gave it an honest try but it didn't get any momentum.

fsloth 6y ago

The ecosystem is fragmented for historical reasons. Wikipedia pages of each API explain the historical context of each. The main reasons there has not been a big push to create only one graphics API are: 1. it's hard after the genie of many API:s is out of the bottle (why should i port my code) 2. Surprisingly, the benefits would not be that huge (IMO) - compared to the enormous amount of energy this would take. The graphics data the different API:s consume is more or less the same. Since it's eventually fed to the same hardware. So for an engine a large part of the non-trivial code is actually graphics backend agnostic. All of the API:s basically 1. select whether to draw to onscreen or texture 2. load triangles 3. load shader program which a) modifies vertices of triangles (projection etc) b) computes pixel color for each sample in triangle 4. load variables and textures that are used as input to the shader program 5. draw. The shader code has different languages but all of them are more or less isomorphic. The above is a ELY 5 trivialization, but the gist of it is more or less so. The difficult part actually is managing the state of any complex graphics program, not getting the graphics to the screen. So, first you need to learn a graphics API and think that's hard. Not so! What's actually hard is then figuring out how to make any coherent application around that.

matsemann 6y ago

I think this answer some of your questions about the history of OpenGL and how it became so fragmented: https://softwareengineering.stackexchange.com/a/88055/51669 https://softwareengineering.stackexchange.com/a/88055/51669

GuB-42 6y ago

> OpenGL looks like it has fallen victim to design-by-committee It totally was when OpenGL was controlled by the ARB. ARB stands for "Architecture Review Board", even the name screamed "designed by committee". In the end, you couldn't do much without proprietary extensions, except using Direct3D... After transfer the Khronos Group, it went better. Still a committee, but at least, the spec is not completely out of touch with modern hardware. I don't know about Metal but Vulkan is not a replacement for OpenGL. It is a low level API, made so that engines like Unreal or Unity can have a lot of control and keep overhead to a minimum. However, it is absolutely terrible for small projects. It takes several pages of code to draw your first triangle. According to the article, it looks like Metal is somewhere between OpenGL and Vulkan: lower level than OpenGL and easier to use than Vulkan. It doesn't look like Apple is doing crazy stuff with its hardware, but because they don't need to be portable, they can provide a simpler API compared to Vulkan which need to support all kinds of hardware and platforms. I am not against Metal, however, I hate Apple for deprecating OpenGL. You used to have 3 options 1- Use an engine, and let it deal with all the rendering API stuff. 2- If you have a smallish project and want to do your own engine, use OpenGL. 3- If you are an engine developer, you make it so that it can support the best API for the system you are targeting, it can be Vulkan, Metal, DirectX 12,... and keep OpenGL for compatibility. Now, option 1 is not portable anymore, and for option 3, you don't have a quasi-universal fallback anymore. MoltenGL/MoltenVK may be an option, but that's not ideal.

pjmlp 6y ago
Option 1 is as portable as ever, all major engines support all relevant 3D APIs, including Metal. Option 2 was never an option for most consoles (check which ones are listed at Khronos). Option 3, as per option 2 never had much gain on quasi universal API.