3 ms·

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

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

by jms55 2y ago

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.