Improve function std::vector arguments, add C++20 std::span support

[monomere]

While looking at the code, I've noticed that a lot of functions return a plain std::vector not behind a reference, that creates extra copying that could be avoided. I've also moved some code from the cpp file to the header file (like the CustomQueueDescription constructor) so that the compiler can inline the code. I think the whole of vk-bootstrap could benefit from that. I should make a separate issue about this.

Also I'm not super sure about the formatting, I did format it with clang-format, but stuff like pointer alignment wasn't changed.

Fixes the should've-been-a-new-issue #224

[charles-lunarg]

Why do we have the implementation for the vector & span functions that just forward the arguments to the count + pointer function while the implementation of the count + pointer function is in the .cpp file?

I would prefer it if all of the implementations were in the .cpp file. While I do think inlining is important, I would much rather make any performance based decision on data, not conjecture.

[monomere]

To answer the first question: so that less code is duplicated

iirc LTO isn't enabled by default on gcc nor clang, which is generally the only way for the compiler to be able to optimize these functions if they weren't inline. Also afaik and it is common practice to put small forwarding functions and simple constructors in the class definition. I could make a small benchmark for this even :)

[monomere]

Although if you really prefer the function bodies to be in the .cpp file (even if they're a single line), I can change the code

Also I think a great possible performance improvement is the operator VkXX methods. It would be the difference between calling a small function (moving stack pointer, etc.) that returns a pointer and using the pointer directly. And since these operators could be used almost everywhere in user code (like passing Device or Instance) it has a measurable impact I'd say.

[charles-lunarg]

Yes I really would like to see benchmarks - because vkb is an initialization library, very little of this code is called more than once in an application. This library definitely prefers maintainability over performance, and keeping implementations out of the .h file is one way to aid that - as the .h file is in effect the 'documentation'.

[monomere]

The header files being a sort of documentation is a fair point! (this could be fixed by moving the implementation outside of the class definition, but still in the header file though)

I'll move the method bodies into the .cpp file for now. Although I would still suggest moving the operator VkXX methods into the header (it doesn't clutter the code that much, since it fits completely on one line, even with the method declaration)

I'll make the benchmark a bit later, since its not as simple as benchmarking pointer access. But here's a simple godbolt disassembly (not a whole lot of instructions, so its easy to see the point). Compiled with -O2.

extern void do_stuff(int);
void test(A& a) { // A { int unused; int *p; }
    do_stuff(*a.fn1()); // declared out-of-line
    do_stuff(*a.fn2()); // declared inline, returns this->p.
}

test(A&):
  push    rbx
  mov     rbx, rdi
  
  ; this is the out-of-line
  call    A::fn1() ; compiles to "mov rax, qword ptr [rdi+8]; ret"
  mov     edi, DWORD PTR [rax]
  call    do_stuff(int)
  
  ; this is inline
  mov     rax, QWORD PTR [rbx+8]
  mov     edi, DWORD PTR [rax]
  call    do_stuff(int)

So even by just analyzing the assembly, you could deduce that when this is being used in a context of another function invocation (most likely vkXX), the compiler would have to save a lot of registers that store the function arguments, and invoke another function which is pointless indirection.
Edit: make the wording a bit more clear 😅

[charles-lunarg]

Same as the InstanceBuilder, would much prefer implementations to be in the .cpp