Porting raylib to wgpu

[AregevDev]

Context

WebGPU is a new graphics API that aims to be a modern graphics API on the web. wgpu is one of the available implementations of WebGPU, written in Rust, and used internally in Firefox. wgpu currently translates WebGPU calls to DirectX 11, DirectX 12, Vulkan, Metal, and OpenGL / GLES / WebGL. wgpu-native is the C binding library for wgpu, usable from C / C++.

As an exercise, I attempt to port raylib to use wgpu. This proves to be a challenge since raylib is deeply dependent on rlgl and OpenGL itself. Virtually, every raylib core module uses rlgl. My goal is to split the core modules from the graphics backend and write a new wgpu graphics backend. This can help future-proofing raylib, while still supporting it on older systems. I do not intend to replace rlgl completely.

How?

To write a new graphics backend, I probably need to split/abstract the graphics initialization.
Some ideas I had in mind:

• Add extra platform source files for the wgpu implementation (i.e rcore_desktop_glfw_wgpu) This approach is similar to what ImGui does, by letting the user include the right combination of window platform and rendering backend. This approach might not fully work since raylib is tightly integrated with OpenGL.
• Abstract the rlgl backend. Make all raylib.h's functions not depend on rlgl directly, but rather select the correct graphics backend based on the build configuration.
• Implement the rlgl functions in wgpu. To be honest, I am not sure about that solution. Mapping old-style OpenGL calls to modern graphics APIs can lead to suboptimal usage/performance.

This proves to be an extremely critical decision from a developer experience and simplicity standpoint.

I need help

I opened this discussion to gain some feedback and start a discussion.
For now, I modified the CMake scrips to download wgpu-native and build it from source. You can view the changes here: https://github.com/AregevDev/raylib/tree/wgpu.

[JeffM2501]

Would this add rust as a dependency to raylib?

[gen2brain]

Sorry to intrude on the discussion, but prebuilt binaries, for what, only Windows, macOS, and Linux, and only amd64? That looks like trouble. The main advantage is that you can use whatever C compiler/toolchain for whatever platform, and there are ongoing discussions and work for software-only support. Something like this ruins everything.

[wwderw]

Sorry to intrude on the discussion, but prebuilt binaries, for what, only Windows, macOS, and Linux, and only amd64? That looks like trouble. The main advantage is that you can use whatever C compiler/toolchain for whatever platform, and there are ongoing discussions and work for software-only support. Something like this ruins everything.

As someone that is looking forward to software-only support, I do have that concern as well.

[AregevDev]

Really? That's cool.
So the idea is to provide an external library for custom rendering backends. Then, the only thing to worry about in the main repository is the core-graphics split.

[JeffM2501]

In general we don't want any new dependencies unless they are absolutely necessary. Raylib is built with MANY different build systems by a wide range of people. We can not assume any specific libraries or tools or prebuild binaries. That even includes tooling such as python.

[AregevDev]

Yeah, fair.

[ghost]

Reasons against changing raylib to accommodate this proposal:

1. WebGPU is experimental (ref), has limited availability (ref) and is still a working draft (ref).
2. It would require a substancial rework of nearly everything in raylib (right after it finally reached a point of good stability).
3. Raylib would add a dependency on Rust (which is very far away from C99).

[manuel5975p]

I agree mostly but again, there is a pure C/C++ webgpu implementation called Dawn

[AregevDev]

@jeanck All fair points, I should not be asking for wgpu in the core library. Maybe reorganize the source files to make writing extra graphics backends more approachable.

(My inner Tsoding is yelling at me rn 😄)

[OetkenPurveyorOfCode]

I once thought of implementing a raylib platform backend (similar to GLFW, SDL2, RGFW) with sokol.
Andre Weissflog's sokol_gfx provides abstractions for different graphics backends (including WebGPU), namely DirectX 11, OpenGL, OpenGL ES, Metal, WebGL, WebGPU.
But is it worth it? I don't know.
It would have many of the same problems that supporting WebGPU would have. The biggest problem would be the shaders. A raylib application would have to supple the shader in the shading language of the target platform. (Sokol has a cross-compiler from Vulkan GLSL to all its backends, but that does not cover the cases when one wants to generate shaders at runtime).