5 ms·

It's a political, not a technical issue. MS and Apple are stuck with their lock-in mentality and until they'll change, this fragmented mess will remain in place

by shmerl 5y ago

It's a political, not a technical issue. MS and Apple are stuck with their lock-in mentality and until they'll change, this fragmented mess will remain in place. At least MS joined OpenXR effort in contrast instead of pushing their own NIH. However this did happen for DirectX as an option. There are dxvk (dx9-11) and vkd3d (dx12) which translate DirectX to Vulkan.

klodolph 5y ago
At least DX12 and Metal have similar semantics to Vulkan. It may be a mess to support multiple platforms without using some kind of translation library, abstraction layer, or off-the-shelf rendering engine, but at least you can work with similar semantics on different platforms.
- shmerl 5y ago
  It's still an unnecessary mess driven by lock-in interests. MS and Apple should have collaborated on supporting Vulkan instead and made whatever higher level stuff on top of it already. But you are right, translating DX12 to Vulkan is easier than translating DX9 or DX11 to it.
  - klodolph 5y ago
    Lock-in was the end result, but the project that eventually resulted in Vulkan hadn't even begun by the time Metal was shipping to developers. Metal was released June 2014, and a project called "OpenGL Next" was started the next month, in July 2014. This project was eventually renamed Vulkan, and wasn't available until February 2016. You can say that the lock-in is "unnecessary", but these things happen for complicated reasons. Fixing the lock-in isn't just a switch you can flip. We can dream about a world in which Vulkan came out two years earlier than it did. In the world we live in, Microsoft wanted migration paths for existing DirectX users, and Apple wanted people to take iOS seriously as a platform for developing games. Waiting for OpenGL Next to materialize seemed like a losing game at the time. When Metal and DirectX 12 were under developement, they weren't competing with Vulkan... they were competing with a set of techniques for OpenGL called AZDO, and it seemed that OpenGL was lagging further and further behind its alternatives with every passing year.
    - ben-schaaf 5y ago
      Vulkan is derived from AMD's Mantle API which came out back in 2013.
      - klodolph 5y ago
        Yes, and Mantle is a vendor-specific (AMD only) API which only supported one platform (Windows). There were plans to port it to Linux, but there were never any plans to support other GPUs. That, and Mantle ran on desktop GPUs. Metal was initially targeted at where the gap between API and hardware was the largest, which was mobile GPUs. At least with desktop OpenGL you had the "AZDO" techniques, but on mobile, you had OpenGL ES. Mobile GPUs aren't just smaller versions of desktop GPUs, they use radically different ways of drawing on the screen (although this gap is narrowing, as desktop GPUs are becoming more like mobile GPUs... basically, expect to see tiled rendering on desktops in the future). If you were living in 2013, would you say, "Gee, I hope someone else forms a committee to adapt Mantle into something which, in the future, maybe in 2016, I could theoretically use?" Or is it faster to make your own API? Or perhaps you like working with cross-platform steering committees that were, at the time, falling behind and failing to address problems with their APIs?
        jhasse 5y ago
        I would help the committee.
        klodolph 5y ago
        Yes, and that's what they did. They were on the committee, helping out. Seems a lot of people have kind of rewritten the narrative here. Or maybe people forgot that committees & steering groups sometimes fall apart, slow to a crawl, or deliver standards that either aren't useful to developers or aren't feasible for implementers. You'd be a moron to put all your hopes and dreams in a committee / industry working group delivering something to fix the problems with your platform. Sending more engineers to a committee that's already moving slowly will just slow things down further. So these companies, while sitting on the committee, worked on alternatives and had backup strategies. Those strategies turned into Metal and DirectX 12, and the committee realized, "Oh, if we don't fix the problems with OpenGL, it will become completely irrelevant." So, in response to this new competition, the OpenGL steering committee started working on OpenGL Next, which later became Vulkan, and about two years later, got released. It's amazing what a little competition can do.
- skocznymroczny 5y ago
  DX12 yes. Metal, not so much. Yes, it shares some of the features of low-level, explicit APIs, but it's still a much higher level API than Vulkan/DX12 are. Things like image transitions, memory barriers, synchronization semaphores/fences. In Vulkan/DX12 you need to grasp those to get a triangle on the screen, in Metal not as much.
kitsunesoba 5y ago
I’m not sure about DX12, but my understanding is the Metal was put into production a good deal before there was even a working draft for Vulkan, which makes its existence seem more driven by an immediate need to replace OpenGL ES. I suppose they could’ve dropped Metal right away after Vulkan became usable, but developers tend to get grouchy when APIs change out from under them that frequently. That said there’s no reason they couldn’t support Vulkan alongside Metal, likely with one being a first-party adapter layer for the other.
- shmerl 5y ago
  > developers tend to get grouchy when APIs change out from under them that frequently Apple didn't care about developers when they let OpenGL rot there, so I don't think it was ever a consideration for them. Their idea for developers is "we know better than you what's good for you". > That said there’s no reason they couldn’t support Vulkan alongside Metal Exactly, and the real reason is - they want their API to work as lock-in rather than allow developers to have options.
- user-the-name 5y ago
  Metal is also a far more usable API than Vulkan. Apple wants people to actually be able to implement things with their APIs.
  - shmerl 5y ago
    Nothing (valid) stopped Apple from building such API on top of Vulkan and provide them alongside each other.
    - Cyberdog 5y ago
      You believe that Apple should support two (three, if you count deprecated but still present OpenGL) different graphics APIs?
      - shmerl 5y ago
        They have more than enough resources to support anything. Such as lower level API (Vulkan) for those who need it and higher level one built on top of it for those who need something simpler but more limited. Do you believe Apple are somehow resource strained in not being able to do that many times over?

