2 ms·

> Yeah, in 2016. Not out of the blue. AMD wanted that collaboration and got different parties interested. It took a while to get needed groups together and the

by shmerl 5y ago

> Yeah, in 2016. Not out of the blue. AMD wanted that collaboration and got different parties interested. It took a while to get needed groups together and then develop it until it was out in 2016 (not by AMD alone at that time obviously). Where were Apple and MS when this was happening between 2013 and 2016? Your argument about non-starter is clearly incorrect, since Vulkan did result from it all. So it was possible, but took time. Khronos was already managing OpenGL so they fit the role of overseeing it. Someone else could do it too may be, but no one else stepped up (including same MS and Apple who easily could if they thought they could do better). > The story I’ve heard was that the release of Metal was a real kick in the pants for what became the Vulkan effort. Apple very well knew there is an interest in the common API. Where were they? Making their Apple only NIH of course. Collaboration takes more time, sure. Did Apple join? No. They never cared.

klodolph 5y ago
> Your argument about non-starter is clearly incorrect, since Vulkan did result from it all. I’m talking about what people perceived in 2013. You are welcome to judge people’s decisions, using your knowledge of future events, if that’s what you really want to do. > Where were Apple and MS when this was happening between 2013 and 2016? Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies with competing interests can get off their butts and even figure out what they’re going to name the project.” Those years were years of massive, massive growth for the App Store and the iOS ecosystem. If you could fix major problems that your customers a couple years faster, during a time when sales were growing 50% year over year, you’d want to do it yourself too. There’s only so many engineers at your company with the patience and drive to sit on committees. > Khronos was already managing OpenGL so they fit the role of overseeing it. It was called “OpenGL Next”, not Vulkan, at the time. Well, not when Metal was released, since it didn’t even exist when Metal was released.
- shmerl 5y ago
  > You are welcome to judge people’s decisions, using your knowledge of future events If some thought it was a non starter, AMD thought it's a good idea that would benefit everyone. Who ended up being right? Not the skeptics, that was my point. The idea was correct and those who backed it helped move it forward. But Apple and MS did the opposite of helping. > Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms". That's the approach MS and Apple were using for years. But it's not right if you care about making things better for the industry, because it's only slowing progress down. I really see no justification for using development tools like APIs for market control, it's a crooked practice.
  - klodolph 5y ago
    > But Apple and MS did the opposite of helping. I think it's pretty absurd to expect Apple and MS to suspend work on graphics APIs until the committee gets around to figure things out. Especially when the committee is already falling behind, and fixing these issues isn't even on the agenda yet. I just don't understand how someone could blame Apple and Microsoft for developing their own APIs, and then let the OpenGL committee off the hook for completely failing to fix the outstanding issues in the OpenGL API in a timely fashion. Again... and it seems people keep forgetting this part... Metal was released to developers before the project that eventually became Vulkan even started. At the time Metal was released, Vulkan DID NOT EXIST, not even by a different name. "I know, let's not work on this important project, and hand it off to an industry working group." Said no engineer, ever. When a committee fails to produce a working standard, alternatives appear. This is how WHATWG appeared. > That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms". That's just begging the question. If you're going to argue, at least make an argument.
    - shmerl 5y ago
      What's absurd is trying to paint them as someone who can't simply start supporting Vulkan today and fix this fragmentation mess. Lock-in has no excuse for the likes of them. And I already brought examples above where MS did the right thing, like with OpenXR.
      - klodolph 5y ago
        They're also locked-in to their own software. It's not just third-party developers using Metal, but first-party developers too. It would be nothing short of a massive effort, to shift the entire company from Metal to Vulkan. Make no mistake, this is what you're asking for. Choosing to support two graphics APIs? No, not gonna happen. This is why Apple deprecated OpenGL in the first place. Nobody believes that Apple could just snap their fingers and start supporting Vulkan today. It just seems too optimistic to me, and these kinds sweeping changes require a lot of coordination. You introduce the Vulkan API internally (which takes time). Then you start with the various low-level frameworks, like Cocoa. With that base in place, you can write transpilers and migration tools to move from Metal shaders to something that compiles to SPIR-V. Perhaps a new backend to an existing compiler? From there, you work up the stack, applying the migration tools. Core Image is a big one. Undoubtedly, you'd have to back out the changes to some frameworks and try again. At the end, you're working on end-user applications like Final Cut. You'll also want to build a framework on top of Vulkan to manage resources a bit. Metal has an Objective-C interface and works with ARC, Vulkan is all manual. OpenXR is a lot smaller than Vulkan, and affects a much smaller number of applications. Not really a suitable comparison. I would love for everything to use Vulkan, but I also understand the reasons why things didn't turn out that way, and why this is a problem that's not easy to solve.

