Deadlock in multithreaded importer for .obj files, or "Creating buffers with data is forbidden during creation of a draw list" error #48265
Labels
Milestone
Comments
Calinou
changed the title
.mtl file
|
Can confirm this is still happening in |
|
As #51315 mentions, does it work if you create an empty Alternatively, you could edit the OBJ file to remove the MTL reference and create materials manually. |
|
You shouldn't need to have an extra mtl file as a requirement when importing an obj. I have never seen that requirement in any application before. Personally, I mostly tend to export obj without mtl's and only export with an mtl if I need access to multiple poly selections in Godot to apply multiple materials. In this circumstance, I don't actually use the imported materials themselves for anything other than maybe a placeholder. I probably should move over to using gltf for everything, but obj has just been so reliable for static objects for a long time, and every application exports them flawlessly. |
Godot has no such requirement. Still, many applications will export MTL files by default, even if you don't need those MTL materials. The MTL material specification is very limited by today's standards (no PBR), so it's only really usable for placeholders or oldschool games unless you adopt nonstandard modifications to the file format. Reading #51315, the issue seems to be that Godot crashes when a nonexistent MTL file is referenced. Instead, it should print a warning and continue importing. |
|
Yes, this is exactly what the issue is. Obj import now only works if you have the mtl, but not if there is no corresponding mtl file (which for my projects is most of the time). As mentioned I only export mtl to get access to poly selections in Godot for certain meshes. |
|
I'm not sure the problem is limited to Here's a full backtrace for all threads when the deadlock happens: And specially the thread where the Anyway, I'll disable multi-threaded import for OBJ as a workaround for now. But we still need to figure out why this bug happens and ideally solve it. |
|
I can reliably reproduce a deadline in current They're from Kenney's retro medieval kit linked above, but with all |
akien-mga
changed the title
.mtl file
|
Disabling threaded import works it around, and it now raises an error, probably at the point where the deadlock used to happen: |
|
#52865 should solve the issue (no more deadlocks), but I suggest keeping this issue open as the real underlying bug is not fixed, just mitigated. The deadlock can be reproduced again by reverting #52865 locally, or most likely investigating and fixing the errors in #48265 (comment) would also solve the deadlock issue and let us re-enable threaded import for OBJ meshes. About the above error, it's worth noting the two On a simpler MRP without anything to import, they're the last lines printed when running the editor in verbose mode, so it points at a race condition where we're importing meshes before the present mode has been set, and thus maybe before the Vulkan renderer is fully set up? |
akien-mga
changed the title
akien-mga
added a commit
to akien-mga/godot
that referenced
this issue
Sep 20, 2021
This can currently lead to deadlocks, possibly due to some race condition in the Vulkan renderer. Works around godotengine#48265.
|
The deadlock occurs because the obj importer threads require access to the rendering server while the main thread is locked waiting for the import thread pool to finish. This wouldn't be an issue if the editor was not forced into main thread rendering mode. Other meshes that import as scenes (gltf, for example) do not have this issue because the scene resource importer disables threaded importing. Perhaps in the future the editor could allow rendering on a separate thread, and the applicable importers could check this setting?
In the current state of the vulkan renderer, if a separate thread tries to use certain functions in the renderer while it's creating draw lists, the renderer just errors away the attempt. Draw lists need to be made threadsafe. I'm currently attempting to fix that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Godot version:
4.0.dev 1c2766e
OS/device including version:
Windows 10.0.19041.928
Issue description:
I had a deadlock occur while reimporting my project containing a few .obj files, as well as a plethora of random content.
The last output is:
Stacktraces from the two relevant threads are as follows:
and both of the stalled importer threads had the same stacktrace as follows:
In case it's relevant, I have stacktraces from all threads saved in the following gist:
https://gist.github.com/lyuma/11dc95ac44db79c9af54aacd61ee7f37
Notably, I was unable to find a RenderingServer thread.
Steps to reproduce:
Minimal reproduction project:
I have a 100MB zip file but it contains copyrighted files. I was able to reproduce the issue twice with this project.
I tried simplifying things, for example only including the .obj files. But I was not able to reproduce the issue on the simpler project. It does seem like a race condition.
The text was updated successfully, but these errors were encountered: