Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

View on HN

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.

They actually are, office software isn't sending rendering command lists to the GPUs.

Anything else is just fine using the OS visualisation widgets on their UI toolkits, and if portability is that much of a concern, pick Qt, wxWidgets or whatever, already solved in the 1990s.

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.

Reply on news.ycombinator.com