AsyncComputeTaskPool blocking main thread on bevy 0.13+ for Linux

[jasonpeinko]

Bevy version

• release-0.13.x
• main

Relevant system information

• Arch Linux
• 6.9.2-zen1-1-zen Render Text #1 ZEN SMP PREEMPT_DYNAMIC Sun, 26 May 2024 01:30:09 +0000 x86_64 GNU/Linux
• rustc 1.78.0 (9b00956e5 2024-04-29)

What you did

Run bevy "async_compute" example.

What went wrong

Running async_compute example on bevy 0.13 or later, I would expect the example to run the same as it did in previous version of bevy (0.12) or as it does on other platforms (OSX tested in this case). Once the example is run, the bevy window will not open until most of the async tasks have finished.

Putting printlns in the update system will see they run once or twice and then block until tasks have finished. This behavior is also observed in my non-example project.

Additional information

Attached are videos comparing 3 different versions of bevy. The expected behavior is version 0.12.1

0.12.1 https://github.com/bevyengine/bevy/assets/1187608/6b38f4d3-e9bc-408b-96f0-42057fb8d8a2

0.13.2 https://github.com/bevyengine/bevy/assets/1187608/fb46744a-ecde-4060-8a67-730195acd883

0.14.0 https://github.com/bevyengine/bevy/assets/1187608/cece0171-44c4-435a-a4b2-44e98537504a

[alice-i-cecile]

Very odd that this is Linux specific. Definitely bad though!

[jasonpeinko]

Ya, strange no one else has encountered the issue either. I would think it was specific to my system if it weren't for previous versions working. Bring the 0.12.1 bevy_task crate back into the 0.13.1 branch, didn't change anything so it may be unrelated to bevy_tasks itself. I will try doing a bisect to find the commit that broke.

[alice-i-cecile]

Awesome. My expectation is that this is something weird going on in one of the upstream dependencies.

[jasonpeinko]

I was able to track it down to the "Async pipeline compilation" commit.

9f7e61b

[alice-i-cecile]

FYI @JMS55 @mockersf

[alice-i-cecile]

Would be good to fix, but not quite milestone-worthy at this late stage.

[mockersf]

shaders are compiled on the AsyncComputeTaskPool, so adding the tasks from this example means they are executed before the shaders are compiled

I think the fix is just to not create the tasks in a startup system, which is not really a realistic scenario anyway

[jasonpeinko]

In my personal project I was starting tasks during an update system and still running into issues. I can see if I can tweak the example to reproduce not using a startup system.

[jasonpeinko]

Confirmed what @mockersf mentioned. However not using a startup system is not good enough. Spawning tasks within the first few frames causes the same delay in window opening. Using a timer to wait 0.1s causes no issues. Is there a ready state or something more reliable than just having a small delay before tasks can be spawned?

[mintlu8]

Are we actually sure running blocking tasks on an async task pool is an ok thing to do?

[mockersf]

it's an async task pool just because we decided to call it that way...
from the built in task pools in Bevy:
IoTaskPool: tasks that uses IO like files, makes sense to group them together
ComputeTaskPool: general tasks that need to finish the same frame they were triggered
AsyncComputeTaskPool: general tasks that can finish in several frames

but that separation is more or less artificial and only maintained by the developer. and the default thread repartition per task pool probably doesn't make sense for any specific game. and it should be dynamic anyway, doesn't make sense to block threads all the time for asset loading when that probably only happens during startup or level loading.

There are ideas to remove that distinction, like #12090, which would probably fix this issue by having more threads available for shaders and async tasks at start

[mockersf]

Is there a ready state or something more reliable than just having a small delay before tasks can be spawned?

Maybe try with https://github.com/rparrett/bevy_pipelines_ready

[mintlu8]

There are ideas to remove that distinction, like #12090, which would probably fix this issue by having more threads available for shaders and async tasks at start

Maybe an easy fix is expose unblock from blocking.

[hymm]

Maybe an easy fix is expose unblock from blocking.

That's basically this PR, but it needs more work before merging. #12090