Announcement

Collapse
No announcement yet.

GAPID 1.0 Released As Google's Cross-Platform Vulkan Debugger

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GAPID 1.0 Released As Google's Cross-Platform Vulkan Debugger

    Phoronix: GAPID 1.0 Released As Google's Cross-Platform Vulkan Debugger

    Back in March we wrote about GAPID as a new Google-developed Vulkan debugger in its early stages. Fast forward to today, GAPID 1.0 has been released for debugging Vulkan apps/games on Linux/Windows/Android as well as OpenGL ES on Android...

    http://www.phoronix.com/scan.php?pag...D-1.0-Released

  • #2
    Seems like this isn't really suited for debugging desktop applications. Just fired up DXVK with one of the Microsoft SDK samples that it can already render correctly and let it record a couple of frames - not only did this software take several minutes to load the trace, after some clicking and playing around it consumed over 7 GiB of RAM, the interface was extremely sluggish, and it didn't even manage to display the final frame images correctly.

    There's one thing it does extremely well though: It provides an easy way to inspect the full state of every single Vulkan object. That's incredibly useful.

    Comment


    • #3
      Originally posted by VikingGe View Post
      Seems like this isn't really suited for debugging desktop applications. Just fired up DXVK with one of the Microsoft SDK samples that it can already render correctly and let it record a couple of frames - not only did this software take several minutes to load the trace, after some clicking and playing around it consumed over 7 GiB of RAM, the interface was extremely sluggish, and it didn't even manage to display the final frame images correctly.

      There's one thing it does extremely well though: It provides an easy way to inspect the full state of every single Vulkan object. That's incredibly useful.
      Thanks for taking the time to give GAPID a try and sharing your thoughts!
      For 1.0 our goal was correctness, and now that 1.0 has been released, our top priority is improving performance. There are a few changes on the way that should help.

      I have opened a Github issue to look into why the frame images were incorrect, and any more information you can provide would be incredibly helpful.
      https://github.com/google/gapid/issues/1504

      Comment


      • #4
        Originally posted by awoloszyn View Post
        I have opened a Github issue to look into why the frame images were incorrect, and any more information you can provide would be incredibly helpful.
        Quick question that came to my mind since vktrace is complaining about it as well: Does this require any specific kernel options in order to deal with persistently mapped buffers? If so, I can test this again in a "proper" environment. I did not think of this earlier since Renderdoc works without it.

        Also, is there any specific debug information you need?

        Anyway, once (significant) performance improves land I can definitely see myself using this.
        Last edited by VikingGe; 12-15-2017, 06:43 AM.

        Comment


        • #5
          Originally posted by VikingGe View Post
          Does this require any specific kernel options in order to deal with persistently mapped buffers?
          Nope, there should be nothing specific you have to do for us to handle these. We have some optimizations in place, however on some configurations they may be disabled if the driver won't play nice with them.

          Originally posted by VikingGe View Post
          Also, is there any specific debug information you need?
          The generated trace itself is the best thing for us to investigate. (Along with information such as GPU/Driver version).
          One thing that is possible to try as well, is turning off replay optimization. (There is an option in preferences.) If that makes the frame show up correctly, it can really help narrow down the issue.

          Originally posted by VikingGe View Post
          Anyway, once (significant) performance improves land I can definitely see myself using this
          One thing that may help in the interim with the UI performance is reducing the number of frames in the trace. How I typically work is turning off "trace from beginning" and tracing only the frames of interest. However from your post, it seems you may already be doing this.

          Comment

          Working...
          X