You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor validation layer checks and feature chaining in Vulkan setup
- Replace `checkValidationLayerSupport` function with inlined logic for layer validation.
- Improve clarity of Vulkan instance creation by directly validating required layers and extensions during initialization.
- Introduce `vk::StructureChain` for cleaner and more efficient feature chaining in logical device creation.
- Refactor debug messenger initialization to use non-pointer object and update Vulkan 1.3-specific features for better compatibility.
Copy file name to clipboardExpand all lines: en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.adoc
+41-38Lines changed: 41 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,50 +77,40 @@ start doing more interesting things with Vulkan.
77
77
vk::PhysicalDeviceFeatures deviceFeatures;
78
78
----
79
79
80
-
== Specifying any extra features or updates we'd like our device to support
80
+
== Enabling additional device features
81
81
82
-
Vulkan is built to be backwards compatible. Thus, if you do nothing else,
83
-
you will get a Vulkan instance just as it was originally released in Vulkan 1
84
-
.0. This is necessary as code written back then would need to still work so
85
-
any additional features must be new code which would need to be turned on.
86
-
So, let's tell Vulkan that we use some of the more modern features which make
87
-
it easier to work with.
82
+
Vulkan is designed to be backwards compatible, which means that by default, you only get access to the basic features that were available in Vulkan 1.0. To use newer features, you need to explicitly request them during device creation.
88
83
89
-
First, let's query for the features of the physical device:
84
+
In Vulkan, features are organized into different structures based on when they were introduced or what functionality they relate to. For example:
85
+
- Basic features are in `vk::PhysicalDeviceFeatures`
86
+
- Vulkan 1.3 features are in `vk::PhysicalDeviceVulkan13Features`
87
+
- Extension-specific features are in their own structures (like `vk::PhysicalDeviceExtendedDynamicStateFeaturesEXT`)
90
88
91
-
[,c++]
92
-
----
93
-
// query for Vulkan 1.3 features
94
-
auto features = physicalDevice.getFeatures2();
95
-
----
89
+
To enable multiple sets of features, Vulkan uses a concept called "structure chaining." Each feature structure has a `pNext` field that can point to another structure, creating a chain of feature requests.
96
90
97
-
Now, let's tell Vulkan that there's a few features we wish to use, by turning
98
-
on dynamicRendering and the extendedDynamicState.
91
+
The C++ Vulkan API provides a helper template called `vk::StructureChain` that makes this process easier. Let's see how to use it:
1. We create a `vk::StructureChain` with three different feature structures.
106
+
2. For each structure in the chain, we provide an initializer:
107
+
- The first structure (`vk::PhysicalDeviceFeatures2`) is left empty with `{}`
108
+
- In the second structure, we enable the `dynamicRendering` feature from Vulkan 1.3
109
+
- In the third structure, we enable the `extendedDynamicState` feature from an extension
118
110
119
-
Note here that features is the same object that we got when we queried the
120
-
physical device for the features. Each pNext member variable points to the
121
-
next feature structure in the chain. So all that's left is to ensure that
122
-
when we create the logical device with a VkDeviceCreateInfo structure we set
123
-
.pNext in that structure to the pointer to the features.
111
+
The `vk::StructureChain` template automatically connects these structures together by setting up the `pNext` pointers between them. This saves us from having to manually link each structure to the next one.
112
+
113
+
When we create the logical device later, we'll pass a pointer to the first structure in this chain, which will allow Vulkan to see all the features we want to enable.
124
114
125
115
== Specifying device extensions
126
116
@@ -140,16 +130,29 @@ The `VK_KHR_swapchain` extension is required for presenting rendered images to t
140
130
141
131
== Creating the logical device
142
132
143
-
With the previous structures in place, we can start filling in the main
144
-
`VkDeviceCreateInfo` structure.
133
+
With all the necessary information prepared, we can now create the logical device. We need to fill in the `vk::DeviceCreateInfo` structure and connect our feature chain to it:
Reviewing how we connect our feature chain to the device creation process:
147
+
148
+
1. The `featureChain.get<vk::PhysicalDeviceFeatures2>()` method retrieves a reference to the first structure in our chain (the `vk::PhysicalDeviceFeatures2` structure).
149
+
150
+
2. We assign this reference to the `pNext` field of the `deviceCreateInfo` structure.
151
+
152
+
3. Since all the structures in our feature chain are already connected (thanks to `vk::StructureChain`), Vulkan will be able to see all the features we want to enable by following the chain of `pNext` pointers.
153
+
154
+
This approach allows us to request multiple sets of features in a clean and organized way. Vulkan will process each structure in the chain and enable the requested features during device creation.
155
+
153
156
The remainder of the information bears a resemblance to the
154
157
`VkInstanceCreateInfo` struct and requires you to specify extensions and
155
158
validation layers. The difference is that these are device-specific this time.
0 commit comments