quickgpu 0.0.3

quickgpu wraps the wgpu API allowing users to write shorter, clearer code
Documentation

🚧 Warning this library is not ready for production use 🚧

Bugs need to be fixed, and the API could change a lot in the coming weeks. Any feedback is appreciated!

Overview

quickgpu wraps the wgpu API allowing users to write shorter, clearer Rust graphics code. It consists mainly of builders for wgpu structs. As a wrapper library, quickgpu doesn't manage or own any state after a builder is done building. There's no need to convert all of your code to quickgpu, you can just use it where it's helpful.

For an example of the library in use, take a look at /example/src/scene.rs

Architecture

This repo is split up into:

  • /quickgpu The user-facing crate which wraps wgpu APIs. The main code here is generated by the other, non-user-facing crates.
  • /example An example of using quickgpu in an app.
  • /bunnymark Quick port of wgpu bunnymark to make sure performance is comparable.
  • /xtask Code which generates he quickgpu bindings using syn and other tools. Also includes scripts or building and releasing new code.
  • /discover_exports An experimental library or helping to resolve exports from a crate, type aliases, etc, to help with code generation. discover_exports isn't a general solution, it only has the features needed for this project. Lots of assumptions, unnecessary use of clone, and inefficient algrorithms. However, this crate is not a user-facing part of quickgpu, it just helps generates the bindings.

Tech Decisions

  • All structs quickgpu's goal is that for any wgpu struct SomeStruct, as long at doesn't contain private fields, you can use a builder by typing some_struct(). This means even structs with zero or one fields have builders. This way developers don't have to memorize which structs have builders.
  • Custom builders For most of quickgpu's development, quickgpu used the excellent bon to generate builders. However, figuring out some tricky issues involving trait bounds etc made me realize it would be quicker to write custom builders for now. I'm happy to discuss going back to using a builder library though.
  • Nested trait Nested builders shouldn't need to call build(), so all builders implement a custom Nested trait. This was chosen over using Into, so quickgpu doesn't need to worry about implications of other Into conversions unrelated to nested builders.

Next steps

  • More tests and benchmarks to ensure quickgpu has minimal cost over wgpu
  • Better code documentation
  • Better docs for defaults. Best case, the user would be able to see the actual default value rather than Default::default()
  • Better support for fields that take slices. For example, render pass attachments could be exposed as an attachment method that can be called multiple times, similar to how you can call std Command args once, or you can call arg multiple times.
  • Add convenience methods beyond simple builders