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

[phoronix]

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?page=news_item&px=GAPID-1.0-Released

[VikingGe]

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.

[awoloszyn]

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

[VikingGe]

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.

[awoloszyn]

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.

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.

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.