Sorry with the audio on this video. Will be fixed in the next upload.

As a graphics programmer I never considered any of this, but he's absolutely right. To my knowledge, Vulkan is the most frankenstein of them all because it attempts to find a common abstraction for every vendor. In a perfect world where every vendor opened up their hardware, abstractions like Vulkan's notoriously awful descriptor sets would either not exist or be a lot more simpler to implement.

I started programming about 15 years ago, and I feel like I was right on the edge of "old school" and "modern" development. I kinda wish I had the opportunity to be a software engineer during the days of actually needing to implement stuff and not just being a glorified infra engineer stitching together a bunch of NPM libraries.

As a C graphics programmer, 100% agree on this

This is why everybody ran for the hills and started using web browsers for everything. On a short term basis it's easier to deal with the insanity of web browsers than the rocket science of native applications.

The worst part is these hardware manufactures don't even get the competitive advantage they seek. What actually happens is they just create significantly work for engine developers to support the multiple shader APIs. Basically nobody wins and everyone else loses.

Modern Graphics Programming and its consequences have been a disaster for the human race

It took me weeks to learn that opengl is basically a state machine, and you're just calling functions that turn on/off features. I wouldn't say it's simple but I feel like that should have been the first line of every beginner tutorial I did.

Vulkan and DX12 are considered modern graphics APIs. DX11 (and previous), OpenGL, and Metal are considered more as Legacy APIs. The main difference between modern and legacy is that the burden of syncing the CPU and GPU is now put in the hands of the developer with modern APIs. Although this leads to more complex code bases and a steeper learning curve, the good thing about this is we can have (almost) complete control over resources shared between the CPU/GPU. This is huge for performance possibilities! Keep in mind, having control like this is also a double edged sword. Not everyone will know how to write code that manages resources correctly. Additionally, these changes help the embedded world once it catches on (embedded seems to always lag so far behind, so who knows how many years until OpenGL ES is phased out) If you are new to learning graphics APIs in general, start with the legacy ones first because they handle the hard part of memory management and GPU sync. Starting with DX12/Vulkan will be much more challenging, and you will end up just learning more memory management than the graphics related aspects. But if that's what you want, go for it!

Jonathan Blow on cake as pallet cleanser

“Everything is too big and too horrible.” lol 2020s in a nutshell.

I’m a software engineer who uses OpenGL for graphics in our company’s software. In my opinion, it is completely impossible to gather the graphics rings of power and bind them in darkness. Instead, I have resigned myself to the fact that I will need to just know each shading language and each use case, and just do the rework a bunch of times. There’s no better solution unless there’s only one GPU manufacturer.

No more graphics programming. Only CLI programs and tic tac toe online.

Man my nigga I dig this dog. Mf thought deep and shared some real shit ,bigsub

i was thinking of learning dos because, as a hobby, i would like to develop games in c for a simple system that isn't subject to terrible change. i'm happy to go down that path but the fact that i couldn't find a sweet spot like that in a relevant modern platform has made me feel very disappointed

My first introduction to "programming" was html and visual basic. I was on the cusp of the design philosophy change over you mention. When I first started, it seemed the only real way to get anything done was to target older machines and when you had direct access to hardware. Things had started to be abstracted so far, you needed to learn dozens of things just to render something on the screen. It was really disheartening. I ended up pushing towards ruby and python for a little bit. Everyone at the time was heralding them as the future of programming. Then I got stuck on java for a little bit. Over the years I ended up more so building skills for dev ops rather than explicitly programming so I pushed for a career in IT. I do wish I had been exposed to more bare metal programming first. I would have fallen more into software development had that been the case.

The cuts in the video are driving me nuts.

100% on point

Your analogy is flawed. It's not that when C was made, someone made a compiler for ALL architectures - far from it. C was made for a specific reason, a specific need on a specific platform. Then, over the years it prevailed because it filled a gap, and it prevailed with lots of vendors implementing it in their own way - gradually then becoming a true standard one could rely upon and so on and so forth. Making the same for a GPU would be trivial, you can make your own toy language for the GCN for example, call it G. But probably it would not really serve a big need, thus won't spread and become a standard etc etc.

Jonathan, I work for Imagination Technologies (PowerVR GPUs). We made the ISA public for our latest two generations (some people even managed to get SGX reversed engineered for PSVita). Unfortunately even if we manage to expose ASM directly to the programmers to they can run shaders they way they want very few brave graphics developers will attempt to do it. Also keep in mind that not only between different families of GPUs, but even on the same family, you can write code on one PowerVR BXM core that will basically hang the GPU on a slightly different permutation (just because that instruction is trying to access or do something that is not supported). This will only work on closed systems where you know that the hardware is never going to change.

What's his take on WebGPU?

Omfg this is so true and even tho i dont make video games it applies to webdev and just software development in general

Will AMD ROCm fit in here somewhere? It’s open source, but I’m unaware of its use outside of deep learning applications.

I wonder how I can apply this to LSPs

what's with the sound?

There are compatibility libraries like bhfx, maybe that's the best way currently.

