6 ms·

Although I'm not a fan of OpenGL's removal, I think it's somewhat misunderstood. OpenGL is an outdated design for modern GPUs. Its featureset and architecture i

by DCKing 7y ago

Although I'm not a fan of OpenGL's removal, I think it's somewhat misunderstood. OpenGL is an outdated design for modern GPUs. Its featureset and architecture is too high level, leading to more buggy drivers and complicated legacy support. There's two things you can do basically - keep OpenGL around in perpituity, or move the complexity and responsibility of it all to libraries. Apple has defined their single graphics API to be Metal, kind of but not quite like mainstream Linux where this has become Gallium3D (i.e. all open source drivers implement their OpenGL and Vulkan and sometimes even Direct3D support on top of Gallium3D). I fully expect OpenGL to be dropped from many future Linux drivers too. I'm actually looking forward to the day Linux drivers will go Vulkan only, as hopefully it allows things to get less buggy. Even when OpenGL gets fully removed from macOS, you can still use OpenGL. You can use Vulkan too. You just need a library for it, like ANGLE or MoltenVK. If that would have been Apple's communication, there'd be a lot less fuzz about this. By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's not working.

badsectoracula 7y ago
> OpenGL is an outdated design for modern GPUs. The thing is, in its entire lifetime OpenGL was never meant to be a GPU abstraction layer - that only happened during GeForce2's time (and only for Nvidia). Even SGI's implementation was doing a lot of stuff on the CPU (and SGI even had a pure CPU implementation). OpenGL was always meant to be a high lever immediate graphics API (immediate here meaning as opposed to retained/scene graph APIs like OpenInventor). > By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's not working. Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working.
- DCKing 7y ago
  It seems to me then that OpenGL should have been a library instead of a driver all along. Its original intent unfortunately has no bearing on what it has become in the meantime. > Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working. Well yeah that's what deprecated means. At the moment, developers have a bit longer to get on with the times though, so that's nice I guess.
  - rrss 7y ago
    > should have been a library instead of a driver all along This would have required there to be a lower-level interface that different vendors could all implement, which was not the case for early graphics hardware. In the decades since graphics hardware has all evolved to look more or less the same to SW (so vulkan became a nice fit), but that wasn't always the case.
- saagarjha 7y ago
  FWIW, OpenGL is quite broken. It works but it periodically glitches or does something weird in even minor point releases.
  - vortico 7y ago
    What you're describing has nothing to do with the OpenGL standard but of graphics drivers (OpenGL implementations).
    - saagarjha 7y ago
      Yes, I’m talking about Apple’s implementation of OpenGL.
- pjmlp 7y ago
  And I think it was a big failure not to adopt Iris Inventor as well. Every OpenGL newbie has to go through the rite of passage of assembling their own SDK for dealing with fonts, textures, materials, math, meshes,... Whereas all competing APIs provide such features out of the box on their SDKs, including the console ones. Plus there is this myth about portability, when any relatively big OpenGL application is full of extensions and multiple code paths to deal with OEM specific features, driver bugs or hardware glitches. Then there is the little issue that OpenGL, OpenGL ES and WebGL are only superficially alike.
quelsolaar 7y ago
My application, does precisely what i want in terms of graphics, and runs at 600FPS. Explain to me why my users would benefit from me spending months switching to a different API? Life is too short for that. The loosers in all this are the Mac users. The reason to support Mac is to be nice to the users, not because it makes financial sense. If apple is going to actively make it harder why bother?
- DCKing 7y ago
  > Explain to me why my users would benefit from me spending months switching to a different API? The idea is that leaving behind old APIs will benefit driver and system stability for the entire ecosystem, benefiting your users in other ways. You might disagree with that view, but Apple is not doing this out of spite alone. I'm not sure that switching to use a library like MoltenGL for this stuff would take months either, but you're in a better position to judge that I guess.
  - quelsolaar 7y ago
    Or Apple could do it! if its possible to support usigng a wrapper, Apple should make the wraper part of the API, why push the responsibility of backwards copatibility over to developers?
    - DCKing 7y ago
      If you want to argue Apple is handling this poorly from a community perspective, you'll find no argument with me. The reason Apple is doing this in this poor way is that they seem to want to push Metal as the answer. They want incentives for developers to move to Metal by making their lives more difficult on OpenGL, because even with libraries those libraries must be maintained and included. They don't want to bear responsibility for this legacy. I'm explaining, not defending. This is the direct opposite to the Linux ecosystem, where Gallium3D not only facilitates both OpenGL and Vulkan, but has had attempted Direct3D implementations in the past. Yet another case where Linux has the "everything and the kitchen sink approach", and Apple just flat out dictates a single choice to everybody. That attitude sometimes helps Apple, but sometimes it doesn't.
