#bindings

gfx-backend-vulkan

Vulkan API backend for gfx-rs

33 releases

0.9.0 Jun 19, 2021
0.7.0 Jan 30, 2021
0.6.5 Oct 15, 2020
0.5.11 Jul 22, 2020
0.1.0 Dec 27, 2018

#735 in #bindings

Download history 2413/week @ 2024-06-12 2920/week @ 2024-06-19 2686/week @ 2024-06-26 340/week @ 2024-07-03 2441/week @ 2024-07-10 2937/week @ 2024-07-17 2894/week @ 2024-07-24 2660/week @ 2024-07-31 4674/week @ 2024-08-07 3287/week @ 2024-08-14 2941/week @ 2024-08-21 3514/week @ 2024-08-28 2920/week @ 2024-09-04 2717/week @ 2024-09-11 2897/week @ 2024-09-18 3079/week @ 2024-09-25

12,259 downloads per month
Used in 143 crates (12 directly)

MIT/Apache

650KB
12K SLoC

gfx-backend-vulkan

Vulkan backend for gfx-rs.

Normalized Coordinates

Render Depth Texture
render_coordinates depth_coordinates texture_coordinates

Binding Model

Dimensions of the model:

  1. Shader stage: vs, fs, cs, others
  2. Descriptor set: 0 .. max_bound_descriptor_sets
  3. Binding: sparse, but expected to be somewhat tight

Mirroring

HAL is modelled after Vulkan, so everything should be 1:1.


lib.rs:

Vulkan backend internals.

Stack memory

Most of the code just passes the data through. The only problem that affects all the pieces is related to memory allocation: Vulkan expects slices, but the API gives us Iterator. So we end up using a lot of inplace_it to get things collected on stack.

Framebuffers

One part that has actual logic is related to framebuffers. HAL is modelled after image-less framebuffers. If the the Vulkan implementation supports it, we map it 1:1, and everything is great. If it doesn't expose KHR_imageless_framebuffer, however, than we have to keep all the created framebuffers internally in an internally-synchronized map, per B::Framebuffer. !

Dependencies

~11MB
~248K SLoC