6 ms·

OpenGL is going to live a long life simply because Vulkan is way more complex and overengineered than it needs to be.

jsheard 1y ago
It's steadily getting better as they keep walking back aspects which turned out to be needlessly complex, or only needed to be complex for the sake of older hardware that hardly anyone cares about anymore, but yeah there's still a way to go. Those simpler ways of doing things are just grafted onto the side of the existing API surface so just knowing which parts you're supposed to use is a battle in itself. Hopefully they'll eventually do a clean-slate Vulkan 2.0 to tidy up the cruft, but I'm not getting my hopes up.
- m-schuetz 1y ago
  Might be getting better but just yesterday I dabbled in Vulkan again, digging through the examples from https://github.com/SaschaWillems/Vulkan https://github.com/SaschaWillems/Vulkan, and the complexity is pure insanity. What should be a simple malloc ends up being 40 lines of code, what should be a simple memcpy is another 30 lines of code, and what should be a single-line kernel launch is another 50 lines of bindings, layouts, pipelines, etc.
  - flohofwoe 1y ago
    Tbf, a lot of the complexity (also in the official Khronos samples) is caused by insane C++ abstraction layers and 'helper frameworks' on top of the actual Vulkan C API. Just directly talking to the C API in the tutorials/examples instead of custom wrapper code would be a lot more helpful since you'd don't need to sift through the custom abstraction layers (even if it would be slightly more code). E.g. have a look at the code snippets in here and weep in despair ;) https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangle/00_Setup/03_Physical_devices_and_queue_families.html https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangl...
  - jplusequalt 1y ago
    Why should these things be simple? Graphics hardware varies greatly even across generations from the same vendors. Vulkan as an API is trying to offer the most functionality to as much of this hardware as possible. That means you have a lot of dials to tweak. Trying to obfuscate all the options goes against what Vulkan was created for. Use OpenGL 4.6/WebGPU if you want simplicity.
    - flohofwoe 1y ago
      A simple vkCreateSystemDefaultDevice() function like on Metal instead of requiring hundreds of lines of boilerplate would go a long way to make Vulkan more ergonomic without having to give up a more verbose fallback path for the handful Vulkan applications that need to pick a very specific device (and then probably pick the wrong one on exotic hardware configs). And the rest of the API is full of similar examples of wasting developer time for the common code path. Metal is a great example of providing both: a convenient 'beaten path' for 90% of use cases but still offering more verbose fallbacks when flexibility is needed. Arguably, the original idea to provide a low-level explicit API also didn't quite work. Since GPU architectures are still vastly different (especially across desktop and mobile GPUs), a slightly more abstract API would be able to provide more wiggle room for drivers to implement an API feature more efficiently under the hood, and without requiring users to write different code paths for each GPU vendor.
      - jplusequalt 1y ago
        Metal has the benefit of being developed by Apple for Apple devices. I'd imagine that constraint allows them to simplify code paths in a way Vulkan can't/won't. Again, Metal doesn't have to deal with supporting dozens of different hardware systems like Vulkan does.
        flohofwoe 1y ago
        Metal also works for external GPUs like NVIDIA or AMD though (not sure how much effort Apple still puts into those use cases, but Metal itself is flexible enough to deal with non-Apple GPUs).
pjmlp 1y ago
Yes, recent example, the board getting released by Qualcomm after acquiring Arduino. Between OpenGL ES 3.1 and Vulkan 1.1, I would certainly go with OpenGL ES.
- Narishma 1y ago
  Oh I didn't know the new Arduino board had a GPU. Do we know what kind?
  - pjmlp 1y ago
    Yes, Adreno 702 https://www.qualcomm.com/products/internet-of-things/robotics-processors/qrb2210 https://www.qualcomm.com/products/internet-of-things/robotic...
