Comment by _wmd | Hacker News Reader

Comment by _wmd | Hacker News Reader

Parent Full thread

I'm not a graphics programmer, but everything I've read about OpenGL tells me moving to Metal isn't some embrace/extend maneuver but more likely due to the fact OpenGL is steaming ancient garbage. Kind of like the types who once complained that MacOS wasn't built on X Window (chortle)

BSD sockets isn't a bastion of extensible interface design, it basically amounts to one giant ioctl() in every operating system. Darwin has weird escape hatches built into it (AF_SYSTEM) much like Linux netlink, and protocol parameter documentation is strewn across 5+ man pages each documenting a different set of magic value combinations for non-portably controlling some part of the stack. TCP_USER_TIMEOUT? That's one of many, many Linux socket options, but it's part of our precious so-portable socket interface we must maintain forever!

OS X chooses to bury its system call interface too, it's always been considered a private detail of the C library. I see no reason why socket() and friends couldn't similarly be forgotten. If some clean 21st century redesign of an ancient API has knock-on effects for the structure of code in open source projects across the ecosystem, that's probably a good thing in the long run. Progress never happens by hugging the past, especially when that past is ugly and filled with horrors

Try not to look at this as "hey, MacOS is breaking precious UNIX", but more as "hey look, why can't Bonjour+multipath TCP be a one liner on Linux too?"

I've held the title of graphics programmer professionally a few times and I do think it was a bad idea. If you're targeting Android/Linux/Windows/OSX it's really handy to be able to run the same APIs on the desktop for debugging and faster iteration time.

The real knife in the back was when they forked for Metal instead of adopting Vulkan. I've not used Vulkan in anger yet(just a couple toy demos) but everything I saw pointed to it solving all the major issues people have with OpenGL. Now there's another N+1 APIs, shader language and graphics pipeline that you need to support if you're building a graphical application and not leveraging Unity/UE4/etc.

While not the best solution, there is MoltenVK [0] which handles Metal from Vulkan code.

0: https://github.com/KhronosGroup/MoltenVK

Yeah, but if you look at the support[1] you need to be careful and not depend on any of the APIs called out. Also you will take a perf hit regardless of how well the shim is written.

[1] https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/Mo...

OpenGL is certainly old and warty but it is nothing like X11.

I think people would be ok with Apple dropping OpenGL if they supported Vulkan, but their motivation and desire to lock people into Apple-only APIs is so obvious and transparent... Why would you support it?

At least Microsoft works with third parties and acknowledges the existence of some standards. Apple are always like "Here is the Apple way. I mean, the way. Because there is only Apple. Apple is the whole world and nothing else exists."

Which makes sense from a business point of view. Obviously that doesn’t always align with a hacker mindset but there is a reason Apple is worth almost a trillion dollars.

Exactly, Apple has 1B devices that can run Metal on their GPUs, why shouldn't they write their own library?

Sure, but what platforms ship with Vulkan support?

* Vulkan was a recommended API on android N+, which has ~35% device install (from first % stats that came up on google). However, the CDD doesn't require Vulkan to be present. * Linux is it up to the distribution to include it, and it isn't currently required by any standard open source package. If your card isn't AMD or Nvidia, you do not have an option for vulkan support AFAIK. * Windows it is something installed by the video card driver as part of their game support and not available across all cards * Mac/iOS it is built on top of Metal and available as a free third party library for your app bundles

I'm sure people would prefer Apple lead the pack and embrace a new standard before the rest of the industry, but it doesn't really buy them anything with their Metal investment to be first adopter, and it is very Anti-Apple to want to cede that sort of control. Especially when nobody else is doing it.

Metal is used by more than just games. Apple needed a robust, scalable library for its GPUs, across 4 different platforms that could handle more than just graphics. It is now the heart of Core ML, used for machine learning, as well a few other things.

> OpenGL is steaming ancient garbage

Not really by any standard. It is about as good as other APIs of a similar level of abstraction (certainly no fair comparison with X11), and crucially it is widely supported. OS X's support for OpenGL is very poor (they are behind on standards by more than half a decade, despite shipping hardware that supports all the new stuff) because Apple has been hostile to it, just as they are not interested in enabling Vulkan in any way (though that hasn't stopped the industry from routing around Apple's tremendous narcissism).

I like OpenGL probably as much as the next developer, probably more. I’ve long been an advocate. But I still think it’s a bunch of steaming ancient garbage, the same way OpenSSL is. Apple stopped bundling OpenSSL and the message was, “if you want it that badly, bring your own.” That turned out to be a good move, and the people who stuck with OpenSSL paid the price.

OpenGL will continue to be available for a long time. But the idea that you would want to develop new applications for it… well, the mismatch between the OpenGL API and the way modern GPUs work is just too big. You can paper over the small problems with a bunch of small changes but at this point I think it’s extremely fair to say, “you want OpenGL, be prepared to bring your own implementation.” This is a good thing, we are getting OpenGL implementations on top of e.g. Vulkan, Metal, DX12 that are going to be more consistent and easy to target than all the differences between vendor OpenGL implementations.

It’s extra work for developers but I believe it’s better for long term platform health. It just makes more sense for OpenGL to be a fat library, and it makes things easier if you can target one version of the library instead of five. Again, this is basically what happened with OpenSSL.

> But I still think it’s a bunch of steaming ancient garbage

Compared to what? Direct3D? I don't think it is fair or reasonable to compare OpenGL to libraries which exist on a completely different level of abstraction. The last straw for OpenSSL was in the implementation, not the API design, so I don't really understand the comparison.

OpenGL is absolutely inferior to DirectX. If for no other reason than it is impossible to figure out the correct, modern way to do things in OpenGL.

The only saving grace is that OpenGL is kinda sorts cross-platform. If your platform provides drivers that are worth a shit, which has been a big question.

> OpenGL is absolutely inferior to DirectX. If for no other reason than it is impossible to figure out the correct, modern way to do things in OpenGL.

Well, I guess I would just say I disagree. I am relatively new to graphics programming, and the right thing was the first thing I found, every time. The most confusing part reading people warning people not to use compatibility contexts at the beginning of articles from the transitional period.

> The only saving grace is that OpenGL is kinda sorts cross-platform. If your platform provides drivers that are worth a shit, which has been a big question.

This bit I largely agree with, but even if it were the worst it's ever been (and it's not), it would still be better than implementing your application twice or thrice. I have been lucky enough to be on Mesa (primarily) for the last eight or so years, and driver quality has been of minimal concern to me.

Reply on news.ycombinator.com