reviewing tea and talking about Modern Graphics programming

Yes.

i agree

I miss the "old days" of programming.

Isn't spir-v basically a universal shading language?

Gone are the days of bare metal coding like on the C64 and Amiga ooooh how glorious where those days ;)

I come here purely for the Jon Blow cake reviews, I don't know what all y'all are talking about here. Like, is Jon known for anything other than his amazing cake reviews?

I started writting a new kind of forward predictive renderer, I don't see a need more than simple compute shaders to crunch numbers to utilize the full gpu.. I decided to instead leverages how Ai's like NERFs and Gaussian splat neural networks calculate graphics, I honestly think we are heading in this direction. It will be more about how many numbers you can crunch at the end of the day :)

GPUs are actually very simple. Writing a direct driver for a particular GPU wouldn't be much harder than using Vulkan. Vulkan is basically the lack of a graphics library. It's just a thin abstraction layer providing things that most GPUs have in common.

Gamedevs don't put up with all of the APIs and issues - they resort to using an existing game engine instead, which is a bummer for the reasons JB outlines here, all the complexity of the undertaking entailed.

Why isn't there a shader language transpiler if that's such a big problem to have so many shader languages?

can anybody here explain to me why we actually need graphics drivers? my cpu doesnt need any drivers either. if i have a program which says to calculate 1+1 on the cpu then the cpu understands it directly. why is it that when i tell my gpu to calculate 1+1 it suddenly needs a driver for it.

RISC-V is developing an open-source GPU. So the problem of shading language access may be alleviated in the near future.

The only game in town is OpenGL and it’s also the one everyone is waiting for to die. The API scene is so bad that OpenGL cannot die.

I don't think this is true, the real problem is your shader fix would suck about as much as glsl. Just look at how many tries people made to get programming right. When we finally got Crablang some people thought that was so good and made wgsl with 'Vec4' that nobody uses.

It's true. It's sad but it's the reality of the situation. Every GPU/System company wants to have control over the process so all of them have their own GPU language. There is no incentive for them to support or care about a universal language. That's the only reason we have Direct3D, Vulkan, OpenGL, Metal, and all the other proprietary console graphics API's, each with their own shading language.

The electronic engineers, the embedded software dev community needs to do it's comming out and put in place an open source collaboration with indepedant graphic hardware makers, graphic driver programmers, and graphic programmers on the "front end". It Really sounds utopian and I am so sorry for everyone who is impacted by this shit situation.

I'm medical laboratory technician. But I don't know why I like and really everyone in the programming world and appreciate Their contribution by any means they give to the world .

Why does it skip every 10-or-so seconds?

Metal is an amazing shading language, shame that Apple locked it to their proprietary hardware. But on the other hand part of the benefit of that is that Metal can be strongly coupled with their GPU hardware which means they can make it less general and more efficient. This is pretty important when considering GPUs.

Low level API's have been an absolute disaster.

@JonathanBlow So, basically, the reason software development is so abstracted and 'crappy', is because of the need to constantly - marketing-driven, profit-driven - evolve the underlying hardware and systems. I use to use the Amiga ecosystem as an example of what happens, when you have hardware/base, that stays more or less the same over a long timeperiod. The creativity and amount of problemsolving that went into making extraordinairy experiences with very constricted technology, was astounding. And I question whether this could be the same, IF hardware wasn't so rapidly evolving. Software development that actually caters to the hardware 100% is soo much longer to develop than the hardware itself. Very interesting take there!

Gaining a fundamental understanding of everything in your stack/all the tools/concepts you use to build things is very time consuming. Like for example, if i wanted a fundmental understanding of what projection in 3d graphics actually does / what project matricies are, i would need to study linear algebra. Studying linear algebra doesn't necessarily require trigonometric knowledge, but there's a fundamental relationship between trig & projection & inner products & magnitude so you really should. Eventually, if youre like me you forget what you were actually studying for in the first place.

i want to see more 3d menu systems, and title screens, make the interface fully extruded 3d and rotating around, i would like to see that, not done that often!!!

The thought of manufacturers designing their products for control. My naive mind can only think of one solution for this: anti-consumerism. But then after buying second hand laptops, I still contributed to the problem more or less. I don't fucking know what the solution anymore apart from DIY microchips and open source projects. But then, trying to source decent equipments and Android (Google) is a shitshow already.

I totally understand what Jon is saying and largely agree, but I feel like his analysis tends to stop prematurely at the technical level. Are AAA games really hampered today primarily by old technical debt? Im sure that's a major factor, but I would argue it's a similar problem with movies. When 100 million dollars are being thrown at a project, no investor is ever going to take the liability of giving artists the freedom they need to make anything but the most mass-appeal trough slop you've ever seen. All while trying to save money by using new developers desperate for work, or offshoring pieces of their development entirely. In this kind of environment, is it really a surprise nobody takes the time to learn the intricacies of their machines? It's not oit of fear or ignorance that people don't know their stuff. I would argue it's almost entirely a form of market failure. We racked up too much technical debt and traded quality for development speed, and now in many ways its become a defining quality trait to do things well instead. The pendulum eventually HAS to swing back that way. And no, I don't agree with Jon's "bronze age collapse" model. I think we'll be able to dust off the C manuals, establish better hardware standards or all switch to Rust before we just pack it in and decide nobody can use computers any more, lol.

