4 ms·

Then again, it's hard to make a case for not learning OGL. You still need to learn all the concepts whether you'd end up using Vulkan or Metal or whatnot. At w

by sham1 3y ago

Then again, it's hard to make a case for not learning OGL. You still need to learn all the concepts whether you'd end up using Vulkan or Metal or whatnot. At worst you'd end up having to use an OpenGL middleware thing in the middle of you and the lower abstraction level API. Like yes, OpenGL is crufty. It's also just not good in many ways, but in many ways it's simple. The lessons learnt from it also informed Khronos on the design of Vulkan, so even for that, it's nice to be able to see just where some of the design decisions come from. Also, not everyone develops for Apple and so their deprecation is less compelling than, say, Khronos officially stopping development on the API ;)

jsheard 3y ago
Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. > Also, not everyone develops for Apple and so their deprecation is less compelling than, say, Khronos officially stopping development on the API ;) Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened.
- winterismute 3y ago
  > Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. While this is true, for somebody who is starting from scratch there is a lot to learn before getting to the level at which thinking in terms of PSO is important, and it can be easier to get there via OpenGL, which btw still teaches you a decent chunk of GPU-friendly patterns (assuming of course we are talking about "modern" OpenGL and not display lists and such...). Also, with a good command of OpenGL, one can start trying to understand and re-implement rendering techniques spanning from deferred/forward+/clustered lighting, the various shadowing techniques and even HW raytracing eg. via the GLSL_NV_ray_tracingextension, which is - in my opinion - the more important side of learning GPU-accelerated rendering.
  - detourdog 3y ago
    What I think is important about this approach is that when OpenGL's cruft appears it is in a technical context. This provides the oppertunity for one to develop a better technical understanding of what is going on with their project and the targeted goals.
- sham1 3y ago
  > Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. Well sure, but as the other commenter pointed out, there's a lot of stuff you'd have to learn about how GPUs and 3D rendering with them actually works, before ever getting to concepts such as PSOs. Like think just the kind of thinking that you'd have to go through just to get a handle on things such as how shaders work, how to pack the data so that it can be efficiently used from the shader, uploading textures and so on. And for these kinds of things, OpenGL is as good a learning platform as any. > Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened. That's what I'm saying tho. Khronos has stopped OpenGL development, which is a way more prescient and compelling reason to not use the API (aside from if you're targeting more "legacy" hardware that doesn't support Vulkan, like you might if you're developing a Wayland compositor, for example, where you might still like some 3D hardware acceleration to complement hardware planes), than the idea that because Apple doesn't support it, it shouldn't be used. OpenGL was, after all, always a 2nd-class citizen on Apple. Even back in the OpenGL 3 days, Apple got stuck in OGL 2 for whatever reason. Oh, and at least with Mesa's Zink[0], you can absolutely use OpenGL even if your hardware natively only support Vulkan. That's not a problem. [0]: <https://docs.mesa3d.org/drivers/zink.html https://docs.mesa3d.org/drivers/zink.html>
- cmovq 3y ago
  > Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works This is definitely true, but newer OpenGL gives you indirect rendering and bindless textures which is about as good as you can get even in Vulkan in terms of driver overhead. Regardless, much like picking a programming language to learn, it doesn’t really matter what you start with. Most concepts transfer over and any graphics programmer will know more than one graphics API anyways. It’s funny you mention PSOs because there is now an extension to not use them in Vulkan (VK_EXT_shader_object) because it turns out it’s not how the hardware works [1]. [1]: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_shader_object.adoc#1-problem-statement https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...
vieinfernale 3y ago
I am still a novice in this world of graphics programming. Not exactly only graphics, but VFX and digital sculpting. Is not OpenGL a good starting point if you want to transition to Metal or Vulkan later on? If not, should I seek out the "new flavor" to learn graphics?
- mellinoe 3y ago
  If your goal is to learn Metal, then just start with Metal. It's a significantly better-designed API. On top of that, if you're developing on an Apple device then you'll have a decent debugging experience with Metal, as opposed to OpenGL where you'll get... nothing last I checked (but it's been a while).

by sham1 3y ago

jsheard 3y ago

Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. > Also, not everyone develops for Apple and so their deprecation is less compelling than, say, Khronos officially stopping development on the API ;) Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened.

