> I think quite a few of the hyperbolic comments
That's what you get from things like deprecating OpenGL and replacing it with a non-multiplatform alternative: bad reputation. They should ask Microsoft if it's easy to get rid of if once you have it.
That's what you get from things like deprecating OpenGL and replacing it with a non-multiplatform alternative: bad reputation. They should ask Microsoft if it's easy to get rid of if once you have it.
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 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."
* 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.
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).
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.
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.
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.
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.
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.
[1] https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/Mo...
Similar, but the differences matter. kqueue is readyness-oriented. It tells you that the driver is ready to queue more writes. But you still need to call fsync and friends to confirm that your data has actually been written out. There's no non-blocking fsync. Servers like Redis run an extra thread just to call fsync; and eat all the performance problems that entails.
In contrast, IOCP is completion-oriented. There's no need for any blocking fsync calls in order to find out when data has been written. Its way more granular - the OS can reorder writes. And it doesn't suffer from fsync's awful non-local error handling problems.
Honestly I'm surprised there's no equivalent for linux / BSD. (I mean, we have AIO but its really not good enough). IOCP is a fantastic API for high performance databases and servers. It enables faster and simpler server code. We should collectively get on it.
You can build a proactor pattern on top of a reactor pattern, but that implementation needs to provide quite a bit - more coordination of pending memory/state and probably needing back pressure support (which I never really understood if Microsoft supplied or if you had to track that yourself).
I know Microsoft used to have several IOCP-related patents; I believe I remember one for event scheduling for multi-threaded locality (preferring to dispatch a completion to the same thread that made the original request).
You still need FlushFileBuffers even with IOCP if files are opened in buffered mode (which is the default). While you will know when a write was completed, an explicit flush is still needed to make sure it’s written through. So it’s pretty much exactly the same case as with fsync(). Alternatively, you can use the write-through mode, but that kills performance like that, especially with a random write pattern.
IOCP is basically a better/cleaner abstracted epoll() that also doubles as a manager of a worker thread pool.