I learned Vulkan and wrote a small game engine with it

That's just not true. https://wgpu.rs/

I'm literally writing native code running on linux with winit and wgpu right now.

webgpu is a modern graphics API for modern GPUs to replace/complement these two APIs in the browser: WebGL (a very limited outdated subset of OpenGL) and Canvas (basically WinAPI drawing from 2000s)

It's heavily influenced by Metal (based on original work by Apple and Mozilla).

People are talking about it because it's on the web and it's finally something modern to work with.

One remarkable feature of WebGPU is that it has no undefined behaviour, traditional 3D APIs are riddled with subtle UB. It also receives much better testing across all sorts of hardware and driver configs, just by being integrated with web browsers.

My perspective is it’s a couple things. Mainly because it’s backed by several implementations with market pressure to deliver high quality working implementations (wgpu in Firefox, Dawn in Chrome). Not saying bgfx or others are bad, but the Chrome team will be putting in a lot of work for you to make sure Dawn works well everywhere Chrome needs to be. That plus it’s super portable. First time in a long time that we could truly be looking at a “write once run anywhere” GPU API. It also fills OpenGL’s niche by being much more approachable than Vulkan. I guess this really just adds up to it being the “OpenGL 2” a lot of people have been wanting in light of Vulkan’s complexity and weaker portability.

There is a native API too, not just JS. You can link it into your game like any other library.

WebGL isn't WebGPU. WebGPU has compute shaders: https://docs.rs/wgpu/latest/wgpu/struct.ComputePass.html https://www.w3.org/TR/WGSL/#compute-attr

(Edit: ah, I missed the bit in GP that you replied to.)

Valve's efforts on playing Microsoft only games started ~10 years ago with Proton (which is more like an umbrella project for ~15 software components like Wine and DXVK). Today, proton is surprisingly good. Their bet paid off, and allowed them to make SteamDeck. Most if not all new games play fine out of the box, with 0 tinkering. Older games sometimes have issues.

Contrary to urban myths, non-xbox consoles aren't that found of Khronos standards either.

Since DXVK exists and Apple dropped OpenGL, the latter gains you access to Android and that's about it, unless you're ok with ES 3.0 contexts and a lackluster set of extensions (ANGLE on Metal).

AFAIK the non-Xbox consoles either don't support OpenGL or we reportedly don't want to use their implementations.

Linux you can get for “free” with DXVK or VKD3D-proton. MacOS is an even more niche platform than Linux as far as gaming is concerned and is not a tough sell to skip considering the total lack of market share in games. iOS and Android generally come in a pair so unless you’re only targeting one you need to support multiple APIs anyway. Xbox requires Xbox specific APIs so you need explicit work there. Every other console uses a bespoke API that will require another backend in your engine (yes Switch technically supports Vulkan but that is not the recommended path from Nintendo, you will likely end up with an NVN backend).

D3D11 gives you both desktop platforms that matter for games, everything else will require multiple backends anyway so if you only care about desktop it’s a fair choice.

Exactly this. Vulkan, especially Vulkan 1.0, was never really meant directly for graphics developers. It was meant specifically for engine developers that didn't want to have to deal with buggy and inconsistent drivers, e.g. Nvidia vs AMD vs crappy Android phones.

The solution Vulkan came up with was "make everything as explicit and user-controlled as possible", and leave "implementing a more user friendly driver" up to user-space, so that it could be tweaked by users, wouldn't be tied to driver updates users would never do, would be consistent across platforms, etc.

Except that never really happened. There are some graphics-driver-as-a-library projects (daxa, nabla, etc), but none with a large amount of community support.

Meanwhile GPU's evolved over time (AMD RDNA1, Nvidia Turing, Intel Arc, Apple Silicon), and it turns out that some of the choices Vulkan 1.0 bet on weren't great (explicit extensive pipeline state, binding model, render passes).