flohofwoe 1y ago
Vulkan (1.0 at least) being a badly designed API doesn't mean that OpenGL will be maintained unfortunately. Work on OpenGL pretty much stopped in 2017.
- m-schuetz 1y ago
  I am sadly aware, but I won't switch until the complexity is fixed. Although I did kind of switch, but to CUDA because the overengineered complexity of Vulkan drove me away. I'm neither smart nor patient enough for that. What should be a malloc is a PhD thesis in Vulkan, what should be a memcpy is another thesis, and what should be a simple kernel launch is insanity.
  - exDM69 1y ago
    > I am sadly aware, but I won't switch until the complexity is fixed It pretty much is by now if you can use Vulkan 1.4 (or even 1.3). It's a pretty lean and mean API once you've got it bootstrapped. There's still a lot of setup code to get off the ground (device enumeration, extensions and features, swapchain setup, pipeline layouts), but beyond that Vulkan is much nicer to work with than OpenGL. Just gotta get past the initial hurdle.
jplusequalt 1y ago
I don't doubt OpenGL will live forever. But Vulkan 1.3/1.4 is not as bad as people make it out to be.
- m-schuetz 1y ago
  So I've been told so I'm trying to take another look at it. At least the examples at https://github.com/SaschaWillems/Vulkan https://github.com/SaschaWillems/Vulkan, which are probably not 1.3/1.4 yet except for the trianglevulkan13 example, are pure insanity. Coming from CUDA, I can't fathom why what should be simple things like malloc, memcpy and kernel launches, end up needing 300x as many lines.
  - jplusequalt 1y ago
    In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts. Vulkan is also trying to expose as many options as possible so as to be extensible on as many platforms as possible. Also, Vulkan isn't even trying to make it more complex than it need be--this is just how complex graphics programming is period. The only reasons people think Vulkan/DX12 are overly complicated is because they're used to using APIs where the majority of the heavy lifting comes from the drivers.
    - flohofwoe 1y ago
      > In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts. Tbf, the distinction between rendering and compute has been disappearing for quite a while now, apart from texture sampling there isn't much reason to have hardware that's dedicated for rendering tasks on GPUs, and when there's hardly any dedicated rendering hardware on GPUs, why still have dedicated rendering APIs?
      - jplusequalt 1y ago
        This is not a statement on the hardware, it's a statement on what the APIs are trying to achieve. In this regard, they are remarkably different.

It's steadily getting better as they keep walking back aspects which turned out to be needlessly complex, or only needed to be complex for the sake of older hardware that hardly anyone cares about anymore, but yeah there's still a way to go. Those simpler ways of doing things are just grafted onto the side of the existing API surface so just knowing which parts you're supposed to use is a battle in itself. Hopefully they'll eventually do a clean-slate Vulkan 2.0 to tidy up the cruft, but I'm not getting my hopes up.

m-schuetz 1y ago
Might be getting better but just yesterday I dabbled in Vulkan again, digging through the examples from https://github.com/SaschaWillems/Vulkan https://github.com/SaschaWillems/Vulkan, and the complexity is pure insanity. What should be a simple malloc ends up being 40 lines of code, what should be a simple memcpy is another 30 lines of code, and what should be a single-line kernel launch is another 50 lines of bindings, layouts, pipelines, etc.
- flohofwoe 1y ago
  Tbf, a lot of the complexity (also in the official Khronos samples) is caused by insane C++ abstraction layers and 'helper frameworks' on top of the actual Vulkan C API. Just directly talking to the C API in the tutorials/examples instead of custom wrapper code would be a lot more helpful since you'd don't need to sift through the custom abstraction layers (even if it would be slightly more code). E.g. have a look at the code snippets in here and weep in despair ;) https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangle/00_Setup/03_Physical_devices_and_queue_families.html https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangl...
- jplusequalt 1y ago
  Why should these things be simple? Graphics hardware varies greatly even across generations from the same vendors. Vulkan as an API is trying to offer the most functionality to as much of this hardware as possible. That means you have a lot of dials to tweak. Trying to obfuscate all the options goes against what Vulkan was created for. Use OpenGL 4.6/WebGPU if you want simplicity.
  - flohofwoe 1y ago
    A simple vkCreateSystemDefaultDevice() function like on Metal instead of requiring hundreds of lines of boilerplate would go a long way to make Vulkan more ergonomic without having to give up a more verbose fallback path for the handful Vulkan applications that need to pick a very specific device (and then probably pick the wrong one on exotic hardware configs). And the rest of the API is full of similar examples of wasting developer time for the common code path. Metal is a great example of providing both: a convenient 'beaten path' for 90% of use cases but still offering more verbose fallbacks when flexibility is needed. Arguably, the original idea to provide a low-level explicit API also didn't quite work. Since GPU architectures are still vastly different (especially across desktop and mobile GPUs), a slightly more abstract API would be able to provide more wiggle room for drivers to implement an API feature more efficiently under the hood, and without requiring users to write different code paths for each GPU vendor.
    - jplusequalt 1y ago
      Metal has the benefit of being developed by Apple for Apple devices. I'd imagine that constraint allows them to simplify code paths in a way Vulkan can't/won't. Again, Metal doesn't have to deal with supporting dozens of different hardware systems like Vulkan does.
      - flohofwoe 1y ago
        Metal also works for external GPUs like NVIDIA or AMD though (not sure how much effort Apple still puts into those use cases, but Metal itself is flexible enough to deal with non-Apple GPUs).

pjmlp 1y ago

Yes, recent example, the board getting released by Qualcomm after acquiring Arduino. Between OpenGL ES 3.1 and Vulkan 1.1, I would certainly go with OpenGL ES.

Narishma 1y ago
Oh I didn't know the new Arduino board had a GPU. Do we know what kind?
- pjmlp 1y ago
  Yes, Adreno 702 https://www.qualcomm.com/products/internet-of-things/robotics-processors/qrb2210 https://www.qualcomm.com/products/internet-of-things/robotic...

flohofwoe 1y ago

Vulkan (1.0 at least) being a badly designed API doesn't mean that OpenGL will be maintained unfortunately. Work on OpenGL pretty much stopped in 2017.

m-schuetz 1y ago
I am sadly aware, but I won't switch until the complexity is fixed. Although I did kind of switch, but to CUDA because the overengineered complexity of Vulkan drove me away. I'm neither smart nor patient enough for that. What should be a malloc is a PhD thesis in Vulkan, what should be a memcpy is another thesis, and what should be a simple kernel launch is insanity.
- exDM69 1y ago
  > I am sadly aware, but I won't switch until the complexity is fixed It pretty much is by now if you can use Vulkan 1.4 (or even 1.3). It's a pretty lean and mean API once you've got it bootstrapped. There's still a lot of setup code to get off the ground (device enumeration, extensions and features, swapchain setup, pipeline layouts), but beyond that Vulkan is much nicer to work with than OpenGL. Just gotta get past the initial hurdle.

jplusequalt 1y ago

I don't doubt OpenGL will live forever. But Vulkan 1.3/1.4 is not as bad as people make it out to be.

m-schuetz 1y ago
So I've been told so I'm trying to take another look at it. At least the examples at https://github.com/SaschaWillems/Vulkan https://github.com/SaschaWillems/Vulkan, which are probably not 1.3/1.4 yet except for the trianglevulkan13 example, are pure insanity. Coming from CUDA, I can't fathom why what should be simple things like malloc, memcpy and kernel launches, end up needing 300x as many lines.
- jplusequalt 1y ago
  In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts. Vulkan is also trying to expose as many options as possible so as to be extensible on as many platforms as possible. Also, Vulkan isn't even trying to make it more complex than it need be--this is just how complex graphics programming is period. The only reasons people think Vulkan/DX12 are overly complicated is because they're used to using APIs where the majority of the heavy lifting comes from the drivers.
  - flohofwoe 1y ago
    > In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts. Tbf, the distinction between rendering and compute has been disappearing for quite a while now, apart from texture sampling there isn't much reason to have hardware that's dedicated for rendering tasks on GPUs, and when there's hardly any dedicated rendering hardware on GPUs, why still have dedicated rendering APIs?
    - jplusequalt 1y ago
      This is not a statement on the hardware, it's a statement on what the APIs are trying to achieve. In this regard, they are remarkably different.