Comment usage of waitIdle in chapter 15

[asuessenbach]

You definitely don't need to device.waitIdle() after every frame. It's enough to wait in cleanup() (Well, with caution, see VK_EXT_swapchain_maintenance1 extension).

The queue.waitIdle() in drawFrame() is not needed, when you have swapChainImages.size() renderFinishedSemaphores.

If this is considered to be ok, I can carry that change to all the other chapters.

[gpx1000]

Yep, definitely a good change.

[asuessenbach]

If this is considered to be ok, I can carry that change to all the other chapters.

I just realized, that none of the other chapters use waitIdle per frame, and all the other chapters are already using multiple renderFinishedSemaphores.
That is, this PR is ready for merging.

[SaschaWillems]

Prob. something that's generally wrong in the tutorial: I think we also need to have a vector for the presentCompleteSemaphore semaphores that's sized by max. no of frames in flight.

See #65

[charles-lunarg]

IIRC the wait idle is because frames in flight hasn't been introduced yet.

So it is there to make sure everything behave correctly with only one semaphore for acquire and one for present.

[asuessenbach]

IIRC the wait idle is because frames in flight hasn't been introduced yet.

That sounds reasonable!
But it should contain some very visible comment in the code then, that that waitIdle is just for this sample and should not be used in production code.

[SaschaWillems]

The waitIdle is mentioned in the documentation side of the tutorial. But yes, that mention should at least add some detail on that and tell readers that waididle shouldn't be used.

[charles-lunarg]

Agreed, waitIdle should have been better described.

I would be 100% for replacing waitIdle with proper usage of semaphores, especially the present semaphore array with size of swapchain image count. In fact, since it is best practice to have swapchain image count present semaphores, it would be better to only ever introduce present semaphores as an array (never as a single object) because the usage of the semaphore escapes outside of the applications direct control.

I commented initially just to give context why, but I do not want to claim that it is the only way things must be done 😄

[charles-lunarg]

Approving to mark that I agree with the intent of the changes. (I did not heavily review the content for full clarity).

[SaschaWillems]

If we agree on this, documentation also needs to be updated to reflect this change.

[gpx1000]

I 100% agree! Will need to update documentation. Sorry didn't have internet over the weekend; just now catching up.

[asuessenbach]

I reverted most of my changes, as the use of multiple semaphores is introduced in the next chapter.
That is, it's just some comments added now.