3 ms·

> 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 official

> 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".
- flohofwoe 1y ago
  In the end, if nobody is maintaining the OpenGL standard, implementations and tooling it doesn't matter much whether it is officially deprecated or just abandondend.
  - fulafel 1y ago
    .. but people ARE maintaining the implementations and tooling even if the spec might not be getting new features aside from extensions. There's a difference. Look at Mesa release notes for example, there's a steady stream of driver feature work and bugfixes for GL: https://docs.mesa3d.org/relnotes/25.2.0.html https://docs.mesa3d.org/relnotes/25.2.0.html (search for "gl_") A slow moving graphics API is a good thing for many uses. People are writing new OpenGL code all the time. See eg HN story sumbmissions: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=opengl&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
    - coffeeaddict1 1y ago
      > A slow moving graphics API is a good thing for many uses. It's not slow moving. It's completely frozen. The Mesa guys are the only ones actually fixing bugs and improving implementations, but the spec is completely frozen and unmaintained. Apple, Microsoft and Google don't really care if OpenGL works well on their platforms.
      - jcelerier 1y ago
        > the spec is completely frozen and unmaintained. but, literally this article is about something new that was added to the OpenGL spec
        Delk 1y ago
josefx 1y ago
> but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation In other words nothing changed. The OpengGL standard had been well past 4.1 for years when Apple released Metal. People working with various 3D tools had to disable system integrity checks to install working drivers from NVIDIA to replace whatever Apple shipped by default.

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".

flohofwoe 1y ago
In the end, if nobody is maintaining the OpenGL standard, implementations and tooling it doesn't matter much whether it is officially deprecated or just abandondend.
- fulafel 1y ago
  .. but people ARE maintaining the implementations and tooling even if the spec might not be getting new features aside from extensions. There's a difference. Look at Mesa release notes for example, there's a steady stream of driver feature work and bugfixes for GL: https://docs.mesa3d.org/relnotes/25.2.0.html https://docs.mesa3d.org/relnotes/25.2.0.html (search for "gl_") A slow moving graphics API is a good thing for many uses. People are writing new OpenGL code all the time. See eg HN story sumbmissions: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=opengl&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
  - coffeeaddict1 1y ago
    > A slow moving graphics API is a good thing for many uses. It's not slow moving. It's completely frozen. The Mesa guys are the only ones actually fixing bugs and improving implementations, but the spec is completely frozen and unmaintained. Apple, Microsoft and Google don't really care if OpenGL works well on their platforms.
    - jcelerier 1y ago
      > the spec is completely frozen and unmaintained. but, literally this article is about something new that was added to the OpenGL spec
      - Delk 1y ago

josefx 1y ago

> but I don't think anybody at Apple is doing serious maintenance work on their OpenGL implementation In other words nothing changed. The OpengGL standard had been well past 4.1 for years when Apple released Metal. People working with various 3D tools had to disable system integrity checks to install working drivers from NVIDIA to replace whatever Apple shipped by default.