4 ms·

> 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 wo

by 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.
    - shmerl 5y ago
      All of that is still no excuse for them. The can do it with their resources just fine. They benefit from lock-in and it's the main reason they didn't fix the situation yet.

by shmerl 5y ago

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.
  - shmerl 5y ago
    All of that is still no excuse for them. The can do it with their resources just fine. They benefit from lock-in and it's the main reason they didn't fix the situation yet.