5 ms·

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 t

by 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
    >If you find graphics APIs too much work, you're not their target audience and you should be using a higher level API. That's a pretty sad state of affairs given the "audience" is shrinking by the day. And then later those graphics programmers leave/get laid off by Unity/Epic/AAA Studio with a custom engine and they wonder why they can't find any DX12/Vulkan engineers to their satisfaction. For the lifeblood of the industry, tools need to also be learnable by hobbyists. At least, if you don't want to spend 6-12 months training your graphics programmers yourself. The courses I peeked at at my Alma mater (when Vulkan was still brand new) are still using OpenGL 3 to teach, so it doesn't sound like Universities are picking up the slack.
    - jms55 2y ago
      Vulkan/DX12 _are_ learnable by hobbyists. This was a pretty popular post here on HN 4 months ago of someone learning Vulkan and making an engine in it https://news.ycombinator.com/item?id=40595741 https://news.ycombinator.com/item?id=40595741. Universities usually teach theory, oftentimes in the form of a raytracer on the CPU, or like you said a simple OpenGL renderer using some prebuilt abstractions. I don't think it really makes sense for them to teach how to use Vulkan well or how to make a fast renderer, the details of that often change quickly year by year anyways. > That's a pretty sad state of affairs given the "audience" is shrinking by the day. And then later those graphics programmers leave/get laid off by Unity/Epic/AAA Studio with a custom engine and they wonder why they can't find any DX12/Vulkan engineers to their satisfaction. That's more a symptom of how garbage working in the game development industry is, and less about any underlying technology. There's a reason I work on a game engine for fun, as my hobby, and not professionally despite having the option to do so. Everyone I spoke to in the industry talks about how terrible the working conditions are. A professional graphics developer I recently talked to summed it up well - everyone needs a game engine, but no one wants to pay people to make and maintain one.
      - johnnyanmac 2y ago
        >Vulkan/DX12 _are_ learnable by hobbyists. I did see that post. It is commendable, but we should also note that that author has 15 years of experience in tech and was already a solo developer as a hobbyist. It can be easy to forget that there's a lot of cruft and API to grok through for these things, things potentially out of the scope of students and juniors who haven't had to navigate codebases with millions of LoC in various states of disarray. That speaks more to our ability to tolerate the chaos than the learnability of the API. >I don't think it really makes sense for them to teach how to use Vulkan well or how to make a fast renderer, the details of that often change quickly year by year anyways From a learners' POV I agree. From the industry's point of view they want someone who can jump into the fray with minimal training. And we both hopefully understand that theory doesn't necessarily correlate to real world experience. So there's some critical bridge that is missing on some side that as of now industry just expects potential programmers to learn in their free time somehow. Which in and of itself still isn't a trivial matter. Because so much of this knowledge is tribal wisdom carried by industry. So you see where the issues add up. You'll find breadcrumbs here and there scattered across the net, but this is only adding more obstacles for people to hit that bar. >That's more a symptom of how garbage working in the game development industry is, and less about any underlying technology. There's a reason I work on a game engine for fun, as my hobby, and not professionally despite having the option to do so. Everyone I spoke to in the industry talks about how terrible the working conditions are. I can concur with that as someone in the industry. But there's not really that many places you can go to work professionally if you're not in games: - animation renderers (Pixar, Dreamworks, Illumination. maybe Laika), but the reputation in that industry isn't much better - various research firms that look more for PhD's if anything. Maybe some Masters students. So you're basically in acedemia land (which is known for its lack of pay, even compared to games). - and of course, the GPU companies. Nvidia, Intel, and AMD among a few others. It's a very niche field that requires very specialized knowledge. If no one's offering training nor even an above average pay for that, what are you going to do? If left unchecked, these kinds of fields will be the first to suffer the brain drain as pioneers start to retire or die off. >A professional graphics developer I recently talked to summed it up well - everyone needs a game engine, but no one wants to pay people to make and maintain one. I'd say that's the 2020's in general, yes. Everyone wants senior+ level workload with the pay of a junior. Meanwhile efficiency is going up and they instead try to pack on more work than ever to "compensate". Something's got to give.