by shmerl 5y ago

klodolph 5y ago

At least DX12 and Metal have similar semantics to Vulkan. It may be a mess to support multiple platforms without using some kind of translation library, abstraction layer, or off-the-shelf rendering engine, but at least you can work with similar semantics on different platforms.

shmerl 5y ago
It's still an unnecessary mess driven by lock-in interests. MS and Apple should have collaborated on supporting Vulkan instead and made whatever higher level stuff on top of it already. But you are right, translating DX12 to Vulkan is easier than translating DX9 or DX11 to it.
- klodolph 5y ago
  Lock-in was the end result, but the project that eventually resulted in Vulkan hadn't even begun by the time Metal was shipping to developers. Metal was released June 2014, and a project called "OpenGL Next" was started the next month, in July 2014. This project was eventually renamed Vulkan, and wasn't available until February 2016. You can say that the lock-in is "unnecessary", but these things happen for complicated reasons. Fixing the lock-in isn't just a switch you can flip. We can dream about a world in which Vulkan came out two years earlier than it did. In the world we live in, Microsoft wanted migration paths for existing DirectX users, and Apple wanted people to take iOS seriously as a platform for developing games. Waiting for OpenGL Next to materialize seemed like a losing game at the time. When Metal and DirectX 12 were under developement, they weren't competing with Vulkan... they were competing with a set of techniques for OpenGL called AZDO, and it seemed that OpenGL was lagging further and further behind its alternatives with every passing year.
  - ben-schaaf 5y ago
    Vulkan is derived from AMD's Mantle API which came out back in 2013.
    - klodolph 5y ago
      Yes, and Mantle is a vendor-specific (AMD only) API which only supported one platform (Windows). There were plans to port it to Linux, but there were never any plans to support other GPUs. That, and Mantle ran on desktop GPUs. Metal was initially targeted at where the gap between API and hardware was the largest, which was mobile GPUs. At least with desktop OpenGL you had the "AZDO" techniques, but on mobile, you had OpenGL ES. Mobile GPUs aren't just smaller versions of desktop GPUs, they use radically different ways of drawing on the screen (although this gap is narrowing, as desktop GPUs are becoming more like mobile GPUs... basically, expect to see tiled rendering on desktops in the future). If you were living in 2013, would you say, "Gee, I hope someone else forms a committee to adapt Mantle into something which, in the future, maybe in 2016, I could theoretically use?" Or is it faster to make your own API? Or perhaps you like working with cross-platform steering committees that were, at the time, falling behind and failing to address problems with their APIs?
      - jhasse 5y ago
        I would help the committee.
        klodolph 5y ago
        Yes, and that's what they did. They were on the committee, helping out. Seems a lot of people have kind of rewritten the narrative here. Or maybe people forgot that committees & steering groups sometimes fall apart, slow to a crawl, or deliver standards that either aren't useful to developers or aren't feasible for implementers. You'd be a moron to put all your hopes and dreams in a committee / industry working group delivering something to fix the problems with your platform. Sending more engineers to a committee that's already moving slowly will just slow things down further. So these companies, while sitting on the committee, worked on alternatives and had backup strategies. Those strategies turned into Metal and DirectX 12, and the committee realized, "Oh, if we don't fix the problems with OpenGL, it will become completely irrelevant." So, in response to this new competition, the OpenGL steering committee started working on OpenGL Next, which later became Vulkan, and about two years later, got released. It's amazing what a little competition can do.
skocznymroczny 5y ago
DX12 yes. Metal, not so much. Yes, it shares some of the features of low-level, explicit APIs, but it's still a much higher level API than Vulkan/DX12 are. Things like image transitions, memory barriers, synchronization semaphores/fences. In Vulkan/DX12 you need to grasp those to get a triangle on the screen, in Metal not as much.

kitsunesoba 5y ago

I’m not sure about DX12, but my understanding is the Metal was put into production a good deal before there was even a working draft for Vulkan, which makes its existence seem more driven by an immediate need to replace OpenGL ES. I suppose they could’ve dropped Metal right away after Vulkan became usable, but developers tend to get grouchy when APIs change out from under them that frequently. That said there’s no reason they couldn’t support Vulkan alongside Metal, likely with one being a first-party adapter layer for the other.

shmerl 5y ago
> developers tend to get grouchy when APIs change out from under them that frequently Apple didn't care about developers when they let OpenGL rot there, so I don't think it was ever a consideration for them. Their idea for developers is "we know better than you what's good for you". > That said there’s no reason they couldn’t support Vulkan alongside Metal Exactly, and the real reason is - they want their API to work as lock-in rather than allow developers to have options.
user-the-name 5y ago
Metal is also a far more usable API than Vulkan. Apple wants people to actually be able to implement things with their APIs.
- shmerl 5y ago
  Nothing (valid) stopped Apple from building such API on top of Vulkan and provide them alongside each other.
  - Cyberdog 5y ago
    You believe that Apple should support two (three, if you count deprecated but still present OpenGL) different graphics APIs?
    - shmerl 5y ago
      They have more than enough resources to support anything. Such as lower level API (Vulkan) for those who need it and higher level one built on top of it for those who need something simpler but more limited. Do you believe Apple are somehow resource strained in not being able to do that many times over?