microsoft
[SPIR-V] debug info should emit DebugEntryPoint with compiler info
The SPIR-V debug information emitted via NonSemantic.Shader.DebugInfo.100 doesn't currently emit DebugEntryPoint for the entry point being compiled.
This is a useful piece of metadata as it includes the compiler identifier itself and importantly the command line arguments, which can then be used to recompile the shader together with the embedded source code, potentially including modifications.
This is required to allow RenderDoc to auto populate the DXC command line arguments for shader editing and is something that works in glslang (I believe there the mechanism used was OpModuleProcessed). Adding support for this would be very helpful in allowing us to do shader edits in RenderDoc. Right now, for shaders generated with DXC with debug info, it doesn't auto populate the compile options.
@baldurk What would RenderDoc want to see for a format for the Compiler Signature? Should the compiler be just dxc/glslang/other? The full name of the executable? The full path of the executable? Should the version just be the latest commit hash as is done by dxc for OpModuleProcessed? Or the semantic version number printed by --version? Should the version be separated from the compiler name just by white space?
Should the Command-line Arguments be truly the command line arguments as dxc does for OpModuleProcessed? Or should they be process/argument pairs as glslang does for OpModuleProcessed? Or can each processor do their own thing?
@baldurk Here is an example of the way that glslang does command line for OpModuleProcessed:
OpModuleProcessed "client vulkan100"
OpModuleProcessed "target-env spirv1.5"
OpModuleProcessed "target-env vulkan1.2"
OpModuleProcessed "entry-point main"
I think the signature is primarily for debugging/human use, e.g. if a miscompilation is found then the compiler can be identified to see if a bugfix is present or not. I don't think it's realistic to have tools programmatically do anything with that information, but I think a simple form of compiler_executable numeric.version commitsha would be best at least for dxc/glslang to not make it harder than necessary, though other compilers of course may not neatly follow this scheme.
The command line arguments yes should be literally the command line arguments that can be passed to the compiler to re-compile, minus the input filename. The purpose being that tools using this debug info should not have to have intimate knowledge of what command line arguments are supported and how they're constructed to re-use the command line. If a tool does want to introspect the command line then it can parse it just like a command line parser (since this is a pretty well defined and simple parsing) and modify it should they wish, and then the tool can decide what to do with unknown arguments etc.
OpModuleProcessed should be ignored effectively, its design was never reliable and needing to know how to stitch together the command line per-tool wasn't scalable (especially with e.g. contradictory command line options like that, and cases in the past where the OpModuleProcessed didn't match the command line).