Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

`wgpu` in Rust is an excellent middle ground, matching the abstraction level of WebGPU. More capable than OpenGL, but you don’t have to deal with things like resource barriers and layout transitions.

The reason you don’t is that it does an amount of bookkeeping for you at runtime, only supports using a single, general queue per device, and several other limitations that only matter when you want to max out the capabilities of the hardware.

Vulkan is miserable, but several things are improved by using a few extensions supported by almost all relevant vendors. The misery mostly pays off, but there are a couple of cases where the API asks you for a lot of detail which all major drivers then happily go ahead ignore completely.



How easy is it to integrate wgpu if the rest of your game is developed with a language that isn't rust? (e.g. C# or C++)


Very! there are unified headers and a C library that the maintainers have written as a wrapper around the library.

https://github.com/gfx-rs/wgpu-native

https://github.com/eliemichel/WebGPU-Cpp


wgpu is the name of the Rust library, but it pretty closely follows the WebGPU spec, which you can easily use from C or C++ via Google's `dawn` library. It provides C bindings as well as a templatized C++ API.


Webgpu.h is, AIUI, part of the webgpu spec. Both Dawn (Google’s C++ implementation used in Chrome) and wgpu (Mozilla’s implementation used in Firefox) can be used as concrete implementation of those headers.


I'll definitely give wgpu a look. I don't need to make something that competes with Unreal 5 or anything, but I do think it would be neat to have my own engine.


Could you say more about which extensions you’re referring to? I’ve often heard this take, but found details vague and practical comparisons hard to find.


Dynamic rendering, timeline semaphores, upcoming guaranteed optimality of general image layouts, just to name a few.

The last one has profound effects for concurrency, because it means you don’t have to serialize texture reads between SAMPLED and STORAGE.


Not the same commenter, but I’d guess: enabling some features for bindless textures and also vk 1.3 dynamic rendering to skip renderpass and framebuffer juggling




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: