> What are the three major projects that were cancelled?

Here are some:

- LogLog Games [1]. Not happy with Bevy. Not too unhappy about performance, although it's mentioned.

- Moonlight Coffee [2]. Not a major project, but he got as far as loading glTF and displaying the results, then quit. That's a common place to give up.

- Hexops. [3] Found Rust "too hard", switched to Zig.

Tiny Glade is very well done. But, of course, it's a tiny glade. This avoids the scaling problems.

[1] https://news.ycombinator.com/item?id=40172033

[2] https://www.gamedev.net/blogs/entry/2294178-abandoning-the-r...

[3] https://devlog.hexops.com/2021/increasing-my-contribution-to...

Tiny glade isn’t tiny on the rendering side. It does gorgeous, detailed landscapes.

Indeed, they also do most of the stuff custom.

None of those are “major projects” by any definition of the word though. And none of the three has anything to do with wgpu's performance.

Rust for game engine has always been a highly risky endeavor since the ecosystem is much less mature than everything else, and even though things have improved a ton over the past few years, it's still light-years away from the mainstream tools.

Building a complete game ecosystem is very hard and it's not surprising to see that Rust is still struggling.

It's crazy you've cited Hexops as an example:

1. It's a game studio not a project (CEO here :))

2. It's very much still alive and well today, not 'cancelled'

3. We never even used WebGPU in Rust, this was before WebGPU was really a thing.

It is true that we looked elsewhere for a better language for us with different tradeoffs, and have since fully embraced Zig. It's also true that we were big proponents of WebGPU earlier on, and have in recent years abandoned WebGPU in favor of something which is better for graphics outside the browser (that's its own worthwhile story)..

But we've never played /any/ role in the Rust gamedev ecosystem, really.

I think the future is getting rid of all the APIs and driver overhead, compile directly to GPU compute and write your own software renderers in a language targeting GPUs (Could be Zig)

A better way to think about the problem is to recognize that the APIs and drivers are providing various services that pretty much every user is going to need, and which you will now need to reimplement yourself.

Nobody needs all of Vulkan, but everyone needs quite a bit of it. Buffer allocation? Command encoding? Scheduling? Synchronization? Abstracting GPU architecture differences (and GPUs vary a lot)? Render pipeline fixed-function stages like primitive assembly, tiling, and blending? You're signing up to implement all of that - good luck!

In this view, your idea is the assertion, "I could do a better job at all that stuff than the driver developers." Maybe so! They're only human. Drivers do have bugs. But you're only human too.

I agree; however, engine developers are already dedicated to building massive behemoths of software that is the game engine and they constantly do collaborate with driver devs, essentially sharing much of the same skillset.

Also, the onus is actually on the GPU manufacturers (not game engine devs) to simplify the programmability of the GPUs to the level we have for CPUs (we also do not write microcode, however, the programmability is much much simpler with access to good compiler toolchains). This will massively help non game engine developers who need GPUs for other kinds of compute.

Check out https://renderling.xyz/