-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
[Regression] LoadThreadedGetStatus stuck in ThreadLoadStatus.InProgress forever #92844
Comments
I can reproduce in v4.3.beta1.official [a4f2ea9] with the MRP ported to GDScript: |
Bisecting points to #91630 as the culprit: |
Just to add to this, i dont know if its an actual design choice or a bug, but, lets say you call LoadThreadedRequest on asset X from code A, then on somewhere else, at code B, you also call LoadThreadedRequest on same asset X, after that, whoever of the code A or B, after the loading is complete, calls LoadThreadedGet on asset X first, will get the asset, but the second one (and all subsequents), will get an error stating its an invalid asset, requiring it to call LoadThreadedRequest on asset X yet again. Basically a LoadThreadedRequest on given asset can only be LoadThreadedGet once, so if several places calls the same asset to be loaded, only the first to call the get after its loaded will get it, and all others will need to request yet again. |
That would be a bug. Threaded load requesters don't need to be aware of others. One request and it can get, independently from others doing the same in parallel or not. When a threaded load is requested, a load token is created internally with a reference count that keeps it alive until all the load results have been collected. |
The problem here is that the loader thread needs to query the rendering server for some operation performed by the
That #91630 triggers a regression with the usage of the API in the MRP is just a symptom. Even if it was reverted, resources could still query the rendering server as part of they being loaded, during the first phase, before the command queue is involved. The issue would still be there, despite being harder to hit. It's a matter of how the engine is designed.
@raulsntos, thanks for the GDScript MRP. |
Tested it indeed works in dev6, because #91630 wasn't still there, but, as explained above, it's more a lucky strike than a guaranteed behavior. |
I can confirm that adding RenderingServer.ForceSync(); fix the stuck problem, but I belive it should be more well documented in the ResourceLoader.LoadThreadedGetStatus method description. Chcecking the docs I couldn't find force_sync on the ResourceLoader page. Its also not clear to me in which ocasions I should use it. |
Tested versions
Bug found in: v4.3.beta1.mono.official [a4f2ea9]
Previous working in: Godot v4.3.dev6.mono
System information
Godot v4.3.beta1.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 31.0.15.3623) - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)
Issue description
Trying to use ResourceLoader.LoadThreadedGetStatus always return ThreadLoadStatus.InProgress
My debug points that even when progress is 1 the status is ThreadLoadStatus.InProgress
Steps to reproduce
You need to have a TileMapLayer node with a TileSet and the TileSet must have an image within it.
Use the minimal reproduction project below to test it, see that it never leaves the while.
Minimal reproduction project (MRP)
bug-thread.zip
The text was updated successfully, but these errors were encountered: