11 ms·

It's officially deprecated in favor of Vulkan, but it will likely live on for decades to come due to legacy CAD software and a bunch of older games still using

It's officially deprecated in favor of Vulkan, but it will likely live on for decades to come due to legacy CAD software and a bunch of older games still using it. I don't share the distaste many have for it, it's good to have a cross-platform medium-complexity graphics API for doing the 90% of rendering that isn't cutting-edge AAA gaming.

m-schuetz 1y ago
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.
Cieric 1y ago
> It's officially deprecated in favor of Vulkan Can you provide a reference for this? I work in the GPU driver space (not on either of these apis), but from my understanding Vulkan wasn't meant to replace OpenGL, it was only introduced to give developers the chance at getting lower level in the hardware (still agnostic from the hardware, at least compared to compiling PTX/CUDA or against AMD's PAL directly, many still think they failed.) I would still highly advocate for developers using OpenGL or dx11 if their game/software doesn't need the capabilities of Vulkan or dx12. And even if you did, you might be able to get away with interop and do small parts with the lower api and leave everything else in the higher api. I will admit I don't like the trend of all the fancy new features only getting introduced into Vulkan and dx12, but I'm not sure how to change that trend.
- ecshafer 1y ago
  I only play with this stuff as a hobbiest. But OpenGL is way more simple than Vulkan I think. Vulkan is really really complicated to get some basic stuff going.
  - marmarama 1y ago
    Which is as-designed. Vulkan (and DX12, and Metal) is a much more low-level API, precisely because that's what professional 3D engine developers asked for. Closer to the hardware, more control, fewer workarounds because the driver is doing something "clever" hidden behind the scenes. The tradeoff is greater complexity. Mere mortals are supposed to use a game engine, or a scene graph library (e.g. VulkanSceneGraph), or stick with OpenGL for now. The long-term future for OpenGL is to be implemented on top of Vulkan (specifically the Mesa Zink driver that the blog post author is the main developer of).
    - genpfault 1y ago
      > specifically the Mesa Zink driver https://docs.mesa3d.org/drivers/zink.html https://docs.mesa3d.org/drivers/zink.html
    - flohofwoe 1y ago
fulafel 1y ago
OpenGL in the form of WebGL is living its best life. It's the only way to ship portable 3D software across the desktop and mobile platforms without platform specific code paths, thanks to the API fragmentation and proprietary platform antics from our beloved vendors. In some years WebGPU may mature and start gaining parity (webgl took a looooong time to mature), and after that it'll still take more years for applications to switch given older hardware, the software inertia needed to port all the middleware over etc.
- m-schuetz 1y ago
  There is also the problem that WebGPU doesn't really add much except for compute shaders. Older WebGL apps have hardly any reason to port. Other problem is that WebGPU is even worse outdated than WebGL was at its release. When WebGL was released, it was maybe 5 years outdated. WebGPU somewhat came out in major desktop browsers this year, and by now it's something like 15 years behind the state of the art. OpenGL, which got de facto deprecated more than half a decade ago, is orders of magnitude more powerful with respect to hardware capabilities/features than WebGPU.
  - charlotte-fyi 1y ago
    This comparison is kind of sloppy, though. OpenGL on the desktop needs to be compared to a concrete WebGPU implementation. While it still lags behind state of the art, `wgpu` has many features on desktop that aren't in the standard. For example, they've started working on mesh shaders too: https://github.com/gfx-rs/wgpu/issues/7197 https://github.com/gfx-rs/wgpu/issues/7197. If you stick to only what's compatible with WebGL2 on the desktop you'd face similar limitations.
    - m-schuetz 1y ago
      I'm of course talking about WebGPU for web browsers, and I'd rather not use a graphics API like wgpu with uncertain support for the latest GPU features. Especially since wgpu went for the same paradigm as Vulkan, so it's not even that much better to use but you sacrifice lots of features. Also Vulkan seems to finally start fixing mistakes like render passes and pipelines, whereas WebGPU (and I guess wgpu?) went all in.
conradev 1y ago
Someone should tell Qualcomm then: https://www.qualcomm.com/developer/blog/2024/11/introducing-new-opn-cl-gpu-backend-llama-cpp-for-qualcomm-adreno-gpu https://www.qualcomm.com/developer/blog/2024/11/introducing-... I believe the llama.cpp Vulkan backend is inoperable on Adreno GPUs
- fulafel 1y ago
  That's OpenCL, not OpenGL.

m-schuetz 1y ago

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.

Cieric 1y ago

> It's officially deprecated in favor of Vulkan Can you provide a reference for this? I work in the GPU driver space (not on either of these apis), but from my understanding Vulkan wasn't meant to replace OpenGL, it was only introduced to give developers the chance at getting lower level in the hardware (still agnostic from the hardware, at least compared to compiling PTX/CUDA or against AMD's PAL directly, many still think they failed.) I would still highly advocate for developers using OpenGL or dx11 if their game/software doesn't need the capabilities of Vulkan or dx12. And even if you did, you might be able to get away with interop and do small parts with the lower api and leave everything else in the higher api. I will admit I don't like the trend of all the fancy new features only getting introduced into Vulkan and dx12, but I'm not sure how to change that trend.

ecshafer 1y ago
I only play with this stuff as a hobbiest. But OpenGL is way more simple than Vulkan I think. Vulkan is really really complicated to get some basic stuff going.
- marmarama 1y ago
  Which is as-designed. Vulkan (and DX12, and Metal) is a much more low-level API, precisely because that's what professional 3D engine developers asked for. Closer to the hardware, more control, fewer workarounds because the driver is doing something "clever" hidden behind the scenes. The tradeoff is greater complexity. Mere mortals are supposed to use a game engine, or a scene graph library (e.g. VulkanSceneGraph), or stick with OpenGL for now. The long-term future for OpenGL is to be implemented on top of Vulkan (specifically the Mesa Zink driver that the blog post author is the main developer of).
  - genpfault 1y ago
    > specifically the Mesa Zink driver https://docs.mesa3d.org/drivers/zink.html https://docs.mesa3d.org/drivers/zink.html
  - flohofwoe 1y ago

fulafel 1y ago

OpenGL in the form of WebGL is living its best life. It's the only way to ship portable 3D software across the desktop and mobile platforms without platform specific code paths, thanks to the API fragmentation and proprietary platform antics from our beloved vendors. In some years WebGPU may mature and start gaining parity (webgl took a looooong time to mature), and after that it'll still take more years for applications to switch given older hardware, the software inertia needed to port all the middleware over etc.

m-schuetz 1y ago
There is also the problem that WebGPU doesn't really add much except for compute shaders. Older WebGL apps have hardly any reason to port. Other problem is that WebGPU is even worse outdated than WebGL was at its release. When WebGL was released, it was maybe 5 years outdated. WebGPU somewhat came out in major desktop browsers this year, and by now it's something like 15 years behind the state of the art. OpenGL, which got de facto deprecated more than half a decade ago, is orders of magnitude more powerful with respect to hardware capabilities/features than WebGPU.
- charlotte-fyi 1y ago
  This comparison is kind of sloppy, though. OpenGL on the desktop needs to be compared to a concrete WebGPU implementation. While it still lags behind state of the art, `wgpu` has many features on desktop that aren't in the standard. For example, they've started working on mesh shaders too: https://github.com/gfx-rs/wgpu/issues/7197 https://github.com/gfx-rs/wgpu/issues/7197. If you stick to only what's compatible with WebGL2 on the desktop you'd face similar limitations.
  - m-schuetz 1y ago
    I'm of course talking about WebGPU for web browsers, and I'd rather not use a graphics API like wgpu with uncertain support for the latest GPU features. Especially since wgpu went for the same paradigm as Vulkan, so it's not even that much better to use but you sacrifice lots of features. Also Vulkan seems to finally start fixing mistakes like render passes and pipelines, whereas WebGPU (and I guess wgpu?) went all in.

conradev 1y ago

Someone should tell Qualcomm then: https://www.qualcomm.com/developer/blog/2024/11/introducing-new-opn-cl-gpu-backend-llama-cpp-for-qualcomm-adreno-gpu https://www.qualcomm.com/developer/blog/2024/11/introducing-... I believe the llama.cpp Vulkan backend is inoperable on Adreno GPUs

fulafel 1y ago
That's OpenCL, not OpenGL.