Open FrancoisBeaune opened 3 years ago
I will take a look.
I am going to investigate #4219 first; it may possibly be causing this one.
The fix for #4219 did not help.
Clue: The DebugPrintf version is blowing up to twice the size of the non-DebugPrintf.
Shouldn't take too long to track down.
Well, I have found one case in an optimization sequence where there is a 3-4x growth in the size of the DebugPrintf version but it will a little more analysis to figure out what's going on and what to do about it.
In general, this is not seem like some simple bug. Rather it looks like the DebugPrintfs are causing extra code to stick around causing aggregate negative effects downstream.
I need to attend to some other work, so I will not be able to get back to this for at least a week. Regrets.
Thanks for the updates Greg, your work is much appreciated here! We're looking forward to this bug being squashed, even if it takes a little bit of time. Thanks again.
Hi Greg,
Did you have a chance to get back to this?
This ZIP file contains two large, nearly identical shaders in SPIR-V form that differ only as follow:
shader-with-debugPrintfEXT.spv
hasdebugPrintfEXT()
statementsshader-without-debugPrintfEXT.spv
doesn'tThey were compiled with glslangValidator from Vulkan SDK 1.2.170.0 [1].
Running spirv-opt on
shader-without-debugPrintfEXT.spv
(withoutdebugPrintfEXT()
statements) takes 21 seconds.Running spirv-opt on
shader-with-debugPrintfEXT.spv
(withdebugPrintfEXT()
statements) takes 172 seconds (2 min 52).Is there any fundamental reason why a few
debugPrintfEXT()
statements would cause optimization times to explode, or is this a bug?[1] Full output of
glslangvalidator --version
: