4 ms·

> The hard part of learning OpenGL for me has been the sheer amount of boilerplate needed to get the most basic image on the screen. You think that now, but wa

> The hard part of learning OpenGL for me has been the sheer amount of boilerplate needed to get the most basic image on the screen. You think that now, but wait until you get to Vulkan.

akdas 6y ago
I bet! I'm fortunate enough to understand the concept of shaders, and how GPUs work generally, so at least that's one concept I don't have to learn. The APIs, however, are another beast altogether.
Impossible 6y ago
Yes, every HN graphics thread has a group of people that complain that Vulkan isn't used everywhere. Most of them have not written any Vulkan because many HN graphics threads complain about the amount of boilerplate required to get a triangle onscreen in higher level APIs like OpenGL. I can't find a Vulkan C API hello triangle that is less than 1000 LOC, although Vulkan-hpp reduces that significantly, and many of the examples are OpenGL size. https://github.com/KhronosGroup/Vulkan-Hpp https://github.com/KhronosGroup/Vulkan-Hpp
- Jasper_ 6y ago
  The complexity that Vulkan introduces is not just the extra code, it's a substantial rethink of the mental model of graphics that involves a lot more precision about things like synchronization, and baking of device state. Those who argue "Vulkan requires more boilerplate" are missing the point, imho.
  - mewse 6y ago
    Or to put that same idea differently: If you treat the extra code required as “boilerplate”, then you’re unlikely to get much of a benefit from switching to Vulkan.
    - esrauch 6y ago
      The issue is that OpenGL isn't going to get any new versions, so if you're trying to be forward looking there's only Vulkan even if you don't need the delta that you get performance-wise between that and GL. Its a little surprising there's no real movement for an API that is closer to ES3 in difficulty that targets Vulkan and Metal underneath. I guess maybe webgpu will be that thing eventually.
- ReactiveJelly 6y ago
  I don't use Vulkan because I'm sick of paying for API upgrades. I can run pretty much the same software on my desktop today as on my now-dead 2008 laptop. On the CPU. But the GPU is capped at OpenGL 2. What's the point of being a software enthusiast if the software is tied to the most expensive piece of hardware in the box?
_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 ago
  The 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.

> The hard part of learning OpenGL for me has been the sheer amount of boilerplate needed to get the most basic image on the screen. You think that now, but wait until you get to Vulkan.

akdas 6y ago

I bet! I'm fortunate enough to understand the concept of shaders, and how GPUs work generally, so at least that's one concept I don't have to learn. The APIs, however, are another beast altogether.

Impossible 6y ago

Yes, every HN graphics thread has a group of people that complain that Vulkan isn't used everywhere. Most of them have not written any Vulkan because many HN graphics threads complain about the amount of boilerplate required to get a triangle onscreen in higher level APIs like OpenGL. I can't find a Vulkan C API hello triangle that is less than 1000 LOC, although Vulkan-hpp reduces that significantly, and many of the examples are OpenGL size. https://github.com/KhronosGroup/Vulkan-Hpp https://github.com/KhronosGroup/Vulkan-Hpp

Jasper_ 6y ago
The complexity that Vulkan introduces is not just the extra code, it's a substantial rethink of the mental model of graphics that involves a lot more precision about things like synchronization, and baking of device state. Those who argue "Vulkan requires more boilerplate" are missing the point, imho.
- mewse 6y ago
  Or to put that same idea differently: If you treat the extra code required as “boilerplate”, then you’re unlikely to get much of a benefit from switching to Vulkan.
  - esrauch 6y ago
    The issue is that OpenGL isn't going to get any new versions, so if you're trying to be forward looking there's only Vulkan even if you don't need the delta that you get performance-wise between that and GL. Its a little surprising there's no real movement for an API that is closer to ES3 in difficulty that targets Vulkan and Metal underneath. I guess maybe webgpu will be that thing eventually.
ReactiveJelly 6y ago
I don't use Vulkan because I'm sick of paying for API upgrades. I can run pretty much the same software on my desktop today as on my now-dead 2008 laptop. On the CPU. But the GPU is capped at OpenGL 2. What's the point of being a software enthusiast if the software is tied to the most expensive piece of hardware in the box?

_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 ago
The 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.