Vulkan 1.2/1.3 cleaned up a lot of this (dynamic state, descriptor indexing, sync v2), which also happens to improve ergonomics a lot to the point that it's much less painful to use Vulkan directly nowadays, as long as you're ok dropping support for older platforms.

gameplay matters, but graphics sell. Look no further at the modern state of hardcore reviewers and hyper nitpickers on social media. See how every switch game is criticized for not being 1080p60 on 2017 mobile hardware. People demand that kind of quality.

That's a loud minority, but it's not like the biggest games aren't selling more and more every year en large. So non-vocal gamers do seem to be drawn to it.

I switched from opengl b/c I was tired of staring at a black screen with no debugging information (sure...glGetError) when I tried to implement a non-trivial feature. After tons of work to learn vulkan and getting it up and running, I still think it was worth it.

Agreed. I don’t even need all these fancy Vulkan features most of the time… Just validation layers and RenderDoc debugging make the whole experience of doing graphics programming so much more pleasant for me, compared to what I had to deal with in OpenGL.

Pushing the code into a user-space library used by many programs means bugs can be fixed once in the library, instead of being at the mercy of every vendor fixing their driver blobs.

Honestly, this might be a bit of a conspiracy theory, but the practical use-case of Vulkan's low-level access isn't because of PCs and consoles - it's because of smartphone manufacturers that make absolutely abysmal mobile drivers.

Now instead of vendors writing this correctly once for everyone, everyone can do it poorly.

_Vendors_ did it poorly, which is why everyone wanted to get away from them. You could argue they over-corrected and left _too_ much to the user, but better safe than sorry.

Sure users can write bad code as well, but at least it's _consistently_ bad, and fully under their control. There are so many fewer problems nowadays like "oh it works on my desktop, but on this older intel GPU for a user with outdated drivers it segfaults in the driver, and there's nothing we can do to fix it ourselves".

It doesn't really make sense to have Khronos maintain nice high-level libraries. There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers.

Why do you need Khronos to "bless" a particular library anyway?

Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.

Please try again with Vulkan 1.3 and reassess how "terrible" the API is.

And use some high level library like vk-bootstrap to do the boring init work.

Because once it's set up, Vulkan 1.3 is about as easy as OpenGL (if you stick with OpenGL-level stuff).

It is easier than WGPU because the RenderPass stuff required in Vulkan 1.0 (and hence WGPU) is gone, removing a lot of boilerplate code.

Pipeline barriers are the only "complex" thing remaining but even they are somewhat simplified with the right defaults (sharing mode) and simplifications (set stage masks to all commands, overhead is negligible on desktop devices).

Use push descriptors for "bindful" textures, set all your pipelines states dynamic (except blending), and timeline semaphores for sync.

For simple stuff (OpenGL level) it's a pleasure to work with, and you get rid of all the OpenGL quirks.

Complex stuff like bindless texturing and GPU driven rendering is still complex, but that's the same in all APIs.

It can still be a bit verbose and the init code is too much work (but you do it only once), but after it is set up it's quite okay.

And if you want OpenGL, use OpenGL. Zink (OpenGL on Vulkan) guarantees that it will be supported, even if GPU vendors stop keeping their GL drivers up to date (has not happened yet).

The "first party library" is OpenGL, or if you have special needs OpenGL ES, WebGPU, Metal, DirectX variants, implemented on top of Vulkan.

The "NO REPLACEMENT" is sidelining ugly OpenGL drivers and adopting leaner and more modern Vulkan drivers.

That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!"

If you can write that OS in anything close to 600 lines then yes, it is easy.

The point is that more realistic OpenGL and Vulkan projects will have a much smaller relative size difference.

Great. What about the other 99% of people?

They can use higher-level abstractions built on top of Vulkan. Or spend some time learning to use Vulkan directly.

I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it.

Disagree.

In giving up OpenGL we're giving up a sane, standard way to do graphics programming

Sane is not a word I would use to describe OpenGL. It has managed to collect many warts over the years and as I have already mentioned, what performs well is not at all intuitive.

(i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

"Oh no, so many options". A nice problem to have.

And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

Wild and unfounded speculation. You can already use ANGLE, which is open source, as your middleware today if you like the OpenGL API so much.

I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming

I cannot avoid thinking that this sort of argument was made for countless technological innovations, from steam engines vs. draft animals to boats vs. swimming.

I agree with your analogy. It just so happens that Java is commonly taught as a first programming language and most people manage just fine with the class boilerplate even if they don't really understand it yet.

I usually copy the built library from a Chrome/Chromium installation, saves me from building the library myself.

WebGPU is mostly very similar to Metal (except for a couple of overly 'rigid' parts which are mostly inherited from Vulkan - most importantly the resource binding via BindGroups and all-in-one PSOs).

Also, Metal isn't generally a high-level API, it has low-level features which are pretty much like Vulkan or D3D12, you just don't need to use those low level features if not needed.

By the way, here's an interesting post by Mike Blumenkrantz (Valve): https://www.supergoodcode.com/manifesto/

Most of it is satire, but it's interesting that the position of "Chair of OpenGL" still exists to this day and a new person was assigned to it in 2024.

The contrast to this is to put in tickets specifically for refactoring and reorganization, but I've rarely seen that work since they often don't have any sweetener included to encourage e.g. product organization to sign off on the work.

I agree, and would add that agile is bad because it's used to iterate along the product vertical, so first create an MVP, then add features. Instead it could be used to iterate from a technical standpoint, first adding the helper functions, then the interfaces, then some of the core functionality.. but the problem there is that most orgs prefer immediate "business value" at the cost of long term good engineering. In some cases, when the application is meant to be short-lived this makes sense, but more often than not I've seen teams suffer from this approach, not realizing they have been digging their own hole for years.

A large organization is likely to have both a separation between experiments and the "actual" game engine, containing the churn of throwaway code in order to build on good foundation, and significant experience and reuse from their previous game engine, constraining (possibly for the worse) the experiments and rewrites.

Totally agree, it needs a careful balance. But is it possible to know when to use what?

Anecdote: A couple years ago I migrated a 1M+ LOC application from one database to another, cutting the cloud hosting costs practically in half. This was absolutely massive for the company. It took a bit less than a year, but was possible because the people who designed the application didn't write any hardcoded queries, and everything went through an ORM or a query builder. Everything was built to an interface, even though they all only had one implementation. This turned out to be absolutely critical when we had to add the second implementation (and because we needed to maintain compatibility for the original implementation at the same time due to some one-off contracts) and the migration would not have been worth it cost-wise if the proper architecture wasn't in place from the start.

Now take the same application. It has tons of complicated architecture stuff implemented in house. Parts of it are definitely overengineered. It's been apparent when doing other upgrades and finding out "oh... this doesn't work because it's using a custom JSON serializer" that the choice to do that was poor.

In the end, I think the right choice for that application was the complex design that allowed those big migrations. For others, they might never do that and only get hit with downsides.

What it needs is likely a good vision and someone smart to know what to abstract and what to not abstract such that it will have been a good choice 15 years down the road.

There are two poles

I'm not sure I agree. I think you can write a simple-but-not-hacky implementation that does only what is necessary, and is also easy to maintain and extend later.

Of course, you never really achieve that ideal, but you can keep getting closer to it as you gain more experience.

In my 25-year career I’ve experienced easily fifty times as much pain from underthought and hastily-implemented systems than I have from overengineered ones.

Sure, build user-facing stuff cheaply and ready to be thrown away as requirements change. But libraries, tooling, and infrastructure that everything else is built on top of should have thought and care invested in it. This will return dividends.

We spend so much time as an industry worried that somebody might put five percent more effort into a project than it’s worth, that the overwhelming majority of engineers have no idea whatsoever of how to build something to be reliable, to be easily iterated on, and to last. And so we spend tens of times more effort trying to build on top of a mountain of crap.

On the other hand, often a "quick and dirty" solution unexpectedly becomes the foundation of a lot of other stuff

This is how Access "databases" and Excel spreadsheets often become mission-critical in SMBs. "We'll deal with needing a database server down the road..."

When I WAS the bane of my existence was senior and staff engineers hoarding all the fun, new work for themselves and forcing me into "bitch work" where I'm just cleaning up old, broken code and handling bugs.

Oh how I relate to this...

That's why these days I go out of my way to "save" interesting work for my junior colleagues and have them grow through it.

Not just politics, I almost feel it can hamper you as an engineer. If you just do basic plumbing for 10 years, are you really an engineer with 10 YOE or one with 2YOE 5 times over because everyone needs a plumber?

2-3 years seems to be where that valuable plumbing experience starts to plateu. I don't know how engineers these days that move companies every other year even get a chance to grow when you're doing a soft restart at every job hop.

The actual issue is not CPU-side. The issue is GPU-side.

The CPU feeds commands (CommandBuffers) telling the GPU what to do over a Queue.

WebGPU/wgpu/dawn only have a single general purpose queue. Meaning any data upload commands (copyBufferToBuffer) you send on the queue block rendering commands from starting.

The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue.

WebGPU/wgpu/dawn would need to add support for additional queues: https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aiss...

There's also ReBAR/SMA, and unified memory (UMA) platforms to consider, but that gets even more complex.

Short version: hope, yes. Obtain now, no.

Long version: https://github.com/gfx-rs/wgpu/discussions/5525

There's a lock stall around resource allocation. The asset-loading threads can stall out the rendering thread. I can see this in Tracy profiilng, but don't fully understand the underlying problem. Looks like one of three locks in WGPU, and I'm going to have to build WGPU with more profiling scopes to narrow the problem.

Very few people have gotten far enough with 3D graphics in Rust to need this. Most Rust 3D graphics projects are like the OP's here - load up a mostly static scene and do a little with it. If you load all the content before displaying, and don't do much dynamic modification beyond moving items around, most of the hard problems can be bypassed. You can move stuff just by changing its transform - that's cheap. So you can do a pretty good small-world game without hitting these problems. Scale up to a big world that won't all fit in the GPU at once, and things get complicated.

I'm glad to hear from someone else who's trying to push on this. Write me at "nagle@animats.com", please.

For a sense of what I'm doing: https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

That sounds wild to me. In c++ I remember a time where I increased the frame rate of a particle renderer from 20fps to 60fps+ simply by going from passing shared_ptr (Arc equivalent) to passing references.

WGPU is an implementation of WebGPU

No.

    wgpu is a safe and portable graphics library for Rust based on the WebGPU API. 
    ...
    and browsers via WebAssembly on WebGPU and WebGL2.

WebGPU is not software, you can't use it

It's an API that you can use, like OpenGL, Vulkan, Metal, .... Here you can see the current Browser support: https://caniuse.com/webgpu

Vulkan doesn't, but WebGPU does do synchronization and memory allocation for you.

WebGPU (or Metal if you're in Apple land) still has a much gentler learning curve. The simplifications to Vulkan weren't really aimed at making it easier to use, just streamlining parts of the API which turned out to be needlessly complex, so the parts that are complex for a reason are still just as complex.

With WebGPU/wgpu you don't get mesh shaders, ray tracing or shader subgroup/wave/warp operations. Its feature set is comparable to Vulkan 1.0, and Vulkan has progressed a lot since.

And WebGPU still requires all the RenderPass setup code which is a lot of boilerplate that Vulkan no longer requires.

only supported on about 28% of reports.

This information is misleading because it includes old reports from years ago, before this feature existed. It does NOT mean that 28% of devices out there have support. You will need Steam hardware survey results and cross reference gpuinfo.org or Android hardware survey results which directly list Vulkan versions.

Dynamic rendering is available on all desktop GPUs (Intel, NV, AMD), on all desktop OSes (Windows, Macos, Linux) as long as you've got drivers that are up to date (no older than 2023).

For mobile devices, the situation isn't as good. Updating mobile GPU drivers is an unsolved problem.

You really have to think of Vulkan on PCs and Vulkan on mobile as separate things, if you only care about running on the former then you can easily count on things like dynamic rendering always being available as long as your users drivers are up to date. If you need to target Android though, my condolences.

Not sure if I’ll be able to do their new guide, my laptop can’t run some of the more recent versions of Vulkan

If your laptop got still GPU driver updates in 2022 or later, it should probably support Vulkan 1.3. You can install Vulkan SDK (or just extract the archive) and check your Vulkan version by running the supplied "vulkaninfo" program.

For example, my 5 year old Thinkpad T490 fully supports Vulkan 1.3 and it only has an iGPU! :)

Khronos overhauled their docs last year. I've found the "Vulkan Guide" easier to read than the spec.

https://docs.vulkan.org/guide/latest/index.html

Not to be confused with the tutorial you're referring to.

https://vkguide.dev

You'll need 1k LOC to draw a single triangle and not 10-20k.

Sticking with OpenGL is understandable, but I can recommend learning some Vulkan as a side project (with the help of vkguide) without too much commitment. That's how I started and it turned out to be not as bad as I imagined! Uour mileage may vary, of course.

But it's part of Mesa, it's not something you can drop into an app written against OpenGL to translate the calls to Vulkan right?

if you're in the industry and have the time and resources necessary to profit from its advantages.

I don't even know how you get into the graphics industry these days. The bar is so high and I just don't see how you get the knowledge needed for it. I graduated years ago and don't feel any closer now than back in the mid 2010's despite having a lot more experience to point to in other parts of games.

vulkan doesn't have global state, and the error handling is better

but it's not batteries-included, and that's often to be a deciding factor at small scales

i think if you're going to dabble in engine dev, you pick which one you want depending on which part of the engine you find interesting. if you want to make a game, you pick up unity or godot or something

I wonder how much less ergonomic is is for getting there via Vulkan. For the ray tracing shaders.

Why though? Khronos doesn't have the best record of API design and there's plenty of other projects that are much higher level and simpler to use for a newbie developer. You can scroll just a bit up and see just how many webdevs end up using webgpu which is closer to the abstraction they prefer.

game engine architecture, by jason gregory

there's a section on memory allocation patterns

i believe casey muratori talks about allocation patterns in the handmade hero video series, too

edit: ryan fleury has a talk: https://www.rfleury.com/p/enter-the-arena-talk

Your site looks nice and is quite readable! The thing I most dislike about sites that just use raw HTML is the lack of `max-width` on the text containers (which makes using reader mode necessary), so thanks for including that

reminds me a lot of http://bettermotherfuckingwebsite.com/

pretty much all HTML, with only the bare minimum CSS to make it somewhat responsive.

I guess if you want one tiny piece of feedback, based on the above site:

A little less contrast

Black on white? How often do you see that kind of contrast in real life? Tone it down a bit, asshole. I would've even made this site's background a nice #EEEEEE if I wasn't so focused on keeping declarations to a lean 7 fucking lines.

I agree with the advice, but I've definitely seen many a heated debate over raw black on raw white amongst designers. So take with a grain of salt and a handful of personal preference.

I guess libraries like bgfx, sokol and The Forge are kinda like that. But I just feel like it’s either all or nothing if you’re already doing your own game engine.

I’m okay with using middleware/3rd party libraries for things which I don’t care too much about (e.g. physics), but graphics is such a core component that I want to handle it myself.

In a way, OpenGL drivers were such middleware libraries written for you by GPU vendors (or open source community). But now they stopped doing that and now you’re either writing your own graphics abstraction layer or using someone else’s.

In this case, I choose the hard way. And it seemed to have worked out so far. I definitely won’t recommend it to everyone (especially if they want to make a game in less than a year!), but as a learning experience it was fun.