5 ms·

Man, since the departure from OpenGL/OpenGL ES, graphics programming is such a pain in the butt. It's totally unfun and ridiculous.

01HNNWZ0MV43FF 2y ago
I finally switched to WebGL 2, I think, to get nicer shadow maps. I'll ride that as far as I can. personally I liked gles2 a lot. Everything ran it.
- deleted 2y ago
  [deleted]
davexunit 2y ago
The fragmentation has been really frustrating but if things like WebGPU and SDL GPU become well supported it will make doing modern graphics programming mostly pleasant. I love/hate OpenGL and will miss it in a strange way.
- deleted 2y ago
  [deleted]
- seivan 2y ago
  [dead]
jms55 2y ago
What part do you dislike? If it's the complexity of newer APIs (Vulkan in 8 years old at this point, DirectX12 9 years), then you might like WebGPU or any of the other userspace graphics APIs such as blade or sdl3 that have been invented over the past few years.
- unconed 2y ago
  Not OP, but IMO the real issue is pretending graphics is still about executing individual draw calls of meshes which map 1-to-1 to visible objects. It's not true anymore, because you have all sorts of secondary rendering (e.g. shadow maps, or pre-passes), as well as temporal accumulation. These all need their own unique shaders. With meshlets and/or nanite, culling becomes a cross-object issue. With deferred rendering, separate materials require careful set up. So now the idea that a dev can just bring their own shaders to plug into an existing pipeline kind of falls apart. You need a whole layer of infrastructure on top, be it node graphs, shader closures, etc. And dispatch glue to go along with it. This is all true even with WebGPU where you don't have to deal with synchronization and mutexes. Just a shit show all around tbh. Rendering APIs have not kept up with rendering techniques. The driver devs just threw up their hands and said "look, it's a nightmare to keep up the facade of old-school GL, so why don't you do it instead".
  - andrewmcwatters 2y ago
    Yep... You nailed it. It really bums me out. There's a lot you can do with simple 90s era graphics programming while still using the newer APIs, but you'll hit bottlenecks very quickly, or run into architectural issues as soon as you want to implement modern rendering techniques.
  - jms55 2y ago
    > executing individual draw calls of meshes which map 1-to-1 to visible objects. This has not been true since deferred shading became popular around 2008. Shadow maps were around much earlier than that even. There's a reason the 1:1 draw:object API has fallen out of popularity - it doesn't scale well, be it CPU overhead, lighting, culling and geometry processing, etc. That said, you of course still can do this if you want to. Draw calls and vertex buffers haven't gone away by any means. > So now the idea that a dev can just bring their own shaders to plug into an existing pipeline kind of falls apart. You need a whole layer of infrastructure on top, be it node graphs, shader closures, etc. And dispatch glue to go along with it. That's the job of rendering engines, not graphics APIs. If you want to work at that layer, then you use a rendering/game engine that provides the tooling for technical artists. If you _are_ the rendering/game engine, then you're thankful for the increased level of control modern graphics APIs provide you to be able to realize better looking, higher performing (more stuff is possible), and more flexible tools to provide your tech artists with. > This is all true even with WebGPU where you don't have to deal with synchronization and mutexes. Just a shit show all around tbh. Rendering APIs have not kept up with rendering techniques. The driver devs just threw up their hands and said "look, it's a nightmare to keep up the facade of old-school GL, so why don't you do it instead". Users of the drivers got fed up with them being buggy, slow, and limited. The industry's response was to move as much code as possible out of the driver and into user space, exposing more control and low-level details to userspace. That way, you would never be bottlenecked by the driver, be it performance or bugs. The industry has realized time and time again that hardware companies are often bad at software, and it would be better to let third parties handle that aspect. The real failure of of the graphics industry imo was Vulkan 1.0 trying to cater to old mobile devices and modern desktop devices simultaneously, and much worse, never starting a large community project to communally develop a higher-level graphics API until WebGPU (which itself is underfunded). Even then its higher-level nature is largely a byproduct of wanting to enforce safety on untrusted webapps. But yes, even WebGPU is still more complicated than OpenGL 2. If you find graphics APIs too much work, you're not their target audience and you should be using a higher level API.
johnnyanmac 2y ago
That's more or less how graphics programming evolved over the last 20 years. Give up conviniences for the more performance, using as much control as GPU vendors would allow. It's basically inaccessible unless you're studying it in academia or employed in the few domains that require that power. This also sadly means that most tools to help navigate these are probably also trapped in some studio codebases. I remember those promises with Vulkan 1.0 where you could potentially just wait until others would make some boilerplate abstraction so other could learn graphics programming before diving deep down into every nitty gritty detail. I haven't looked extensively for that, but nothing came on my radar while navigating through learning Vulkan.
alkonaut 2y ago
Not at all. OpenGL had that get-something-done quickly feel but it was riddled with limitations and unnecessary complexity. DX12/Vulkan means you do 2000 lines of boilerplate to get anywhere. WebGPU is actually a nice step back towards OpenGL. You can get off the ground much faster, while still being modern in the way the APIs work.

