Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions attachments/16_frames_in_flight.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -330,7 +330,6 @@ class HelloTriangleApplication
vk::PipelineShaderStageCreateInfo fragShaderStageInfo{.stage = vk::ShaderStageFlagBits::eFragment, .module = shaderModule, .pName = "fragMain"};
vk::PipelineShaderStageCreateInfo shaderStages[] = {vertShaderStageInfo, fragShaderStageInfo};


vk::PipelineVertexInputStateCreateInfo vertexInputInfo;
vk::PipelineInputAssemblyStateCreateInfo inputAssembly{.topology = vk::PrimitiveTopology::eTriangleList};
vk::PipelineViewportStateCreateInfo viewportState{.viewportCount = 1, .scissorCount = 1};
Expand Down Expand Up @@ -392,7 +391,8 @@ class HelloTriangleApplication
{
auto &commandBuffer = commandBuffers[frameIndex];
commandBuffer.begin({});
// Before starting rendering, transition the swapchain image to COLOR_ATTACHMENT_OPTIMAL

// Before starting rendering, transition the swapchain image to vk::ImageLayout::eColorAttachmentOptimal
transition_image_layout(
imageIndex,
vk::ImageLayout::eUndefined,
Expand Down Expand Up @@ -420,7 +420,8 @@ class HelloTriangleApplication
commandBuffer.setScissor(0, vk::Rect2D(vk::Offset2D(0, 0), swapChainExtent));
commandBuffer.draw(3, 1, 0, 0);
commandBuffer.endRendering();
// After rendering, transition the swapchain image to PRESENT_SRC

// After rendering, transition the swapchain image to vk::ImageLayout::ePresentSrcKHR
transition_image_layout(
imageIndex,
vk::ImageLayout::eColorAttachmentOptimal,
Expand Down
16 changes: 8 additions & 8 deletions en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -43,14 +43,13 @@ std::vector<vk::raii::Fence> inFlightFences;

Then we need to create multiple command buffers.
Rename `createCommandBuffer` to `createCommandBuffers`.
Next we need to resize the command buffers vector to the size of `MAX_FRAMES_IN_FLIGHT`, alter the `VkCommandBufferAllocateInfo` to contain that many command buffers, and then change the destination to our vector of command buffers:
Next we need to resize the command buffers vector to the size of `MAX_FRAMES_IN_FLIGHT`, alter the `vk::CommandBufferAllocateInfo` to contain that many command buffers, and then change the destination to our vector of command buffers:

[,c++]
----
void createCommandBuffers() {
commandBuffers.clear();
vk::CommandBufferAllocateInfo allocInfo{ .commandPool = commandPool, .level = vk::CommandBufferLevel::ePrimary,
.commandBufferCount = MAX_FRAMES_IN_FLIGHT };
void createCommandBuffers()
{
vk::CommandBufferAllocateInfo allocInfo{.commandPool = commandPool, .level = vk::CommandBufferLevel::ePrimary, .commandBufferCount = MAX_FRAMES_IN_FLIGHT};
commandBuffers = vk::raii::CommandBuffers( device, allocInfo );
}
----
Expand All @@ -59,7 +58,8 @@ The `createSyncObjects` function should be changed to create all the objects:

[,c++]
----
void createSyncObjects() {
void createSyncObjects()
{
assert(presentCompleteSemaphores.empty() && renderFinishedSemaphores.empty() && inFlightFences.empty());

for (size_t i = 0; i < swapChainImages.size(); i++)
Expand All @@ -80,7 +80,7 @@ We will use a frame index for that purpose:

[,c++]
----
uint32_t frameIndex 0;
uint32_t frameIndex = 0;
----

The `drawFrame` function can now be modified to use the right objects:
Expand Down Expand Up @@ -133,7 +133,7 @@ be known with a fence whether the semaphore is ready for re-use.
We've now implemented all the necessary synchronization to ensure that there
are no more than `MAX_FRAMES_IN_FLIGHT` frames of work enqueued and that
these frames are not stepping over each other.
Note that it is fine for other parts of the code, like the final cleanup, to rely on more rough synchronization like `vkDeviceWaitIdle`.
Note that it is fine for other parts of the code, like the final cleanup, to rely on more rough synchronization like `vk::raii::Device::waitIdle`.
You should decide on which approach to use based on performance requirements.

Additionally, we could use timeline semaphores instead of the binary
Expand Down
Loading