Skip to content

Commit 51bb6d9

Browse files
authored
Align docu in 04_Logical_device_and_queues.adoc to the sources in 04_logical_device.cpp (#312)
1 parent 9e48635 commit 51bb6d9

1 file changed

Lines changed: 18 additions & 20 deletions

File tree

en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.adoc

Lines changed: 18 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -37,14 +37,15 @@ void createLogicalDevice() {
3737
== Specifying the queues to be created
3838

3939
The creation of a logical device involves specifying a bunch of details in
40-
structs again, of which the first one will be `VkDeviceQueueCreateInfo`. This
40+
structs again, of which the first one will be `vk::DeviceQueueCreateInfo`. This
4141
structure describes the number of queues we want for a single queue family.
4242
Right now we're only interested in a queue with graphics capabilities.
4343

4444
[,c++]
4545
----
4646
std::vector<vk::QueueFamilyProperties> queueFamilyProperties = physicalDevice.getQueueFamilyProperties();
47-
uint32_t graphicsIndex = findQueueFamilies(m_physicalDevice);
47+
auto graphicsQueueFamilyProperty = std::ranges::find_if(queueFamilyProperties, [](auto const &qfp) { return (qfp.queueFlags & vk::QueueFlagBits::eGraphics) != static_cast<vk::QueueFlags>(0); });
48+
auto graphicsIndex = static_cast<uint32_t>(std::distance(queueFamilyProperties.begin(), graphicsQueueFamilyProperty));
4849
vk::DeviceQueueCreateInfo deviceQueueCreateInfo { .queueFamilyIndex = graphicsIndex };
4950
----
5051

@@ -67,9 +68,9 @@ vk::DeviceQueueCreateInfo deviceQueueCreateInfo { .queueFamilyIndex = graphicsIn
6768

6869
The next information to specify is the set of device features that we'll be
6970
using. These are the features that we queried support for with
70-
`vkGetPhysicalDeviceFeatures` in the previous chapter, like geometry shaders.
71+
`vk::raii::PhysicalDevice::getFeatures` in the previous chapter, like geometry shaders.
7172
Right now we don't need anything special, so we can simply define it and leave
72-
everything to `VK_FALSE`. We'll come back to this structure once we're about to
73+
everything to `vk::False`. We'll come back to this structure once we're about to
7374
start doing more interesting things with Vulkan.
7475

7576
[,c++]
@@ -118,11 +119,11 @@ For our application to work properly, we need to enable certain device extension
118119

119120
[,c++]
120121
----
121-
std::vector<const char*> deviceExtensions = {
122+
std::vector<const char*> requiredDeviceExtension = {
122123
vk::KHRSwapchainExtensionName};
123124
----
124125

125-
The `VK_KHR_swapchain` extension is required for presenting rendered images to the window. The other extensions provide additional functionality that we'll use in later parts of the tutorial.
126+
The `VK_KHR_swapchain` extension is required for presenting rendered images to the window. Other extensions provide additional functionality that we'll use in later parts of the tutorial.
126127

127128
== Creating the logical device
128129

@@ -134,8 +135,8 @@ vk::DeviceCreateInfo deviceCreateInfo{
134135
.pNext = &featureChain.get<vk::PhysicalDeviceFeatures2>(),
135136
.queueCreateInfoCount = 1,
136137
.pQueueCreateInfos = &deviceQueueCreateInfo,
137-
.enabledExtensionCount = static_cast<uint32_t>(deviceExtensions.size()),
138-
.ppEnabledExtensionNames = deviceExtensions.data()
138+
.enabledExtensionCount = static_cast<uint32_t>(requiredDeviceExtension.size()),
139+
.ppEnabledExtensionNames = requiredDeviceExtension.data()
139140
};
140141
----
141142

@@ -149,9 +150,7 @@ Reviewing how we connect our feature chain to the device creation process:
149150

150151
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.
151152

152-
The remainder of the information bears a resemblance to the
153-
`VkInstanceCreateInfo` struct and requires you to specify extensions and
154-
validation layers. The difference is that these are device-specific this time.
153+
The remainder of the information bears a resemblance to the `vk::InstanceCreateInfo` struct and requires you to specify extensions. The difference is that these are device-specific this time.
155154

156155
An example of a device-specific extension is `VK_KHR_swapchain`, which allows
157156
you to present rendered images from that device to windows. It is possible that
@@ -163,7 +162,7 @@ Previous implementations of Vulkan made a distinction between instance and
163162
device-specific validation layers, but this is
164163
link:https://docs.vulkan.org/spec/latest/chapters/raytracing.html#extendingvulkan-layers-devicelayerdeprecation[no longer the case].
165164
That means that the `enabledLayerCount` and `ppEnabledLayerNames` fields of
166-
`VkDeviceCreateInfo` are ignored by up-to-date implementations.
165+
`vk::DeviceCreateInfo` are ignored by up-to-date implementations.
167166

168167
As mentioned earlier, we need several device-specific extensions for our application to work properly.
169168

@@ -173,10 +172,9 @@ device = vk::raii::Device( physicalDevice, deviceCreateInfo );
173172
----
174173

175174
The parameters are the physical device to interface with, and the usage
176-
info we just specified, the optional allocation callbacks pointer and a pointer
177-
to a variable to store the logical device handle in. Similarly to the instance
178-
creation function, this call can throw errors based on enabling non-existent
179-
extensions or specifying the desired usage of unsupported features.
175+
info we just specified. Similarly to the instance creation function, this
176+
call can throw errors based on enabling non-existent extensions or specifying
177+
the desired usage of unsupported features.
180178

181179
Logical devices don't interact directly with instances, which is why it's not
182180
included as a parameter.
@@ -194,10 +192,10 @@ vk::raii::Queue graphicsQueue;
194192
Device queues are implicitly cleaned up when the device is destroyed, so we
195193
don't need to do anything in `cleanup`.
196194

197-
We can use the `vkGetDeviceQueue` function to retrieve queue handles for each
198-
queue family. The parameters are the logical device, queue family, queue index
199-
and a pointer to the variable to store the queue handle in. Because we're only
200-
creating a single queue from this family, we'll simply use index `0`.
195+
We can use the `vk::raii::Queue` constructor to retrieve a queue handle for one
196+
queue family. The parameters are the logical device, queue family index, and queue
197+
index. Because we're only creating a single queue from this family, we'll simply
198+
use queue index `0`.
201199

202200
[,c++]
203201
----

0 commit comments

Comments
 (0)