- alkonaut 2y ago
  Yes but that’s where WebGPU really shines though isn’t it? Writing a render graph system (or any reasonably complex renderer that at least does several passes) in Vulkan means juggling with manual synchronization but writing one in WebGPU at least means you pay a little performance to not have to do that. If you want to graduate your renderer from WebGPU to Vulkan/DX12 you can pretty easily do that I imagine. So it front loads the fun and lets you postpone the boring boilerplate somewhat. Obviously rendering is always going to be about managing dozens of descriptor sets and pipelines and controlling which resources are written and copied when and where. But WebGPU strikes a pretty good balance for complexity I think.
  - pjmlp 2y ago
    No you can't, because you will need to rewrite all shaders anyway, unless already using the approach to use something else to generate WGSL. It isn't because of fun that most Web 3D frameworks like Threejs, Babylonjs and PlayCanvas provide their own shading abstractions, three shading languages to target now.
    - alkonaut 2y ago
      If you write a rust+wgpu renderer now, your options are already Rust, glsl, wgsl (and probably more). You could do Spir-V too on webgpu so long as you stick to desktop. I'm sure we'll see people load glsl on webgpu on the web too. Any reasonably complex renderer will include shader generation/reflection/translation and so on. Just having a hole where you can plug vanilla hlsl/glsl shaders seems almost impossible.
      - pjmlp 2y ago
        I rather use WebGPU, on the Web, using it for native is always going to be playing catchup with middleware engines that don't have to worry about targeting a 2016 hardware design, as minimum viable product across all major native APIs, and with browser sandboxing in mind. Although it appears to be the next managed 3D API for Android userspace, as communicated at SIGGGRAPH, then again it is better than being stuck with GL ES 3.x as it is now. So a matter of perspective I guess.

