This commit adds timestamp query commands in Vulkan runner's
compute pipeline to gain insights into how long it takes to
run the compute shader. This commit also adds timing from CPU
side for VkQueueSubmit and vkQueueWaitIdle.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/tools/mlir-vulkan-runner/VulkanRuntime.cpp | ||
---|---|---|
17 | LLVM forbids the use of iostream. https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden |
Address comments
mlir/tools/mlir-vulkan-runner/VulkanRuntime.cpp | ||
---|---|---|
17 | Changed to llvm::outs. I saw we are using iostream already in RunnerUtils.h and cblas_interface.h so wanted to be consistent there. Should those be fixed? | |
722 | Thanks! I find the spec a bit difficult to parse: "latches the value of the timer when all previous commands have completed executing as far as the specified pipeline stage". I interpret it as the pipeline stage (VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT) controls when to write out the timestamp, not the placement of the vkCmdWriteTimestamp command. (Otherwise the pipeline stage specification does not really make sense.) But I do see there is a difference if I move the second vkCmdWriteTimestamp below vkCmdDispatch. So I'm a bit puzzled here. |
mlir/tools/mlir-vulkan-runner/VulkanRuntime.cpp | ||
---|---|---|
722 | I believe that vkCmdWriteTimestamp acts as an implicit vkCmdPipelineBarrier with the srcStageMask set to what you pass in (BOTTOM_OF_PIPE), so it effectively partitions the command buffer into two synchronization scopes based on the order the commands were recorded. |
mlir/tools/mlir-vulkan-runner/VulkanRuntime.cpp | ||
---|---|---|
17 | Isn’t cblas_interface for generated code intended to be used a runtime for generated code, including outside of a JIT environment? |
LLVM forbids the use of iostream.
https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden