Closed mihaly-sisak closed 1 month ago
Thank you for reporting this issue. Would you be able to post an example of a shader that behaves differently with --merge-return
?
The input file is a 11 kLOC file that contains almost all of my glsl source code. Is it possible to provide an example without it being public?
It would be better if you were able to provide a minimal reproducible example of a SPIR-V shader which has this issue. You might be able to create one semi-automatically using spirv-reduce
on <filename>.spv
. In the "interestingness function", you'd want to run glslang -O
and test for whether the behavior has changed.
It may also help if you can describe the change in the behavior of glsl shaders after running the merge-return
pass.
We will close this issue because there is nothing we can do with the current information. Please open a new issue when with more information on how to reproduce it.
The input file is a 11 kLOC file that contains almost all of my glsl source code. Is it possible to provide an example without it being public?
I'm not sure how our legal team would feel about it.
I try to ship optimized OpenGL code in my game EvoLife. Without this steps the shader compilation takes longer on first launch. My optimizing pipeline:
My problem is that I can not run spirv-opt with -O, I have to use -Oconfig with the file attached. My starting point was the -O list and I bisected which options cause issues. glsl_opt_config.txt Line 3 --merge-return: causes glsl shaders to behave differently than unoptimized versions Line 4 --inline-entry-points-exhaustive: can not run without merge-return Line 40 and 43 --merge-blocks: causes spirv-cross to abort on some shaders
Please let me know how can I help to resolve this problem. In the meantime maybe others will find this and can use the same workaround.