4 ms·
People panicked at first about the GL Apocalypse when Apple decided to use Metal instead of Vulcan. But here's the way I look at it: OpenGL was created to abst
by _bxg1 6y ago
People panicked at first about the GL Apocalypse when Apple decided to use Metal instead of Vulcan.
But here's the way I look at it: OpenGL was created to abstract over graphics hardware and operating systems both at once, and yet was intended to be high-level enough that it could be called out to directly by application developers (including game developers).
It was what people needed at the time, but I think it was trying to do too many things in a single layer of abstraction, and these days it isn't doing a great job at any of them. It's known for being slow. Most people don't write it directly anymore; they use a game engine or library and only write shaders directly. It performs inconsistently between OSes.
Whereas Vulcan, and even more so Metal, are decidedly lower-level. They abstract over the hardware and that's about it. This enables the higher-level libraries and engines that people were already using to be more fine-tuned and performant while still allowing graphics hardware to remain a commodity.
In this context WebGL is interesting because it's also an abstraction over Vulcan/Metal/DirectX, while remaining lower-level than most of those other libraries and engines. It's really very much like we've split the OpenGL layer in two and ended up with one layer focused on performance within a given OS, and another layer focused on providing a modern, ergonomic API across all systems.
All in all, I think this is a pretty good way for things to have progressed.
- oddity 6y agoThe real benefits of DirectX 12, Vulkan, and Metal were that they let the API designers drop cruft and add new features. This was more significant for OpenGL->Vulkan and OpenGL->Metal than it was for DirectX 11->12 because OpenGL had more cruft and so much more surface area to get wrong. I'd still hesitate to say that Vulkan, DirectX, and Metal are lower level in any meaningful way. Most of the work the driver does/did, like shader/pipeline state compilation or command submission, is still there. Vulkan and DirectX just tie the driver's hands a bit, for better or worse inversely proportional to how good the driver stack is/was. Calling Vulkan lower-level than OpenGL is a bit like calling Java lower level than Javascript. We're still a long way from being able to shoot ourselves in the foot like we can with C. Unless you're using the more modern features of Metal like argument buffers and manual resource tracking, Metal is closer to late-stage OpenGL than it is to Vulkan or DirectX. Otherwise, they're about the same. I agree about the split between performance vs ergonomics, but it's a bit more complicated than that. Conceptually, the lower-level APIs expose functionality that make graphics programming much, much easier for large scale rendering engines. It's not just about performance. Most of the initial boilerplate amortizes away behind an abstraction layer anyway. What's exposed in web apis is still many years behind the state of the art in the native space. However, when it comes to just drawing a triangle with the techniques of 2010, personally I have a lot of hope for WebGPU. Besides functionality, the ergonomics problem of native apis are primarily down to tooling. Large game studios and engine devs can afford to invest in infrastructure that small hobbyists/indie devs can't.