by jms55 2y ago

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
  >If you find graphics APIs too much work, you're not their target audience and you should be using a higher level API. That's a pretty sad state of affairs given the "audience" is shrinking by the day. And then later those graphics programmers leave/get laid off by Unity/Epic/AAA Studio with a custom engine and they wonder why they can't find any DX12/Vulkan engineers to their satisfaction. For the lifeblood of the industry, tools need to also be learnable by hobbyists. At least, if you don't want to spend 6-12 months training your graphics programmers yourself. The courses I peeked at at my Alma mater (when Vulkan was still brand new) are still using OpenGL 3 to teach, so it doesn't sound like Universities are picking up the slack.
  - jms55 2y ago
    Vulkan/DX12 _are_ learnable by hobbyists. This was a pretty popular post here on HN 4 months ago of someone learning Vulkan and making an engine in it https://news.ycombinator.com/item?id=40595741 https://news.ycombinator.com/item?id=40595741. Universities usually teach theory, oftentimes in the form of a raytracer on the CPU, or like you said a simple OpenGL renderer using some prebuilt abstractions. I don't think it really makes sense for them to teach how to use Vulkan well or how to make a fast renderer, the details of that often change quickly year by year anyways. > That's a pretty sad state of affairs given the "audience" is shrinking by the day. And then later those graphics programmers leave/get laid off by Unity/Epic/AAA Studio with a custom engine and they wonder why they can't find any DX12/Vulkan engineers to their satisfaction. That's more a symptom of how garbage working in the game development industry is, and less about any underlying technology. There's a reason I work on a game engine for fun, as my hobby, and not professionally despite having the option to do so. Everyone I spoke to in the industry talks about how terrible the working conditions are. A professional graphics developer I recently talked to summed it up well - everyone needs a game engine, but no one wants to pay people to make and maintain one.
    - johnnyanmac 2y ago
      >Vulkan/DX12 _are_ learnable by hobbyists. I did see that post. It is commendable, but we should also note that that author has 15 years of experience in tech and was already a solo developer as a hobbyist. It can be easy to forget that there's a lot of cruft and API to grok through for these things, things potentially out of the scope of students and juniors who haven't had to navigate codebases with millions of LoC in various states of disarray. That speaks more to our ability to tolerate the chaos than the learnability of the API. >I don't think it really makes sense for them to teach how to use Vulkan well or how to make a fast renderer, the details of that often change quickly year by year anyways From a learners' POV I agree. From the industry's point of view they want someone who can jump into the fray with minimal training. And we both hopefully understand that theory doesn't necessarily correlate to real world experience. So there's some critical bridge that is missing on some side that as of now industry just expects potential programmers to learn in their free time somehow. Which in and of itself still isn't a trivial matter. Because so much of this knowledge is tribal wisdom carried by industry. So you see where the issues add up. You'll find breadcrumbs here and there scattered across the net, but this is only adding more obstacles for people to hit that bar. >That's more a symptom of how garbage working in the game development industry is, and less about any underlying technology. There's a reason I work on a game engine for fun, as my hobby, and not professionally despite having the option to do so. Everyone I spoke to in the industry talks about how terrible the working conditions are. I can concur with that as someone in the industry. But there's not really that many places you can go to work professionally if you're not in games: - animation renderers (Pixar, Dreamworks, Illumination. maybe Laika), but the reputation in that industry isn't much better - various research firms that look more for PhD's if anything. Maybe some Masters students. So you're basically in acedemia land (which is known for its lack of pay, even compared to games). - and of course, the GPU companies. Nvidia, Intel, and AMD among a few others. It's a very niche field that requires very specialized knowledge. If no one's offering training nor even an above average pay for that, what are you going to do? If left unchecked, these kinds of fields will be the first to suffer the brain drain as pioneers start to retire or die off. >A professional graphics developer I recently talked to summed it up well - everyone needs a game engine, but no one wants to pay people to make and maintain one. I'd say that's the 2020's in general, yes. Everyone wants senior+ level workload with the pay of a junior. Meanwhile efficiency is going up and they instead try to pack on more work than ever to "compensate". Something's got to give.
alkonaut 2y ago
Yes but that’s where WebGPU really shines though isn’t it? Writing a render graph system (or any reasonably complex renderer that at least does several passes) in Vulkan means juggling with manual synchronization but writing one in WebGPU at least means you pay a little performance to not have to do that. If you want to graduate your renderer from WebGPU to Vulkan/DX12 you can pretty easily do that I imagine. So it front loads the fun and lets you postpone the boring boilerplate somewhat. Obviously rendering is always going to be about managing dozens of descriptor sets and pipelines and controlling which resources are written and copied when and where. But WebGPU strikes a pretty good balance for complexity I think.
- pjmlp 2y ago
  No you can't, because you will need to rewrite all shaders anyway, unless already using the approach to use something else to generate WGSL. It isn't because of fun that most Web 3D frameworks like Threejs, Babylonjs and PlayCanvas provide their own shading abstractions, three shading languages to target now.
  - alkonaut 2y ago
    If you write a rust+wgpu renderer now, your options are already Rust, glsl, wgsl (and probably more). You could do Spir-V too on webgpu so long as you stick to desktop. I'm sure we'll see people load glsl on webgpu on the web too. Any reasonably complex renderer will include shader generation/reflection/translation and so on. Just having a hole where you can plug vanilla hlsl/glsl shaders seems almost impossible.
    - pjmlp 2y ago
      I rather use WebGPU, on the Web, using it for native is always going to be playing catchup with middleware engines that don't have to worry about targeting a 2016 hardware design, as minimum viable product across all major native APIs, and with browser sandboxing in mind. Although it appears to be the next managed 3D API for Android userspace, as communicated at SIGGGRAPH, then again it is better than being stuck with GL ES 3.x as it is now. So a matter of perspective I guess.