spirv-opt: --inst-debug-printf produces "Definition is not registered"

[natevm]

I ran into this issue while adding support for some mixed shader stages when instrumenting debug printf.

Given the following code (HLSL -> SPV via dxc):

void commonFunction() {
  printf("Common function!\n");
}

[shader("miss")]
void MissProg(inout int tmp) {
    commonFunction();
}

I can produce the following unoptimized SPV deviceCode_unoptimized_as.spv.txt:

Sending this .spv file through spirv-opt with the following passes: --inline-entry-points-exhaustive --inst-debug-printf

produces the following error: Assertion failed: def && "Definition is not registered.", file SPIRV-Tools\source\opt\def_use_manager.cpp, line 56

[natevm]

@greg-lunarg any ideas what might be going wrong here? Perhaps it’s not expected for —inst-debug-printf to be used from the command line?

[greg-lunarg]

Sorry. Missed this when it first came in. Hopefully you will have figured out how to use debug printf by this time. If not, please read on.

--inst-debug-printf is not a supported option for spirv-opt. It is not documented in the spirv-opt usage. The command line option was created as a debug aid for the developer (me) during the initial development of the debug printf capability. I will remove it.

Please refer to the following URL for help on how to use debug printf in Vulkan: https://vulkan.lunarg.com/doc/sdk/1.3.243.0/windows/debug_printf.html

[greg-lunarg]

The command line option was created as a debug aid for the developer (me) during the initial development of the debug printf capability. I will remove it.

I have been persuaded to keep this in the CLI to facilitate debugging and fixing the instrumentation. I will instead add comments to warn users to use VVL to access debug printf.

@natevm BTW, I ran your SPIR-V through the latest version of --inst-debug-printf and it processes cleanly and generates valid SPIR-V. Once again, I apologize for the tardy response.

[natevm]

It’s been so long I have a hard time remembering, but I believe this issue was a blocker for issue/PR #4893 which was on enabling prints to work in mixed shader entry point environments. That PR unfortunately closed without resolution. Maybe we could open that up again now? Unless things have changed?

My ultimate goal was to achieve a similar power to OptiX and allow prints throughout a ray tracing pipeline without requiring users break up their program into separate shader compilation units.

Times have changed, and I’m bogged down on other tasks at the moment. But yeah, hopefully having this issue resolved will fix some growing pains.

[greg-lunarg]

It looks like #4893 can move ahead by adding tests as requested by @s-perron .