Refactor instance creation

[asuessenbach]

Description

This is a suggestion on how the instance creation could be simplified.
The main goal was to move all the application specific logic out of vkb::core::Instance into vkb::VulkanSample and the sample specific code.

This means that the vkb::core::Instance constructor now only receives the data that is to be used for the actual instantiation and checks its validity. As the structures chained into the vk::InstanceCreateInfo via pNext might depend on the actually enabled layers or extensions, it also takes a function to determine those structures.

In vkb::VulkanSample::create_instance, a couple of virtual functions are called (get_name, get_api_version, request_layers, request_instance_extension) or provided (get_instance_create_info_extensions) to actually get the data needed to instantiate that vkb::core::Instance. The default implementations in vkb::VulkanSample fit to the needs of most samples, and some samples override some of them for special needs. Those virtual functions replace some calls previously done in the samples constructor or prepare function.

To summarize, this MR makes more clear when and where data needed for vkb::core::Instance creation is provided by the samples.

Build tested on Win11 with VS2022. Run tested on Win10 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

• I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• I have tested the sample on at least one compliant Vulkan implementation
• If the sample is vendor-specific, I have tagged it appropriately
• I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• Any dependent assets have been merged and published in downstream modules
• For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
• For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[SaschaWillems]

Not sure about this :/

Probably a personal preference, but I prefer the old way over this. This is kinda odd to read (and write) and having instance and device creation getting setup in two very different ways feels somewhat unnatural.

[asuessenbach]

having instance and device creation getting setup in two very different ways feels somewhat unnatural.

Sure. I had planned to adjust the device creation accordingly, if this approach would be approved.

This is kinda odd to read (and write)

Could you elaborate a bit more on this? What is odd?

[SaschaWillems]

As for the odd part, I personally find this:

add_instance_extension(VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME);
add_instance_extension(VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME);
add_instance_extension(VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME);

Easier to write, easier to read and easier to remember than this:

void OpenCLInterop::request_instance_extensions(std::unordered_map<std::string, vkb::RequestMode> &requested_extensions) const
{
	ApiVulkanSample::request_instance_extensions(requested_extensions);
	requested_extensions[VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME]    = vkb::RequestMode::Required;
	requested_extensions[VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME] = vkb::RequestMode::Required;
	requested_extensions[VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME]     = vkb::RequestMode::Required;
}

Interestingly I've been undoing similar constructs like these in my samples to make them easier to maintain and to follow.

Maybe that's because I'm a mostly pragmatic programmer trying to keep code as simple as possible, esp. when writing code that people should learn from ;)

[asuessenbach]

I personally find it more clear and easier to understand, if there's one function (e.g. request_instance_extensions) called by the framework to resolve one task (here: list all the requested extensions). It's clear what to do and when.

But if it's consensus to keep the add/set functions and to not introduce those virtual functions, I could revert that part of this PR.

[asuessenbach]

Any additional opinion anyone?