01HNNWZ0MV43FF 2y ago

I finally switched to WebGL 2, I think, to get nicer shadow maps. I'll ride that as far as I can. personally I liked gles2 a lot. Everything ran it.

deleted 2y ago
[deleted]

davexunit 2y ago

The fragmentation has been really frustrating but if things like WebGPU and SDL GPU become well supported it will make doing modern graphics programming mostly pleasant. I love/hate OpenGL and will miss it in a strange way.

deleted 2y ago
[deleted]
seivan 2y ago
[dead]

jms55 2y ago

What part do you dislike? If it's the complexity of newer APIs (Vulkan in 8 years old at this point, DirectX12 9 years), then you might like WebGPU or any of the other userspace graphics APIs such as blade or sdl3 that have been invented over the past few years.

unconed 2y ago
Not OP, but IMO the real issue is pretending graphics is still about executing individual draw calls of meshes which map 1-to-1 to visible objects. It's not true anymore, because you have all sorts of secondary rendering (e.g. shadow maps, or pre-passes), as well as temporal accumulation. These all need their own unique shaders. With meshlets and/or nanite, culling becomes a cross-object issue. With deferred rendering, separate materials require careful set up. So now the idea that a dev can just bring their own shaders to plug into an existing pipeline kind of falls apart. You need a whole layer of infrastructure on top, be it node graphs, shader closures, etc. And dispatch glue to go along with it. This is all true even with WebGPU where you don't have to deal with synchronization and mutexes. Just a shit show all around tbh. Rendering APIs have not kept up with rendering techniques. The driver devs just threw up their hands and said "look, it's a nightmare to keep up the facade of old-school GL, so why don't you do it instead".
- andrewmcwatters 2y ago
  Yep... You nailed it. It really bums me out. There's a lot you can do with simple 90s era graphics programming while still using the newer APIs, but you'll hit bottlenecks very quickly, or run into architectural issues as soon as you want to implement modern rendering techniques.
- jms55 2y ago
  > executing individual draw calls of meshes which map 1-to-1 to visible objects. This has not been true since deferred shading became popular around 2008. Shadow maps were around much earlier than that even. There's a reason the 1:1 draw:object API has fallen out of popularity - it doesn't scale well, be it CPU overhead, lighting, culling and geometry processing, etc. That said, you of course still can do this if you want to. Draw calls and vertex buffers haven't gone away by any means. > So now the idea that a dev can just bring their own shaders to plug into an existing pipeline kind of falls apart. You need a whole layer of infrastructure on top, be it node graphs, shader closures, etc. And dispatch glue to go along with it. That's the job of rendering engines, not graphics APIs. If you want to work at that layer, then you use a rendering/game engine that provides the tooling for technical artists. If you _are_ the rendering/game engine, then you're thankful for the increased level of control modern graphics APIs provide you to be able to realize better looking, higher performing (more stuff is possible), and more flexible tools to provide your tech artists with. > This is all true even with WebGPU where you don't have to deal with synchronization and mutexes. Just a shit show all around tbh. Rendering APIs have not kept up with rendering techniques. The driver devs just threw up their hands and said "look, it's a nightmare to keep up the facade of old-school GL, so why don't you do it instead". Users of the drivers got fed up with them being buggy, slow, and limited. The industry's response was to move as much code as possible out of the driver and into user space, exposing more control and low-level details to userspace. That way, you would never be bottlenecked by the driver, be it performance or bugs. The industry has realized time and time again that hardware companies are often bad at software, and it would be better to let third parties handle that aspect. The real failure of of the graphics industry imo was Vulkan 1.0 trying to cater to old mobile devices and modern desktop devices simultaneously, and much worse, never starting a large community project to communally develop a higher-level graphics API until WebGPU (which itself is underfunded). Even then its higher-level nature is largely a byproduct of wanting to enforce safety on untrusted webapps. But yes, even WebGPU is still more complicated than OpenGL 2. If you find graphics APIs too much work, you're not their target audience and you should be using a higher level API.

johnnyanmac 2y ago

That's more or less how graphics programming evolved over the last 20 years. Give up conviniences for the more performance, using as much control as GPU vendors would allow. It's basically inaccessible unless you're studying it in academia or employed in the few domains that require that power. This also sadly means that most tools to help navigate these are probably also trapped in some studio codebases. I remember those promises with Vulkan 1.0 where you could potentially just wait until others would make some boilerplate abstraction so other could learn graphics programming before diving deep down into every nitty gritty detail. I haven't looked extensively for that, but nothing came on my radar while navigating through learning Vulkan.

alkonaut 2y ago

Not at all. OpenGL had that get-something-done quickly feel but it was riddled with limitations and unnecessary complexity. DX12/Vulkan means you do 2000 lines of boilerplate to get anywhere. WebGPU is actually a nice step back towards OpenGL. You can get off the ground much faster, while still being modern in the way the APIs work.