search

KhronosGroup / glslang

Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.
Other
3.01k stars 829 forks source link

No #line directives generated when --target-env is vulkan1.1, vulkan1.2 or vulkan1.3 #3192

Open TonyBarbour opened 1 year ago

TonyBarbour commented 1 year ago

GPU-AV depends on #line directives to determine which source line is responsible for a validation error. glslang is generating #line directive(s) with --target-env vulkan1.0, but not vulkan1.1, 1.2, or 1.3. #line is also created when no --target-env is specified. Issue is at https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/5596

corporateshark commented 10 months ago

We have the same problem in LightweightVK when using glslang C-interface. No SPIR-V OpSource is generated when emit_nonsemantic_shader_debug_source is enabled.

https://github.com/corporateshark/lightweightvk/blob/d1c511d9bfaf8e96c0efa00a33b7bec5d1cd7e79/lvk/vulkan/VulkanUtils.cpp#L649

arcady-lunarg commented 10 months ago

@corporateshark I think that is a somewhat different issue, could you open a new issue for your problem? Also, could you confirm that you're using the most recent version of glslang as there was a somewhat similar sounding bug that was fixed recently.

spencer-lunarg commented 3 months ago

I am taking over the original VVL issue posted

I just tested with -g and it seems to display both OpLine/OpSource with all --target-env and I don't know if this is still an issue anymore or not (for glslang)

Timbals commented 1 month ago

Leaving my observations here as I noticed this behavior as well.

For SPIR-V versions before 1.1 (which means before Vulkan 1.1) the OpModuleProcessed instruction is not supported. glslang still adds this information for SPIR-V 1.0. But it has to put it directly in the source code as comments. But adding these comments at the start of the source code offsets any OpLine instructions, so a #line 1 directive is emitted after the comments to specify the start of the "real" source code lines. That generally looks like this:

// OpModuleProcessed entry-point main
// OpModuleProcessed auto-map-bindings
// OpModuleProcessed client vulkan100
// OpModuleProcessed target-env vulkan1.0
// OpModuleProcessed entry-point main
#line 1

The relevant code that does this is here: https://github.com/KhronosGroup/glslang/blob/a496a34b439022750d41d2ba04fbbe416ef81c9a/SPIRV/GlslangToSpv.cpp#L1563-L1577

As far as I can tell the #line directive is non-standard, and not universally supported by all tools. For example, I've had issues with the line attributions in the shader profiler of NVIDIA Nsight being offset because it doesn't support the #line directive. So I think the current behavior is good because targeting a higher SPIR-V version removes that offset. If anything, the comments should be added to the end of the file without a #line directive, to prevent line numbers being offset.

The issue in the Vulkan validation layers seems to have been fixed as well, and it correctly uses the line numbers as-is when no #line directive was found.

I think this is working as intended and this issue can be closed.