mirror of
https://github.com/charles-lunarg/vk-bootstrap.git
synced 2024-11-25 16:24:35 +00:00
Expanded getting started page
This commit is contained in:
parent
1daf83f541
commit
a057ddbe2e
@ -11,7 +11,7 @@ Simply create a builder variable and call the `build()` member function.
|
|||||||
vkb::InstanceBuilder instance_builder;
|
vkb::InstanceBuilder instance_builder;
|
||||||
auto instance_builder_return = instance_builder.build();
|
auto instance_builder_return = instance_builder.build();
|
||||||
```
|
```
|
||||||
Because creating an instance may fail, the builder returns an 'Expected' type which can be either a valid `vkb::Instance` struct, containing the `VkInstance` handle, or the builder returns an error.
|
Because creating an instance may fail, the builder returns an 'Expected' type. This contains either a valid `vkb::Instance` struct, which includes a `VkInstance` handle, or contains an `vkb::InstanceError`.
|
||||||
```cpp
|
```cpp
|
||||||
if (!instance_builder_return) {
|
if (!instance_builder_return) {
|
||||||
printf("Failed to create Vulkan instance. Cause %s\n",
|
printf("Failed to create Vulkan instance. Cause %s\n",
|
||||||
@ -19,11 +19,11 @@ if (!instance_builder_return) {
|
|||||||
return -1;
|
return -1;
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
Now that any possible errors have been handled,
|
Once any possible errors have been dealt with, we can pull the `vkb::Instance` struct out of the `Expected`.
|
||||||
```cpp
|
```cpp
|
||||||
vkb::Instance vkb_instance = instance_builder_return.value();
|
vkb::Instance vkb_instance = instance_builder_return.value();
|
||||||
```
|
```
|
||||||
This is enough to create a usable `VkInstance` but most use cases will want to customize it a bit. To do so, simply call the member functions on the `vkb::InstanceBuilder` object before `build()` is called.
|
This is enough to create a usable `VkInstance` handle but many will want to customize it a bit. To configure instance creation, simply call the member functions on the `vkb::InstanceBuilder` object before `build()` is called.
|
||||||
|
|
||||||
The most common customization to instance creation is enabling the "Validation Layers", an invaluable tool for any vulkan application developer.
|
The most common customization to instance creation is enabling the "Validation Layers", an invaluable tool for any vulkan application developer.
|
||||||
```cpp
|
```cpp
|
||||||
@ -90,7 +90,7 @@ vkb::destroy_instance(vkb_instance);
|
|||||||
```
|
```
|
||||||
## Surface Creation
|
## Surface Creation
|
||||||
|
|
||||||
Vulkan requires manually creating a surface, called `VkSurfaceKHR`. Creating a surface is the responsibility of the windowing system, thus is out of scope for `vk-bootstrap`. However, it does try to make the process as painless as possible by automatically enabling the correct windowing extensions in `VkInstance` creation.
|
Presenting images to the screen Vulkan requires creating a surface, encapsulated in a `VkSurfaceKHR` handle. Creating a surface is the responsibility of the windowing system, thus is out of scope for `vk-bootstrap`. However, `vk-bootstrap` does try to make the process as painless as possible by automatically enabling the correct windowing extensions in `VkInstance` creation.
|
||||||
|
|
||||||
Windowing libraries which support Vulkan usually provide a way of getting the `VkSurfaceKHR` handle for the window. These methods require a valid Vulkan instance, thus must be done after instance creation.
|
Windowing libraries which support Vulkan usually provide a way of getting the `VkSurfaceKHR` handle for the window. These methods require a valid Vulkan instance, thus must be done after instance creation.
|
||||||
|
|
||||||
@ -133,12 +133,50 @@ By default, this will prefer a discrete GPU.
|
|||||||
|
|
||||||
No cleanup is required for `vkb::PhysicalDevice`.
|
No cleanup is required for `vkb::PhysicalDevice`.
|
||||||
|
|
||||||
// TODO -- configuring selection, querying phys device details, explaining why a surface is needed
|
The `vkb::PhysicalDeviceSelector` will look for the first device in the list that satisfied all the specified criteria, and if none is found, will return the first device that partially satisfies the criteria.
|
||||||
|
|
||||||
|
The various "require" and "desire" pairs of functions indicate to `vk-bootstrap` what features and capabilities are necessary for an application and what are simply preferred. A "require" function will fail any `VkPhysicalDevice` that doesn't satisfy the constraint, while any criteria that doesn't satisfy the "desire" functions will make the `VkPhysicalDevice` only 'partially satisfy'.
|
||||||
|
|
||||||
|
```c
|
||||||
|
// Application cannot function without this extension
|
||||||
|
phys_device_selector.add_required_extension("VK_KHR_timeline_semaphore");
|
||||||
|
|
||||||
|
// Application can deal with the lack of this extension
|
||||||
|
phys_device_selector.add_desired_extension("VK_KHR_imageless_framebuffer");
|
||||||
|
```
|
||||||
|
|
||||||
|
Note:
|
||||||
|
|
||||||
|
Because `vk-bootstrap` does not manage creating a `VkSurfaceKHR` handle, it is explicitly passed into the `vkb::PhysicalDeviceSelector` for proper querying of surface support details. Unless the `vkb::InstanceBuilder::set_headless()` function was called, the physical device selector will emit `no_surface_provided` error. If an application does intend to present but cannot create a `VkSurfaceKHR` handle before physical device selection, use `defer_surface_initialization()` to disable the `no_surface_provided` error.
|
||||||
|
|
||||||
## Device Creation
|
## Device Creation
|
||||||
// TODO
|
|
||||||
|
Once a `VkPhysicalDevice` has been selected, a `VkDevice` can be created. Facilitating that is the `vkb::DeviceBuilder`. Creation and usage follows the forms laid out by `vkb::InstanceBuilder`.
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
vkb::DeviceBuilder device_builder{ phys_device};
|
||||||
|
auto dev_ret = device_builder.build ();
|
||||||
|
if (!dev_ret) {
|
||||||
|
// error
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The features and extensions used as selection criteria in `vkb::PhysicalDeviceSelector` automatically propagate into `vkb::DeviceBuilder`. Because of this, there is no way to enable features or extensions that were not specified during `vkb::PhysicalDeviceSelector`. This is by design as any feature or extension enabled *must* have support from the `VkPhysicalDevice`.
|
||||||
|
|
||||||
|
The common method to extend Vulkan functionality in existing API calls is to use the pNext chain. This is accounted for `VkDevice` creation with the `add_pNext` member function of `vkb::DeviceBuilder`. Note: Any structures added to the pNext chain must remain valid until `build()` is called.
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
VkPhysicalDeviceDescriptorIndexingFeatures descriptor_indexing_features{};
|
||||||
|
|
||||||
|
auto dev_ret = device_builder.add_pNext(&descriptor_indexing_features)
|
||||||
|
.build ();
|
||||||
|
```
|
||||||
|
|
||||||
|
### Queue Selection and Querying
|
||||||
|
|
||||||
|
By default, `vkb::DeviceBuilder` will enable one queue from each queue family available from the `VkPhysicalDevice` unless otherwise specified. This is due to the variety of possible combinations of queue families on different hardware.
|
||||||
|
|
||||||
## Swapchain
|
## Swapchain
|
||||||
// TODO
|
// TODO
|
||||||
## Error Handling
|
|
||||||
// TODO
|
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user