Replace builders with lifetimes/setters directly on Vulkan structs

[Ralith]

Based on prior discussion in #441 and #483.

Remarkably, this doesn't seem to significantly impact build times despite deleting on the order of 20k(!) lines of code. Arguably still an improvement for the sake of simplicity and safety, though. Could use confirmation on the build impact by someone with a better test environment.

TODO: Try making all the setters by &mut rather than by value, per discussion in #483.

[MarijnS95]

Remarkably, this doesn't seem to significantly impact build times

This may have been the #[inline] change pushed later, but this PR in its current form nets me ~1.3 seconds:

$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
  Time (mean ± σ):      7.113 s ±  0.062 s    [User: 7.927 s, System: 0.405 s]
  Range (min … max):    7.053 s …  7.244 s    10 runs

$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
  Time (mean ± σ):      5.812 s ±  0.036 s    [User: 6.644 s, System: 0.356 s]
  Range (min … max):    5.725 s …  5.862 s    10 runs

I recall discussing earlier that the builder structs themselves likely weren't the problem, but it was down to lifetime propagation on the setter methods. Can't find that discussion anymore, but I'd love to get this in and replace trivial setters with just member updates or struct initialization, as previously discussed and proposed in #441.

EDIT: Keeping in mind the twitter link at #441 (comment), would be nice to also drop setters for pointers (Rust borrows with a proper lifetime now) and "trivial slices" with a length (unique!) + pointer pair.

[MarijnS95]

Is this something we can do inside construction above:

let param_ty_tokens = field.safe_type_tokens(quote!('a));

?

[Ralith]

Not trivially, I don't think, since it needs the has_lifetimes state.

[Ralith]

This may have been the #[inline] change pushed later, but this PR in its current form nets me ~1.3 seconds:

Nice! Can you verify whether it was the inlining or not? If so, we definitely can/should pursue it further. I don't expect that to have mattered, since I believe codegen still occurs for inline stuff (so it can only add work), but there's some conjecture there.

EDIT: Keeping in mind the twitter link at #441 (comment), would be nice to also drop setters for pointers (Rust borrows with a proper lifetime now) and "trivial slices" with a length (unique!) + pointer pair.

Per previous discussion I don't believe it's possible to avoid setters for any slice case due to ABI concerns. I'm also a bit leery of requiring a mixture of different approaches to initialize a struct; let's leave that for future work.

[MarijnS95]

$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
  Time (mean ± σ):      6.251 s ±  0.032 s    [User: 7.082 s, System: 0.387 s]
  Range (min … max):    6.176 s …  6.295 s    10 runs

Seems to be both, with your initial approach netting about ~800ms and the #[inline] addition another ~400ms.

Per previous discussion I don't believe it's possible to avoid setters for any slice case due to ABI concerns. I'm also a bit leery of requiring a mixture of different approaches to initialize a struct; let's leave that for future work.

Whoops, I meant to write the VulkanSlice1 wrapper type. Still needs a setter and/or Into/new() construction pattern, but could also expose a safe iterator. Perhaps that type is a bit neater to initialize and use than having a pointer_to_first_element: &'a vk::Something (or doing away with lifetime safety and keeping it *const). Let's indeed leave both the discussion and implementation for a different place though ^^

[Ralith]

Seems to be both, with your initial approach netting about ~800ms and the #[inline] addition another ~400ms.

Interesting! Most ash functions should objectively be inlined, so this would be good to explore further.