This Week In Veloren 67

0.6, the content update, is slated to be released this week! Join us for the release party at 18:00 GMT on Saturday the 16th. This week, we hear from @Sharp about the move to WGPU. This Month in Rust GameDev has a new edition for the month of April. In other news, here be dragons.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @Songtronix, @imbris, @CapsizeGlimmer, @AngelOnFira, @Slipped, @YuriMomo, @Snowram, and @Shandley!

Lots of bug fixes this week as we approach the 0.6 launch this Saturday! @ProTheory8 found a bug was found where rapidly changing items in the eq slot would crash the server. @imbris is working on a fix. This Month in Rust GameDev #9 has been released for the month of April.

Persistence has finally been merged! Although @Shandley built the final implementation, this has been an ongoing effort by many developers. The current level of persistence only allows a character's looks to be stored on the server. The plan is to expand this out to a character's level, position, and stats before 0.6 is released.

'Programming' is simply the act of adding bugs to an empty text file, don't fear. - @zesterer

Move to WGPU by @Sharp

Concretely, the move to WGPU, at least in the long run, lets us do two things:

1. Access newer graphics card features on cards that support them (where "newer" means anything added since OpenGL 3.2, which came out literally in 2008) without giving up cross-platform compatibility.
2. Exert far more control over the way we interact with the GPU than was possible with OpenGL, opening up previously impossible performance optimizations without sacrificing safety.

The mechanism allowing for both of these changes is that we target the (in-progress) WebGPU API. The API is being designed to provide a target for browser applications that want to interact with the GPU. Unlike APIs like DirectX or Metal, which are explicitly intended to be proprietary, WGPU is designed to be cross-platform. Vulkan, on the other hand, tries to be a universal standard capable of representing all possible interactions with all existing graphics cards. It aims to provide a common interface between all the new APIs; unlike OpenGL, it is aimed at modern graphics cards.

Unlike all of these APIs, WGPU is not intended as a "final" target language implemented by the GPU vendor, but instead treats low-level APIs like Vulkan, Metal, or DirectX as compilation targets. This gives it some independence from vendors changing or abandoning their implementations (like Apple did with OpenGL).

The mechanism for all this is the gfx-rs project. It both implements a low-level Rust API over all the backends I mentioned, and provides a safe Rust implementation of the WebGPU API on top of each one. WGPU is a unified interface to all these backends that automatically selects the best native target.

In practice this whole vision is not yet reality:

• There are older machines that don't expose a more modern backend, but still support OpenGL. Thus, an OpenGL target is needed (this is in progress).
• Since it's still relatively early, there are still a fair number of bugs in the WGPU implementations--safety, performance, etc. But with how high quality the old gfx-rs is, I have little doubt these will be ironed out.
• There are features of OpenGL, or the target languages, that aren't yet exposed but could be very beneficial to performance. As time goes on and the WebGPU standard develops, I expect a lot of these concerns to lessen over time, but apparently there is a way to write native plugins for the time being if you don't care about the web.
• One very important part of this vision is missing; how to handle shaders. Currently, WGPU does not have its own, working shader compiler that can translate from SPIR-V to the relevant backend languages, or from a language like HLSL or GLSL to SPIR-V. Instead, WGPU relies on a C++ library called spirv-cross that (in our experience) is much more difficult to integrate into a typical Rust workflow, both in terms of compiling it and developing against it (e.g. it's much harder to deal with a bug in it than a bug in a Rust dependency). Work is ongoing on addressing this in the naga repository, which @Capucho is apparently helping work on!
• A related problem is that (AFAIK) there is no standard intermediate language that's been chosen for shaders (I think SPIR-V is just a convenience thing). This doesn't affect us that much though.

Despite these concerns, it's already very promising and I am really happy we were able to get Veloren working using its API, even if it's only a proof of concept!

WGPU's current approach leverages the borrow checker to provide a Rust API that can be significantly more efficient without sacrificing safety, at the cost of being significantly harder to use (a tradeoff we're happy to make). However, just because you rewrite code to use the new API doesn't automatically make it faster.

Mostly, it does make all the steps that are costly more explicit, which makes it a lot easier to design for performance, but there are also some quirks of the API itself that may make it harder to do this. I think the API (both Rust side and interface side) will probably continue to evolve to hit the right balance of safety and performance. It also seems possible to me that WGPU alone will not be a high level enough target in some languages to use sanely (for instance, it seems very hard to use safely in a language like C++).