Vulkan: Implement basic integrated GPU profiling. #12262
Conversation
Currently simply measures the total GPU time of the frame. Will later be extended to get the execution time of individual render passes.
| VK_QUERY_RESULT_64_BIT); | ||
| if (res == VK_SUCCESS) { | ||
| double timestampConversionFactor = (double)vulkan_->GetPhysicalDeviceProperties().properties.limits.timestampPeriod * (1.0 / 1000000.0); | ||
| uint64_t timestampDiffMask = 0xFFFFFFFFFFFFFFFFULL; // TODO: Get from queue family |
There was a problem hiding this comment.
Seems like Adreno typically has 48, and PowerVR typically has 0 (unfortunate.)
Technically The command pool’s queue family must support a non-zero timestampValidBits is required, so we ought to check for PowerVR, but it seems like we're allowed to call vkCreateQueryPool (I think) even if that's zero. So shame on someone if they enable the ini on PowerVR...
-[Unknown]
There was a problem hiding this comment.
Yeah, not like we can do something about it anyway other than hide the option. Not gonna do the extra work for such crappy implementations...
| @@ -895,10 +950,20 @@ void VulkanRenderManager::BeginSubmitFrame(int frame) { | |||
| void VulkanRenderManager::Submit(int frame, bool triggerFence) { | |||
| FrameData &frameData = frameData_[frame]; | |||
| if (frameData.hasInitCommands) { | |||
| if (gpuProfilingEnabled_ && triggerFence) { | |||
| // Pre-allocated query ID 1. | |||
| vkCmdWriteTimestamp(frameData.initCmd, VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, frameData.timestampQueryPool_, 1); | |||
There was a problem hiding this comment.
Hm, ought we check the initCmd timing for subsequent submits in the frame (triggerFence = false)?
-[Unknown]
There was a problem hiding this comment.
Yeah probably, and we should subtract the time spent between the submits and show that separately. Thought I'd leave that for later.
| vkCmdResetQueryPool(initCmd, frameData.timestampQueryPool_, 0, MAX_TIMESTAMP_QUERIES); | ||
| vkCmdWriteTimestamp(initCmd, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, frameData.timestampQueryPool_, 0); | ||
| } else { | ||
| frameData.numQueries = 0; |
There was a problem hiding this comment.
Hm, should we frameData.timestampDescriptions.clear(); here? And really before the other path too?
Actually, is there are scenario where we want frameData.timestampDescriptions.size() != frameData.numQueries? It seems like we could just use the vector only.
-[Unknown]
There was a problem hiding this comment.
Yeah definitely, embarrassing mistake.
As for the separate variable, I had originally intended a description-less mode for a smaller performance hit but I don't think it's worth the trouble any more.
…scompilations when reading config with inconsistent ifdefs set.
Currently simply measures the total GPU time of the frame, split into init and main command buffers. Will later be extended to get the execution time of individual render passes.
Enabled using a checkbox in the "Dev menu" (or permanently through ini file).
The goal is to be able to quantify improvements from various attempts at GPU optimization. Framerate isn't good enough for comparisons if you're already at 60 on mobile.
Note: If the GPU is mostly idle it'll downclock. On PC you can unthrottle to get it to run at its proper performance. I'll also later investigate locking the GPU frequency, there are some methods.