I honestly think its not comparable C that had to deal with a few different data types/formats vs. the massive complexity of modern graphics shaders.

Glados give you cake ? 😂

Honestly this is a poor take IMO. What do you mean "locking up shading languages" ? You know that HLSL can be compiled in Vulkan, right? Also GLSL runs on any vendor right now, except maybe Apple. So, I don't understand this complain. Secondly, do you know that OpenCL exists? Is the closest thing to C and it's more of the general compute platform that you are talking about. This is also runs on any vendor (again, except Apple), so, again, what's the problem here? Do you want a simple API for graphics, well, you can always use OpenGL or D3D11, they still work you know. Now, as developer, I am grateful that Dx12 and Vulkan exist, because now you can optimize your app or game to take full potential of the hardware. In the past, we had to depend on the vendor to optimize the driver for specific games, it was worse than now, so, again I don't understand your rant. Yes, Dx12 and Vulkan ARE complicated, and there is a reason, there is no free lunch, GPUs are complicated, and they are not complicated for some conspiracy theory of Nvidia to make them complicated, is just progress. They are required to do thousand of things now that were not a thing in the past, video encoding/decoding, general compute, AI inference, raytracing, etc. You can write a Basic interpreter for GLSL if you want, you can also go an write your open source driver for Intel if you want (like the i915). Finally, are you advocating for Open Source drivers? or Open Source RTL? Like the design of the GPU? Who will fund this? Who will validate this? Is not a raspberry PI you know. Seems to me you are trying to reduce everything to: complicated bad, simple good.

This is something that I am quite excited about the future of wgpu for - it compiles down (and quite effectively too, an actually good use of rust's absolute overkill of 'zero-cost' abstractions) into basically whatever backend API you want. Vulkan, DX, Metal, if you want to support antique toasters it can do OpenGL no problem, and even WebGL and WebGPU (confusingly, wgpu is also the core of firefox's WebGPU implementation. Mozilla moment I guess). And it's a heck of a lot nicer to write than Vulkan, speaking from experience. While I've seen bindings for other languages out in the wild, it is still rust native - and does depend on its features kinda deeply. So if you don't want to use rust, you've still got a while to wait most likely. also, grrr CUDA >:{ One of the big names at intel, don't remember exactly who, said the world should push towards open standards (specifically calling out against CUDA) for how to interact with a GPU. Rare hardware manufacturer W? Be interesting to see how much intel follow up on that in their own product lines

But… the hardware manufacturers don‘t make the standards. Different consortiums make the standards, like Khronos or the DirectX Group at Microsoft. So what is John‘s point, since the manufacturers don‘t make the evil he complains about?

Ughh this is the exact problem I'm in the process of solving, but the likelyhood of piracy and/or no payment, is kicking me in the gut so hard. /whinge

I can understand and accept the sentiment, but hardware nowadays really is too complicated to be accesseed directly. Still, opensourcing specs, drivers and frameworks would make everyone's life so much easier.

I still think the most universal approach model wise to graphics is writing directly to the acreen pixels. Unfortunately it seems you just can't get any speed out of that. APIs have not favored the programmer instead we're having to bend ourselves and bang our heads on the wall as we build cabins out of sawdust and glue. I don't think there's been a more hostile programming era to the new programmer. We have tools that attempt to do everything for us yet we have horrid abstractions around graphics we need entire engines just to manage everything and nobody understands what's going on at the end of the day truly because everybody's worried about learning the 10% of the glue they need to make everything work. A big part of it too is the expectation of the people who receive the games. If the graphics API was simply coloring screen pixels you're development kit consisted of a core language and some multimedia libraries and the customer would settle for much more simple games with less content we'd all be better off. You look at game programming books in the '90s and early 2000s and you essentially see a core language some supporting multimedia functionality and that's it you get a game in around 200 pages. Go back to the '80s and you basically get 4 pages of BASIC to make a game. So we've gone from a program listing of four pages to a book of 200 pages to five books covering various topics or just blindly learning a game engine.

Good thing Unreal Engine has a material editor

we need to reimagine the gpu from the ground up using first principles. we cant just leave nvidia, amd, and intel to keep using their bloated proprietary architecture

The poor state of modern API's are kind of an indication that capitalism isnt quite giving us better products - Competition seems to affect only the hardware. Same thing with modern entertainment - Competition hasnt worked to give us better Alien, Terminator or Predator movies. Its all garbage. Why isnt competition working?

too big to fail in video games?

Did this dude just complain about shader languages? Of all problems that face video game developers, is the inability to rewrite the shader language really something to focus on? There is literally no game that would become possible to make in reasonable time if you had a new shader language. I'm reminded of the Steve Jobs Takes Criticism video whre the dude complains about java and opendoc. There aren't any customers that care dude.