by shmerl 5y ago

klodolph 5y ago

> Your argument about non-starter is clearly incorrect, since Vulkan did result from it all. I’m talking about what people perceived in 2013. You are welcome to judge people’s decisions, using your knowledge of future events, if that’s what you really want to do. > Where were Apple and MS when this was happening between 2013 and 2016? Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies with competing interests can get off their butts and even figure out what they’re going to name the project.” Those years were years of massive, massive growth for the App Store and the iOS ecosystem. If you could fix major problems that your customers a couple years faster, during a time when sales were growing 50% year over year, you’d want to do it yourself too. There’s only so many engineers at your company with the patience and drive to sit on committees. > Khronos was already managing OpenGL so they fit the role of overseeing it. It was called “OpenGL Next”, not Vulkan, at the time. Well, not when Metal was released, since it didn’t even exist when Metal was released.

shmerl 5y ago
> You are welcome to judge people’s decisions, using your knowledge of future events If some thought it was a non starter, AMD thought it's a good idea that would benefit everyone. Who ended up being right? Not the skeptics, that was my point. The idea was correct and those who backed it helped move it forward. But Apple and MS did the opposite of helping. > Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms". That's the approach MS and Apple were using for years. But it's not right if you care about making things better for the industry, because it's only slowing progress down. I really see no justification for using development tools like APIs for market control, it's a crooked practice.
- klodolph 5y ago
  > But Apple and MS did the opposite of helping. I think it's pretty absurd to expect Apple and MS to suspend work on graphics APIs until the committee gets around to figure things out. Especially when the committee is already falling behind, and fixing these issues isn't even on the agenda yet. I just don't understand how someone could blame Apple and Microsoft for developing their own APIs, and then let the OpenGL committee off the hook for completely failing to fix the outstanding issues in the OpenGL API in a timely fashion. Again... and it seems people keep forgetting this part... Metal was released to developers before the project that eventually became Vulkan even started. At the time Metal was released, Vulkan DID NOT EXIST, not even by a different name. "I know, let's not work on this important project, and hand it off to an industry working group." Said no engineer, ever. When a committee fails to produce a working standard, alternatives appear. This is how WHATWG appeared. > That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms". That's just begging the question. If you're going to argue, at least make an argument.
  - shmerl 5y ago
    What's absurd is trying to paint them as someone who can't simply start supporting Vulkan today and fix this fragmentation mess. Lock-in has no excuse for the likes of them. And I already brought examples above where MS did the right thing, like with OpenXR.
    - klodolph 5y ago
      They're also locked-in to their own software. It's not just third-party developers using Metal, but first-party developers too. It would be nothing short of a massive effort, to shift the entire company from Metal to Vulkan. Make no mistake, this is what you're asking for. Choosing to support two graphics APIs? No, not gonna happen. This is why Apple deprecated OpenGL in the first place. Nobody believes that Apple could just snap their fingers and start supporting Vulkan today. It just seems too optimistic to me, and these kinds sweeping changes require a lot of coordination. You introduce the Vulkan API internally (which takes time). Then you start with the various low-level frameworks, like Cocoa. With that base in place, you can write transpilers and migration tools to move from Metal shaders to something that compiles to SPIR-V. Perhaps a new backend to an existing compiler? From there, you work up the stack, applying the migration tools. Core Image is a big one. Undoubtedly, you'd have to back out the changes to some frameworks and try again. At the end, you're working on end-user applications like Final Cut. You'll also want to build a framework on top of Vulkan to manage resources a bit. Metal has an Objective-C interface and works with ARC, Vulkan is all manual. OpenXR is a lot smaller than Vulkan, and affects a much smaller number of applications. Not really a suitable comparison. I would love for everything to use Vulkan, but I also understand the reasons why things didn't turn out that way, and why this is a problem that's not easy to solve.