Merged
Conversation
… gfx context. * Write gxcontext to device through ezapp on init to let you call predictedRenderFinishTick from the device. * Several other cleanups and clarifications related to the swap render loop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Added some comments, TODOs and cleanup related to the swapchain render loop that I found when sorting through this.
Due to how the waitFrame was setup, and also another bug which called vkDeviceWaitIdle every frame, there was no frame pipelining. After each submit it would fully wait for that frame to finish. I did not change that behavior in this PR. It still fully waits for the frame to finish without pipelining. But I made a few changes to make this behavior more apparent and easier to change. Specifically added an incrementFrame separate from the waitFrame, enuqueFrame and presentFrame calls so you can easily discern in which order it is queuing, presenting and waiting.
I found a chunk of the swapchain fence wait logic to not be necessary so I deleted it.