• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 137 subscribers
  • Views 1381 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

vulkan app drawcall timing

rchakena

Hello forum,

I am looking for a tool recommendation which can provide per drawcall time for vulkan application frame, similar to what renderdoc provides. (refer the link)

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/13/2161.renderdoc.PNG

I tried renderdoc, but the time value does not look reliable. (either too high or too low). The renderdoc github mentioned that it is not recommended for timing capture. Also, ARM tools like streamline or graphics analyzer doesn't seem to have any option to get per drawcall time.

So looking for other alternative tools to get this info.

Parents
  • +1

    There isn't a good way to do this on a tile-based GPU, because draw calls don't exist as single monolithic entities. They are processed as multiple disjoint pieces, interleaved with other render passes and other draw calls from the same render pass. Timing whole render passes is about as good as it gets unfortunately. 

    I believe RenderDoc is using timer queries around draw calls, which will only work for an immediate-mode GPU. (EDIT - Just to clarify the Mali behavior here, timer query ranges inside a render pass will just show the start and end time of the render pass).

    There are invasive techniques that give hints - you can render the same render pass twice with draws disabled in the second run and compare, for example. However, that's still not entirely accurate because pixel coverage of remaining draws changes and it will change the effects of hidden surface removal.

    Cheers, 
    Pete

Reply
  • +1

    There isn't a good way to do this on a tile-based GPU, because draw calls don't exist as single monolithic entities. They are processed as multiple disjoint pieces, interleaved with other render passes and other draw calls from the same render pass. Timing whole render passes is about as good as it gets unfortunately. 

    I believe RenderDoc is using timer queries around draw calls, which will only work for an immediate-mode GPU. (EDIT - Just to clarify the Mali behavior here, timer query ranges inside a render pass will just show the start and end time of the render pass).

    There are invasive techniques that give hints - you can render the same render pass twice with draws disabled in the second run and compare, for example. However, that's still not entirely accurate because pixel coverage of remaining draws changes and it will change the effects of hidden surface removal.

    Cheers, 
    Pete

Children