6 ms·

> 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

by 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
    > fewer workarounds because the driver is doing something "clever" hidden behind the scenes. I would be very surprised if current Vulkan drivers are any different in this regard, and if yes then probably only because Vulkan isn't as popular as D3D for PC games. Vulkan is in a weird place that it promised a low-level explicit API close to the hardware, but then still doesn't really match any concrete GPU architecture and it still needs to abstract over very different GPU architectures. At the very least there should have been different APIs for desktop and mobile GPUs (not that the GL vs GLES split was great, but at least that way the requirements for mobile GPUs don't hold back the desktop API). And then there's the issue that also ruined OpenGL: the vendor extension mess.
  - m-schuetz 1y ago
    > Closer to the hardware To what hardware? Ancient desktop GPUs vs modern desktop GPUs? Ancient smartphones? Modern smartphones? Consoles? Vulkan is an abstraction of a huge set of diverging hardware architectures. And a pretty bad one, on my opinion. If you need to make an abstraction due to fundamentally different hardware, then at least make an abstraction that isn't terribly overengineered for little to no gain.
    - fingerlocks 1y ago
      100%. Metal is actually self-described as a high level graphics library for this very reason. I’ve never actually used it on non-Apple hardware, but the abstractions for vendor support is there. And they are definitely abstract. There is no real getting-your-hands-dirty exposure of the underlying hardware
      - dagmx 1y ago
        Metal does have to support AMD and Intel GPUs for another year after all, and had to support NVIDIA for a hot minute too.
        fingerlocks 1y ago
        Wow, what a brain fart. So much of metal has improved since M-series, I just forgot it was even the same framework entirely. Even the stack is different now that we have metal cpp and swift++ interop with unified memory access.
    - MountainTheme12 1y ago
      Closer to AMD and mobile hardware. We got abominations like monolithic pipelines and layout transition thanks to the first, and render passes thanks to the latter. Luckily all of these are out or on their way out.
      - pjmlp 1y ago
        Not really, other than on desktops, because as we all know mobile hardware gets the drivers it gets on release date, and that's it. Hence why on Android, even with Google nowadays enforcing Vulkan, if you want to deal with a less painful experience in driver bugs, better stick with OpenGL ES, outside Pixel and Samsung phones.
flohofwoe 1y ago
> Can you provide a reference for this? The last OpenGL release 4.6 was in 2017... I think that speaks for itself ;) And at least on macOS, OpenGL is officially deprecated, stuck at 4.1 and is also quickly rotting (despite running on top of Metal now - but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation).
- aj_hackman 1y ago
  I've never been able to successfully create a GL context > version 2.1, or invoke the GLSL compiler. As a sidenote, I've very much enjoyed your blog, and developed a similar handle system as yours around the same time. Mine uses 32 bits though - 15 for index, 1 for misc stuff, 8 for random key, and 8 for object type :^)
  - jlokier 1y ago
    Recent versions of macOS will provide either an OpenGL 2.1 context or OpenGL 4.1 context, depending on how you request the context. You have to request a 3.2+ core profile, and not use X11 or the glX* functions. From macOS 10.7 to 10.9, you'd get an OpenGL 3.2 context. As OpenGL 4.1 is backward compatible to OpenGL 3.2, it's fine that the same code gets OpenGL 4.1 now. Basically, macOS will provide an "old" API to programs that need it, which is fixed at 2.1, and a "modern" API to programs that know how to ask for it, which has settled at 4.1 and is unlikely to change. OpenGL 4.1 is harmonised with OpenGL ES 2.0. Almost the same rendering model, features, extensions, etc. On iOS, iPadOS etc you can use OpenGL ES 2.0, and no version of OpenGL (non-ES), so my guess is that's why macOS settled on OpenGL 4.1. Both platforms offer the same OpenGL rendering features, but through slightly different APIs. But if you request 4.1 over GLX (which uses X11/Xorg/XQuartz), the X11 code only supports OpenGL 2.1. For example, if you're porting some Linux code or other GLX examples over. Unfortunately, the GLX limitation is probably just due to the Xorg-based XQuartz being open source but only minimally maintained since before OpenGL 3.2 was added to macOS. XQuartz uses Xorg and Mesa, which have all the bindings for 4.1, but some of them are not quite wired up.
- fulafel 1y ago
  That's not "OpenGL is officially deprecated".
aj_hackman 1y ago
The universal narrative around OpenGL is that it's deprecated, so I assumed that came with a thumbs-up from Khronos. In any case, I'm not holding my breath for GL > 4.6.
jplusequalt 1y ago
I think Vulkan was originally called OpenGL Next. Furthermore, Vulkan's verbosity allows for a level of control of the graphics pipeline you simply can't have with OpenGL, on top of having built in support for things like dynamic rendering, bindless descriptors, push constants, etc. Those are the main reasons IMO why most people say it's deprecated.

by Cieric 1y ago

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
  > fewer workarounds because the driver is doing something "clever" hidden behind the scenes. I would be very surprised if current Vulkan drivers are any different in this regard, and if yes then probably only because Vulkan isn't as popular as D3D for PC games. Vulkan is in a weird place that it promised a low-level explicit API close to the hardware, but then still doesn't really match any concrete GPU architecture and it still needs to abstract over very different GPU architectures. At the very least there should have been different APIs for desktop and mobile GPUs (not that the GL vs GLES split was great, but at least that way the requirements for mobile GPUs don't hold back the desktop API). And then there's the issue that also ruined OpenGL: the vendor extension mess.
- m-schuetz 1y ago
  > Closer to the hardware To what hardware? Ancient desktop GPUs vs modern desktop GPUs? Ancient smartphones? Modern smartphones? Consoles? Vulkan is an abstraction of a huge set of diverging hardware architectures. And a pretty bad one, on my opinion. If you need to make an abstraction due to fundamentally different hardware, then at least make an abstraction that isn't terribly overengineered for little to no gain.
  - fingerlocks 1y ago
    100%. Metal is actually self-described as a high level graphics library for this very reason. I’ve never actually used it on non-Apple hardware, but the abstractions for vendor support is there. And they are definitely abstract. There is no real getting-your-hands-dirty exposure of the underlying hardware
    - dagmx 1y ago
      Metal does have to support AMD and Intel GPUs for another year after all, and had to support NVIDIA for a hot minute too.
      - fingerlocks 1y ago
        Wow, what a brain fart. So much of metal has improved since M-series, I just forgot it was even the same framework entirely. Even the stack is different now that we have metal cpp and swift++ interop with unified memory access.
  - MountainTheme12 1y ago
    Closer to AMD and mobile hardware. We got abominations like monolithic pipelines and layout transition thanks to the first, and render passes thanks to the latter. Luckily all of these are out or on their way out.
    - pjmlp 1y ago
      Not really, other than on desktops, because as we all know mobile hardware gets the drivers it gets on release date, and that's it. Hence why on Android, even with Google nowadays enforcing Vulkan, if you want to deal with a less painful experience in driver bugs, better stick with OpenGL ES, outside Pixel and Samsung phones.

flohofwoe 1y ago

> Can you provide a reference for this? The last OpenGL release 4.6 was in 2017... I think that speaks for itself ;) And at least on macOS, OpenGL is officially deprecated, stuck at 4.1 and is also quickly rotting (despite running on top of Metal now - but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation).

aj_hackman 1y ago
I've never been able to successfully create a GL context > version 2.1, or invoke the GLSL compiler. As a sidenote, I've very much enjoyed your blog, and developed a similar handle system as yours around the same time. Mine uses 32 bits though - 15 for index, 1 for misc stuff, 8 for random key, and 8 for object type :^)
- jlokier 1y ago
  Recent versions of macOS will provide either an OpenGL 2.1 context or OpenGL 4.1 context, depending on how you request the context. You have to request a 3.2+ core profile, and not use X11 or the glX* functions. From macOS 10.7 to 10.9, you'd get an OpenGL 3.2 context. As OpenGL 4.1 is backward compatible to OpenGL 3.2, it's fine that the same code gets OpenGL 4.1 now. Basically, macOS will provide an "old" API to programs that need it, which is fixed at 2.1, and a "modern" API to programs that know how to ask for it, which has settled at 4.1 and is unlikely to change. OpenGL 4.1 is harmonised with OpenGL ES 2.0. Almost the same rendering model, features, extensions, etc. On iOS, iPadOS etc you can use OpenGL ES 2.0, and no version of OpenGL (non-ES), so my guess is that's why macOS settled on OpenGL 4.1. Both platforms offer the same OpenGL rendering features, but through slightly different APIs. But if you request 4.1 over GLX (which uses X11/Xorg/XQuartz), the X11 code only supports OpenGL 2.1. For example, if you're porting some Linux code or other GLX examples over. Unfortunately, the GLX limitation is probably just due to the Xorg-based XQuartz being open source but only minimally maintained since before OpenGL 3.2 was added to macOS. XQuartz uses Xorg and Mesa, which have all the bindings for 4.1, but some of them are not quite wired up.
fulafel 1y ago
That's not "OpenGL is officially deprecated".

aj_hackman 1y ago

The universal narrative around OpenGL is that it's deprecated, so I assumed that came with a thumbs-up from Khronos. In any case, I'm not holding my breath for GL > 4.6.

jplusequalt 1y ago

I think Vulkan was originally called OpenGL Next. Furthermore, Vulkan's verbosity allows for a level of control of the graphics pipeline you simply can't have with OpenGL, on top of having built in support for things like dynamic rendering, bindless descriptors, push constants, etc. Those are the main reasons IMO why most people say it's deprecated.