2 ms·

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 l

by 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

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.