[2022.26590] Long freeze when loading RayTK scene

The attached project stalls for 10+ minutes while loading.
The splash dialog shows 129,000+ nodes, but 0 updates.

Is it possible to determine what’s holding it up?

I am fairly confident that the issue is related to a RayTK scene / renderer in the included tox file, since those are the only changes made since I was last able to successfully load the project.

Attempting to drag the tox file into an empty project appears to cause the same issue for a limited time, but it is able to open eventually.

Looking at the thread stack traces it seems to be stuck in NvCV_GetErrorStringFromCode.

Hey @tekt

Thanks for the report.

I’m able to reproduce on my end and I will log an issue for a developer to look into it.

Best,
Michel

1 Like

It’s taking so long compiling and optimizing the GLSL. What has changed in the 2022 builds it that the GLSL is now compiled into SPIR-V, and then optimized. This is done using open source tools GLSLang and spirv-tools. It seems they are much slower than the Nvidia OpenGL drivers though, sadly.
I’ll do some profiling, but ideally if you can simplify your shaders at all, that may help.

1 Like

Yeah I was worried that was the issue.

Reducing code size has been an ongoing battle in RayTK. Right now a lot of it uses preprocessor macros to includes lots of different variants of things that are conditionally used when macros are present. I’m investigating a more targeted approach using python to dynamically generate the code, only including things that are needed based on the current conditions. It makes the code harder to maintain from a development standpoint, but it does reduce the size of the shader that gets sent to the compiler.

Are you able to tell if there’s anything causing it to compile multiple times? Maybe there’s something that I can do to reduce how often shader code is sent to the compiler.
The scene file in that zip has two render chains which in theory should mean 2 glsl TOPs, with each one compiling only once.

Preprocessor macros are actually fine, especially if they remove code. That will be super fast. The time is spent trying to optimize the final SPIR-V, which is the code generated from the post-processed GLSL.
I’m looking into it more

By the way, you can remove your #include test nodes, #include is supported for everything in the 2022 series. It’s done using TD code now, not the graphics drivers, so the support is consistent no matter what GPU is installed.

1 Like

This is confirmed to be a regression in spriv-tools, and has been fixed. I hope to be able to roll that fix into the next build we post. It should only take a few seconds to compile your large shader after that.

3 Likes

Excellent news!
Thanks!
That will make a huge difference for all RayTK users.

Do you know if dead code elimination happens before or after this compile step?
Would unused functions and such have an impact on it?

Deadcode elimination (not things done with #ifdef, but code that is never used), happens as part of the optimization pass.