winterismute 3y ago
> Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. While this is true, for somebody who is starting from scratch there is a lot to learn before getting to the level at which thinking in terms of PSO is important, and it can be easier to get there via OpenGL, which btw still teaches you a decent chunk of GPU-friendly patterns (assuming of course we are talking about "modern" OpenGL and not display lists and such...). Also, with a good command of OpenGL, one can start trying to understand and re-implement rendering techniques spanning from deferred/forward+/clustered lighting, the various shadowing techniques and even HW raytracing eg. via the GLSL_NV_ray_tracingextension, which is - in my opinion - the more important side of learning GPU-accelerated rendering.
- detourdog 3y ago
  What I think is important about this approach is that when OpenGL's cruft appears it is in a technical context. This provides the oppertunity for one to develop a better technical understanding of what is going on with their project and the targeted goals.
sham1 3y ago
> Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works, so you end up having to unlearn bad habits which OpenGLs messy abstractions enable. OpenGL won't teach you to think in terms of PSOs, for example. Well sure, but as the other commenter pointed out, there's a lot of stuff you'd have to learn about how GPUs and 3D rendering with them actually works, before ever getting to concepts such as PSOs. Like think just the kind of thinking that you'd have to go through just to get a handle on things such as how shaders work, how to pack the data so that it can be efficiently used from the shader, uploading textures and so on. And for these kinds of things, OpenGL is as good a learning platform as any. > Have they not stopped? The last major update to OpenGL was six years ago, around the time Vulkan went public. I recall there initially being talk of OpenGL continuing to be developed alongside Vulkan but that just hasn't happened. That's what I'm saying tho. Khronos has stopped OpenGL development, which is a way more prescient and compelling reason to not use the API (aside from if you're targeting more "legacy" hardware that doesn't support Vulkan, like you might if you're developing a Wayland compositor, for example, where you might still like some 3D hardware acceleration to complement hardware planes), than the idea that because Apple doesn't support it, it shouldn't be used. OpenGL was, after all, always a 2nd-class citizen on Apple. Even back in the OpenGL 3 days, Apple got stuck in OGL 2 for whatever reason. Oh, and at least with Mesa's Zink[0], you can absolutely use OpenGL even if your hardware natively only support Vulkan. That's not a problem. [0]: <https://docs.mesa3d.org/drivers/zink.html https://docs.mesa3d.org/drivers/zink.html>
cmovq 3y ago
> Part of the problem is that many of the concepts OpenGL teaches you have no bearing on how modern hardware actually works This is definitely true, but newer OpenGL gives you indirect rendering and bindless textures which is about as good as you can get even in Vulkan in terms of driver overhead. Regardless, much like picking a programming language to learn, it doesn’t really matter what you start with. Most concepts transfer over and any graphics programmer will know more than one graphics API anyways. It’s funny you mention PSOs because there is now an extension to not use them in Vulkan (VK_EXT_shader_object) because it turns out it’s not how the hardware works [1]. [1]: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_shader_object.adoc#1-problem-statement https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...

vieinfernale 3y ago

I am still a novice in this world of graphics programming. Not exactly only graphics, but VFX and digital sculpting. Is not OpenGL a good starting point if you want to transition to Metal or Vulkan later on? If not, should I seek out the "new flavor" to learn graphics?

mellinoe 3y ago
If your goal is to learn Metal, then just start with Metal. It's a significantly better-designed API. On top of that, if you're developing on an Apple device then you'll have a decent debugging experience with Metal, as opposed to OpenGL where you'll get... nothing last I checked (but it's been a while).