Looking the Vulkan example code, I’m putting breakpoints at the spots where the shader database class is used (OnShaderLookup(), OnShaderSourceDebugInfoLookup(), ShaderDatabase::FindShaderBinaryWithDebugData() etc.), however those callbacks never get called. I’ve tried changing GFSDK_Aftermath_GpuCrashDumpFeatureFlags_DeferDebugInfoCallbacks to GFSDK_Aftermath_GpuCrashDumpFeatureFlags_Default but that doesn’t change the behavior.
Since we are given the shader binary in the call to OnShaderDebugInfo(), in what cases will the shader database get used?
Hello,
Thank you for using Nsight Aftermath and your question. I will contact the engineering manager responsible for Nsight Aftermath and one of us will close the loop with you on your concern. We will get back to you.
The files in the shader database are used when you load the crash dump into Nsight Graphics. It is part of what we need to map from the microcode running on the GPU to the original source code. The “DeferDebugInfoCallbacks” flag defers the callback from the time the shader is compiled until the event of an actual crash, and will only be called for shaders involved in the crash. When you get the callback, you should save the files to disk with a nvdbg extension, which is what the GpuCrashTracker helper class will do.
Thanks Jeff,
Is there any way to see it in-action? In the Vulkan sample code I can’t seem to make any of the the codepaths that make use of it go off.
Thanks
Malcolm
Related question, is there any reason why the SPIR-V isn’t automatically included in the nvdump file, and then disasembled into GLSL when viewing it in Nsight? At least as a backstop. The GLSL disassembly that is used when doing profile workflows within Nsight tends to be quite useful.
Let me investigate why you are not seeing it work with the Vulkan sample…as it should.
The main reason we don’t include the SPIR-V is just to try and keep the dump file(s) manageable. We could consider doing a similar disasm in Aftermath that we do in the profiler, but we haven’t had many requests for it. I will put your name on such a feature request.
Thanks for the consideration. The end user would need to gather up all of the outputted files anyways, so it’s the same overall size either way. The less files they need to wrangle the easier it is for an end-user to provide a crash report for us. I can also provide the non-stripped versions of the SPIR-V to Vulkan to give your driver full information. Honestly it would be even better if the .json also get embeded into the nvdump file, making it even less error prone for users to send us dump files.
Thanks!
To answer my own question a little. I can see that that shader database does get used if I set use_stripped_shaders = true
However the GLSL source isn’t visible for that .nvdmp, so it’s a little unclear to me what the result of ShaderDatabase::FindShaderBinaryWithDebugData() is used for. Shouldn’t that be providing the information needed to find the GLSL code line? If not, what information is it providing?