> deprecating it was also stupid. It was a legal decision made by Apple lawyers pursuing a particular litigation strategy vs Nvidia that caused Apple's withdrawal from Khronos group.

I'm not aware of the context here but that sounds like an interesting story. Could you give more details or do you know where I could read more about this?

I'm not aware of any good writeups. Neither Apple nor Nvidia wanted to publicize it. Here's the story as I know it:

When Apple decided to make their own GPU, all the other GPU vendors sued them for patent infringement. Apple countersued, and the litigation went on for many, many years. In the case of Nvidia there were also previous legal disputes over liability for Macbook GPU hardware defects, which meant that Apple had cut all ties with Nvidia years prior. This probably led to Apple's legal fight with Nvidia being especially prolonged and vicious.

Khronos Group, which produces the OpenGL and Vulkan standards, has ties to Nvidia. I don't know all the details but it seems Apple's lawyers decided that they would block implementation of any new Khronos standards in Apple products due to the Nvidia connection. As a result the OpenGL implementation in macOS was frozen at version 4.1 (July 2010) for many years, even prior to deprecation, lacking important features like compute shaders. Of course Vulkan support for macOS was completely out of the question. They also stopped work on Safari's implementation of WebGL 2 (which was left in a half-done state for years until it was eventually pushed to completion by Google engineers including myself). Additionally, Apple successfully maneuvered the WebGPU working group out of Khronos to W3C, and vetoed SPIR-V on the web, eventually resulting in WGSL.

So the legal dispute between Apple and Nvidia had a big influence on the industry. If Apple hadn't been allergic to Khronos standards, in an optimistic scenario we might have had a significantly better Vulkan standard with contributions from Apple's Metal team, Vulkan+SPIR-V support on macOS and iOS, and even SPIR-V on the web, which would have given us a truly cross-platform modern graphics API to replace OpenGL and made writing portable graphics software significantly easier in the last decade.

Of course today all this seems a lot less relevant with the rise of coding agents that can port a codebase or even a binary executable between platforms with a few prompts. So it will soon be a forgotten historical curiosity.

The easiness of porting is always exaggerated, first of all, all 8 and 16 bit home computers had their own ways, the game consoles for the most part ignore Khronos, and still there is a thriving market, because game devs contrary to FOSS folks, implement a middleware engine during breakfast, and move on with their lives.

Secondly, thanks to extension spaghetti from Khronos APIs, the portability across devices, OS and computing platforms is hardly much different than coding to multiple graphics backends.

There are hardly any Khronos APIs related content at game conferences, that isn't done by Khronos themselves.

So even without coding agents it has never been that industry relevant, other than on open source communities.

Games are not the only users of graphics APIs. Anyway, it's true that Vulkan/SPIR-V support on mac/iOS and web would not be a portability panacea by itself. That said, it certainly wouldn't have hurt either. And if portability between all desktop and mobile devices with a single API was a realistic possibility, there would have been more interest in fixing the portability issues that remained. But why bother to care about Vulkan portability when you're going to need an abstraction layer above it anyway for iOS/Metal support.

Point is, the reasons we didn't get any even minimally portable native graphics API this cycle are more legal than technical.

I find this pattern so funny. Khronos and Microsoft anticipate 20 graphics vendor APIs, so 2 portable standard APIs are created. The common denominator problem stifles competition and leads to unexposed functionality some vendors have or won’t bother developing because of it. It also introduces a lot of implementation problems that would not exist with vendor-specific APIs. How many vendor APIs were there really back then and now? A handful across industries, less on specific platforms.

I see this pattern again and again. For example in the manufacturing industry there’s a network standard OPC UA. It sucks. It tries to extend to absolutely everything (wtf database interfaces?). Like you say, the “integrators” just write a middle layer and move on with their days.

interesting story, but the fact that Apple and Nvidia were sueing each other doesn't seem any reason to drop all open standards. I would say they did it because of arrogance - ie. we're Apple and everything we do is better, therefore our graphics API is superior than any other

TBH, I'm not saying "DTS Engineer" isn't an actual Apple engineer, but it feels very LLM-written. For something like that, I wouldn't want it to guarantee that a fix can or will be done in any sort of timeframe.