Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let materials' shaders update happen on loader threads #91630

Merged
merged 1 commit into from
May 13, 2024

Conversation

RandomShaper
Copy link
Member

@RandomShaper RandomShaper commented May 6, 2024

Most important material types feature a dirty list that is processed every frame so those materials generate their internal shader. In the case of ShaderMaterial, its _shader_changed() function is also invoked (if running the editor). During threaded loading, there are some mechanics in place so such those operations don't happen until the load is known to have finished. They eventually happen on the main thread.

The problem in #90565 has to do with that. The resource previewer runs on a thread, from where it loads a material whose preview it wants to generate. Unfortunately, by the time the main thread would have had the chance to run the internal update, the shader is already gone (no error is printed about this). Also, the deferred call to _shader_changed() is attempted there on the already freed shader, which causes the error message.

A possible solution would have been to add some API so the resource previewer can somehow force the flush of the loader thread call queue right there instad of being transferred to the main one. However, after some analysis, I think we can just make those update operations happen on the loader thread organically (with added benefits). My only concern is that there might be some resource types that have a similar mechanism of deferred update in a way that they don't support such a thing happening on the loader thread. I can't think of any, but it's important to bear that in mind. If this is considered too risky for 4.3, I may provide a compromise fix for it and reschedule this PR for 4.4.

Finally, as a bonus, a little cleanup is made in terms of init-term, to make it more consistent across material types.

@akien-mga akien-mga merged commit 5cb9a74 into godotengine:master May 13, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

@RandomShaper RandomShaper deleted the enh_mat_sh_update branch May 13, 2024 17:19
@mihe
Copy link
Contributor

mihe commented May 13, 2024

@akien-mga This turned out to supersede #91768, so #58818, #69861 and #70974 should be closed as a result of this being merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment