Add "force_pipeline_compilation_on_load" ProjectSetting

[clayjohn]

Describe the project you are working on

The Godot engine

Describe the problem or limitation you are having in your project

Despite making massive strides to reduce shader/pipeline compilation times, some users still experience pipeline compilation stutters at run time. Pipeline compilation stutters are tricky to work around and currently, Godot doesn't offer any tools to fully avoid them.

We are doing work towards compiling pipelines in the background so that we reduce stutters as much as possible, but it is unclear whether that will be enough to fully eliminate them.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This would move the cost of compiling pipelines to load time, so there are no stutters at runtime.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This feature would add an toggle to the ProjectSettings named "force_pipeline_compilation_on_load". When enabled, all pipelines will be compiled when the shader is loaded (same time the shader is compiled). This will substantially increase load times as even pipelines that never get used will be compiled. But it will move the entire cost to load time, so that developers can avoid pipeline compilation stutters at run time completely.

Basically, what is needed is a check during the pipeline assembly step (in shader_set_code), if enabled, the pipeline will be compiled right away instead of waiting to be used.

If this enhancement will not be used often, can it be worked around with a few lines of script?

There is no workaround

Is there a reason why this should be core and not an add-on in the asset library?

It is part of the core rendering code.

[Calinou]

Can PSOs be cached so that this startup time cost only has to be performed on the initial launch?

I wonder if this setting should be enabled in release builds by default (using the feature tag to override the project setting). This way, you don't have to wait longer when running the project from the debugger, or when running a project exported in debug mode.

It's important that the default experience for release builds is as stutter-free as possible, as a developer may not notice the issue during development (especially if they have a fast CPU). We also can't expect all developers to be aware of this setting before releasing their project.

[clayjohn]

Can PSOs be cached so that this startup time cost only has to be performed on the initial launch?

PSOs are cached by default. But caching does not help the initial compile time. And on some systems loading the cached pipeline still leads to a small stutter.

[jsjtxietian]

It sounds like the ShaderWarmup related API in Unity?

In a project I worked before, we have a shader pre warm list and the first time we load the game, the shaders and pipelines needs to be compiled and cached. And we end up trying to reduce the load time caused by this pre warm mechanism.

But anyway it is important to avoid pipeline compilation stutters at run time. Maybe we can find a way to avoid tremendous increasing the loading time.

[Calinou]

But anyway it is important to avoid pipeline compilation stutters at run time. Maybe we can find a way to avoid tremendous increasing the loading time.

You can perform shader warmup while in the game's main menu, so that the user can still adjust settings while it's doing shader warmup.

If the user starts a game while shader warmup is still being performed, display a warning asking them to wait, or allow them to skip at the cost of stuttering during gameplay.

[jsjtxietian]

If the user starts a game while shader warmup is still being performed, display a warning asking them to wait, or allow them to skip at the cost of stuttering during gameplay.

We should learn from Unity's mistake, the shader warmup api in Unity will block the main thread and make the main thread wait for every shader compilation is done, it's a pain for big projects (But it seems many 3A games suffer from long shader compile time too, maybe wo don't need to care about this part now).

[clayjohn]

Superseded by godotengine/godot#90400