From 03f1befbc714f111c97698891ec621869cdda580 Mon Sep 17 00:00:00 2001 From: swinston Date: Thu, 20 Aug 2026 21:00:52 -0700 Subject: [PATCH] en: fix duplicate device-extension doc and Frames-in-flight vector gaps Swap chain: remove the "Enabling device extensions" section, which re-taught device creation already shown in Logical device and queues. Frames in flight: explain the drawFence -> inFlightFences rename and add the missing local commandBuffer reference in recordCommandBuffer. --- .../01_Presentation/01_Swap_chain.adoc | 33 +++---------------- .../03_Drawing/03_Frames_in_flight.adoc | 17 +++++++++- 2 files changed, 21 insertions(+), 29 deletions(-) diff --git a/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc b/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc index 5047177f..21206674 100644 --- a/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc +++ b/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc @@ -41,34 +41,11 @@ std::vector requiredDeviceExtension = { It should be noted that the availability of a presentation queue, as we checked in the previous chapter, implies that the swap chain extension -must be supported. However, the extension does have to be explicitly enabled. - -== Enabling device extensions - -Using a swapchain requires enabling the `VK_KHR_swapchain` extension first. -Enabling the extension just requires a small change to the logical device -creation structure: - -[,c++] ----- -deviceCreateInfo.enabledExtensionCount = requiredDeviceExtension.size(); -deviceCreateInfo.ppEnabledExtensionNames = requiredDeviceExtension.data(); ----- - -Alternatively, we can do this at the construction and keep this very succinct: - -[,c++] ----- -std::vector requiredDeviceExtension = { vk::KHRSwapchainExtensionName }; - -float queuePriority = 0.5f; -vk::DeviceQueueCreateInfo deviceQueueCreateInfo{.queueFamilyIndex = queueIndex, .queueCount = 1, .pQueuePriorities = &queuePriority}; -vk::DeviceCreateInfo deviceCreateInfo{.pNext = &featureChain.get(), - .queueCreateInfoCount = 1, - .pQueueCreateInfos = &deviceQueueCreateInfo, - .enabledExtensionCount = static_cast(requiredDeviceExtension.size()), - .ppEnabledExtensionNames = requiredDeviceExtension.data()}; ----- +must be supported. We already passed `requiredDeviceExtension` to +`vk::DeviceCreateInfo` when +xref:../00_Setup/04_Logical_device_and_queues.adoc[creating the logical device], +so the extension is enabled and there's no further device-creation code +needed here. == Querying details of swap chain support diff --git a/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc b/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc index 6d68ce01..767e8a6b 100644 --- a/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc +++ b/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc @@ -28,7 +28,9 @@ Generally, extra latency isn't desired. But giving the application control over the number of frames in flight is another example of Vulkan being explicit. Each frame should have its own command buffer, set of semaphores, and fence. -Rename and then change them to be ``std::vector``s of the objects: +Rename and then change them to be ``std::vector``s of the objects. The single +fence, previously called `drawFence`, becomes `inFlightFences` here rather +than just gaining an `s`, since we now have one fence per frame in flight: [,c++] ---- @@ -83,6 +85,19 @@ We will use a frame index for that purpose: uint32_t frameIndex = 0; ---- +`commandBuffer` is now a vector too, so `recordCommandBuffer` can no longer +use it directly - add a local reference to the buffer for the current frame +at the top of the function: + +[,c++] +---- +void recordCommandBuffer(uint32_t imageIndex) +{ + auto &commandBuffer = commandBuffers[frameIndex]; + ... +} +---- + The `drawFrame` function can now be modified to use the right objects: [,c++]