vbezhenar 7y ago
They could implement OpenGL API over Vulkan, so it's just a library, no need to touch drivers.
bepvte 7y ago
Gallium3D is a framework for building drivers, not a graphics API. The intel drivers do not use gallium3d (yet), and neither do nvidias.
overgard 7y ago
I think it would have been a lot more palatable if they hadn't gone off and made their own API (why not Vulkan?)
notfudplease 7y ago
This is blatantly false. You may be thinking about OpenGL 1.x and the fixed pipeline. Modern OpenGL is perfectly capable of running virtually every game and professional app out there. OpenGL does NOT work on macOS and hasn’t worked for a very long time. Apple only allows to use an ancient version of OpenGL, which is not really my definition of “working”. Nobody is going to ever remove OpenGL from Linux (or Windows) drivers. OpenGL/D3D powers everything there. Vulkan and Direct3D 12 are just the lowest level and are not a replacement for OpenGL nor Direct3D 11. Drivers may implement them on top of Vulkan/D3D12, but removing? Never. Finally, Apple has never told anybody to use MoltenVK because they don’t want you to. And I would not be surprised if they end up banning such layers if they find they get popular.
- pjmlp 7y ago
  Better start paying attention to what the Vulkan folks are doing, Khronos and friends haven been pushing for OpenGL deprecation for quite a while now. https://xdc2019.x.org/event/5/contributions/329/attachments/433/687/XDC2019-Zink-slide-deck.pdf https://xdc2019.x.org/event/5/contributions/329/attachments/..., 2nd slide This is just one example, here is a nice gathering at latest Reboot Develop Blue 2019 https://www.youtube.com/watch?v=hcgG1RQ-BJM https://www.youtube.com/watch?v=hcgG1RQ-BJM As for Windows, OpenGL ICD drivers only run in legacy Win32 mode, UWP and Win32 sandbox mode doesn't allow for ICD drivers.
ryandrake 7y ago
> OpenGL is an outdated design for modern GPUs. Its featureset and architecture is too high level, leading to more buggy drivers and complicated legacy support. This is only a problem for game developers who live right on the GPU hardware and need to squeeze absolutely all the performance out of it. Which is probably a small number of admittedly very important developers: Game engines and AAA studios. For the rest of developers who have more modest requirements, I don't really understand what "modern" graphics APIs provide, besides tons of extra boilerplate code and headaches. When I was a graphics programming newbie, it was great to have the whole fixed function pipeline all set up and ready for me to experiment and learn. If I had to learn from nothing on Vulkan, I'd probably have given up before the first 1000 lines. Drawing a triangle in OpenGL vs. Vulkan: http://sol.gfxile.net/temp/hellotriangle.png http://sol.gfxile.net/temp/hellotriangle.png It's so strange--in most of the software world, newer APIs and tools tend to be higher and higher level abstractions. "Modern" Electron apps run Javascript, HTML and CSS on an embedded browser which itself running on a high-level native toolkit which is probably written in C or C++, which compiles to assembly, etc. You can have a web server in one line of python. In contrast, the more modern graphics APIs get, the lower-level and more verbose they get.
- pjmlp 7y ago
  As one of those graphics developers that doesn't need to squeeze absolutely all the performance out of a GPU, I moved into middelware engines, where each API backend can be crazly optimized, while I have the productivity freedom to just ask to draw my scene, with a nicely organized set of meshes, materials and combined shaders, without feeling I am doing graphics programming with two sticks. The anti-managed bias on some Vulkan circles also doesn't help, specially when the OpenGL deprecation message keeps poping up in Vulkan related talks. Yes, using managed languages will take some performance out of Vulkan, but guess whose's fault it is when no other API gets offered as alternative, not everyone is jumping of joy to use C for graphics programming. And here Metal, DirectX, LibGNMN, NVN, WebGL, WebGPU take a much developer friendly attitude.

by DCKing 7y ago

badsectoracula 7y ago

> OpenGL is an outdated design for modern GPUs. The thing is, in its entire lifetime OpenGL was never meant to be a GPU abstraction layer - that only happened during GeForce2's time (and only for Nvidia). Even SGI's implementation was doing a lot of stuff on the CPU (and SGI even had a pure CPU implementation). OpenGL was always meant to be a high lever immediate graphics API (immediate here meaning as opposed to retained/scene graph APIs like OpenInventor). > By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's not working. Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working.

DCKing 7y ago
It seems to me then that OpenGL should have been a library instead of a driver all along. Its original intent unfortunately has no bearing on what it has become in the meantime. > Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working. Well yeah that's what deprecated means. At the moment, developers have a bit longer to get on with the times though, so that's nice I guess.
- rrss 7y ago
  > should have been a library instead of a driver all along This would have required there to be a lower-level interface that different vendors could all implement, which was not the case for early graphics hardware. In the decades since graphics hardware has all evolved to look more or less the same to SW (so vulkan became a nice fit), but that wasn't always the case.
saagarjha 7y ago
FWIW, OpenGL is quite broken. It works but it periodically glitches or does something weird in even minor point releases.
- vortico 7y ago
  What you're describing has nothing to do with the OpenGL standard but of graphics drivers (OpenGL implementations).
  - saagarjha 7y ago
    Yes, I’m talking about Apple’s implementation of OpenGL.
pjmlp 7y ago
And I think it was a big failure not to adopt Iris Inventor as well. Every OpenGL newbie has to go through the rite of passage of assembling their own SDK for dealing with fonts, textures, materials, math, meshes,... Whereas all competing APIs provide such features out of the box on their SDKs, including the console ones. Plus there is this myth about portability, when any relatively big OpenGL application is full of extensions and multiple code paths to deal with OEM specific features, driver bugs or hardware glitches. Then there is the little issue that OpenGL, OpenGL ES and WebGL are only superficially alike.

quelsolaar 7y ago

My application, does precisely what i want in terms of graphics, and runs at 600FPS. Explain to me why my users would benefit from me spending months switching to a different API? Life is too short for that. The loosers in all this are the Mac users. The reason to support Mac is to be nice to the users, not because it makes financial sense. If apple is going to actively make it harder why bother?

DCKing 7y ago
> Explain to me why my users would benefit from me spending months switching to a different API? The idea is that leaving behind old APIs will benefit driver and system stability for the entire ecosystem, benefiting your users in other ways. You might disagree with that view, but Apple is not doing this out of spite alone. I'm not sure that switching to use a library like MoltenGL for this stuff would take months either, but you're in a better position to judge that I guess.
- quelsolaar 7y ago
  Or Apple could do it! if its possible to support usigng a wrapper, Apple should make the wraper part of the API, why push the responsibility of backwards copatibility over to developers?
  - DCKing 7y ago
    If you want to argue Apple is handling this poorly from a community perspective, you'll find no argument with me. The reason Apple is doing this in this poor way is that they seem to want to push Metal as the answer. They want incentives for developers to move to Metal by making their lives more difficult on OpenGL, because even with libraries those libraries must be maintained and included. They don't want to bear responsibility for this legacy. I'm explaining, not defending. This is the direct opposite to the Linux ecosystem, where Gallium3D not only facilitates both OpenGL and Vulkan, but has had attempted Direct3D implementations in the past. Yet another case where Linux has the "everything and the kitchen sink approach", and Apple just flat out dictates a single choice to everybody. That attitude sometimes helps Apple, but sometimes it doesn't.

vbezhenar 7y ago

They could implement OpenGL API over Vulkan, so it's just a library, no need to touch drivers.

bepvte 7y ago

Gallium3D is a framework for building drivers, not a graphics API. The intel drivers do not use gallium3d (yet), and neither do nvidias.

overgard 7y ago

I think it would have been a lot more palatable if they hadn't gone off and made their own API (why not Vulkan?)

notfudplease 7y ago

This is blatantly false. You may be thinking about OpenGL 1.x and the fixed pipeline. Modern OpenGL is perfectly capable of running virtually every game and professional app out there. OpenGL does NOT work on macOS and hasn’t worked for a very long time. Apple only allows to use an ancient version of OpenGL, which is not really my definition of “working”. Nobody is going to ever remove OpenGL from Linux (or Windows) drivers. OpenGL/D3D powers everything there. Vulkan and Direct3D 12 are just the lowest level and are not a replacement for OpenGL nor Direct3D 11. Drivers may implement them on top of Vulkan/D3D12, but removing? Never. Finally, Apple has never told anybody to use MoltenVK because they don’t want you to. And I would not be surprised if they end up banning such layers if they find they get popular.

pjmlp 7y ago
Better start paying attention to what the Vulkan folks are doing, Khronos and friends haven been pushing for OpenGL deprecation for quite a while now. https://xdc2019.x.org/event/5/contributions/329/attachments/433/687/XDC2019-Zink-slide-deck.pdf https://xdc2019.x.org/event/5/contributions/329/attachments/..., 2nd slide This is just one example, here is a nice gathering at latest Reboot Develop Blue 2019 https://www.youtube.com/watch?v=hcgG1RQ-BJM https://www.youtube.com/watch?v=hcgG1RQ-BJM As for Windows, OpenGL ICD drivers only run in legacy Win32 mode, UWP and Win32 sandbox mode doesn't allow for ICD drivers.

ryandrake 7y ago

> OpenGL is an outdated design for modern GPUs. Its featureset and architecture is too high level, leading to more buggy drivers and complicated legacy support. This is only a problem for game developers who live right on the GPU hardware and need to squeeze absolutely all the performance out of it. Which is probably a small number of admittedly very important developers: Game engines and AAA studios. For the rest of developers who have more modest requirements, I don't really understand what "modern" graphics APIs provide, besides tons of extra boilerplate code and headaches. When I was a graphics programming newbie, it was great to have the whole fixed function pipeline all set up and ready for me to experiment and learn. If I had to learn from nothing on Vulkan, I'd probably have given up before the first 1000 lines. Drawing a triangle in OpenGL vs. Vulkan: http://sol.gfxile.net/temp/hellotriangle.png http://sol.gfxile.net/temp/hellotriangle.png It's so strange--in most of the software world, newer APIs and tools tend to be higher and higher level abstractions. "Modern" Electron apps run Javascript, HTML and CSS on an embedded browser which itself running on a high-level native toolkit which is probably written in C or C++, which compiles to assembly, etc. You can have a web server in one line of python. In contrast, the more modern graphics APIs get, the lower-level and more verbose they get.

pjmlp 7y ago
As one of those graphics developers that doesn't need to squeeze absolutely all the performance out of a GPU, I moved into middelware engines, where each API backend can be crazly optimized, while I have the productivity freedom to just ask to draw my scene, with a nicely organized set of meshes, materials and combined shaders, without feeling I am doing graphics programming with two sticks. The anti-managed bias on some Vulkan circles also doesn't help, specially when the OpenGL deprecation message keeps poping up in Vulkan related talks. Yes, using managed languages will take some performance out of Vulkan, but guess whose's fault it is when no other API gets offered as alternative, not everyone is jumping of joy to use C for graphics programming. And here Metal, DirectX, LibGNMN, NVN, WebGL, WebGPU take a much developer friendly attitude.