Conversation
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.
Describe the pull request
This PR implements support for GPU-based time measurements. This works by defining one or more Timing Events, that are written to a command buffer during frame drawing. If the frame has finished drawing (i.e., the next time the swap chain swaps back to the frame's back buffer), the results of the measurements are read and can be requested from the event.
Usage
During initialization (usually in the startup-callback for a backend), all timing events need to be registered:
Note that it is possible to insert more events during runtime, but this results in re-creation of query pools/heaps, which may be inefficient.
When drawing a frame, the events can be set on a command buffer:
Finally, the events themselves can be used to acquire the current readings. In this example, the duration is converted into milliseconds and then written into a string.
Note that timestamp queries are asynchronous, so the readings are not representing the last frame drawn by the app, but the last presented frame. Also note that the timestamps are expressed as 64 bit ticks, which need to be converted into milliseconds by querying the
ticksPerSecondproperty of the current device.Known issues
When using the native Vulkan swap chain, the validation layers in some rare occasions complain about a query pool not being reset properly. Usually, this only means that the readings are not valid in those instances, but since the behavior is undefined, it is best not to rely on this feature when using this swap chain. This does not happen when using the D3D interop swap chain.