[SOLVED] Flush Command Thread

[K.Wagrez]

Hello everyone,

I have been using the Microprofiler to identify bottlenecks in my application by not only using it on my "main" application, but also on another Unigine project with the exact same graphical assets, but without all the external processes/plugins we embark. I wanted to make sure the graphical scene was valid by itself, for I am CPU bound on the rendering part in my main application. Curiously, the exact same graphical configuration is not CPU bound in my other application, which is why I try to investigate any factor that could slow down the CPU render loop.  

While doing that, I stumbled upon a thread, named "Flush command thread", which appears in my main application, but not on my custom blank application. What is it ? Can it disrupt any operation on the main thread ?

Thanks !

PS: for reference I join the screenshot. In the dropdown list for my blank applciation, I don't even have this thread available.

PS2: I don't have complete knowledge of every part of said application, it might be due to something we've done, or a plugin.

Edited June 30, 2025 by K.Wagrez

[bmyagkov]

Hello!

@K.WagrezCould you please share the dump file generated using the microprofile_dump_html command?
After running the command from the console, the resulting file should appear in the \data\microprofile_dump folder within your project directory.

Access to the complete dump might provide us with some additional clarity on this behavior.

Thank you in advance!

[K.Wagrez]

Hello,

Here is a wetransfer with the Microprofile dump and a little readme acting as a reminder for the context : https://we.tl/t-E8D8lsyIT6
It should stay online for 3 days.

 

[bmyagkov]

22 minutes ago, K.Wagrez said:

Hello,

Here is a wetransfer with the Microprofile dump and a little readme acting as a reminder for the context : https://we.tl/t-E8D8lsyIT6
It should stay online for 3 days.

 

Thanks! We've taken a look and will get back to you as soon as any new information becomes available.

 

[bmyagkov]

Hello!

@K.WagrezFrom the Microprofiler dump most of the time is spent in Async Present which suggests V-Sync might be enabled. This could explain the "Flush command thread" — it likely handles command flushing during present and can appear when V-Sync is on. Can you check if V-Sync (render_vsync) is enabled in your main app?

Also, comparing the .render preset files between both projects may help identify any differences. 

If you prefer not to share configuration files publicly, we recommend using our private helpdesk for more in-depth assistance: https://developer.unigine.com/en/support/tickets/add

We’ll be glad to assist you further there!

Thanks!

[K.Wagrez]

vsync seem to be disabled on both app. I checked on the console, and it would have been shown in the show_fps section too, which it isn't :(. I'm not even sure it's bad, I juste wanted to have an idea what was going on.

I'm going to check thoroughly the render settings, seek internally if anyone has any idea and will come back to you as soon as there is news.

[bmyagkov]

Hello,

We’ve found what’s causing the difference you noticed. The Flush Commands thread is specific to DirectX 12 and Vulkan and wasn’t present in DirectX 11 which is probably what your blank projects are using. That said, there’s nothing unusual or problematic about this behavior — everything looks normal from that perspective.

However, based on the microprofile you shared the GPU load appears to be a bit low. Even with VSync turned off (please double-check in case it's accidentally enabled) the render_main_scene thread is still taking a significant amount of CPU time. This is likely the main area to focus on.

The good news is that starting with version 2.20 (planned for release later this month) this thread will support multithreading which should help reduce its impact. Upgrading to that version could be a good options to address this.

Thanks!

[K.Wagrez]

Thank you for the answer, I was worried this thread was something ominous.

I double checked, It is deactivated. You guys also specify Vsynced when enabling show_fps, so I'm pretty sure it was off. I will check my external project, but I suspect you are right on the DX12/DX11.

And yes, I found very suspicious that the CPU render loop is slow, also because here is a snapshot of the project assets on this external project (same viewpoint though, same resolution), with no logic and no plugins, and the CPU render loop takes almost half the time. you can also see the GPU has the same amount of work to do. Of course there must be some discrepancies in the render settings that I will track down at some point, but it's a sign there is something weird going on. It even looks like the same distribution of work load among all the tasks.



I will continue working on investigating all of that, and If I have any issue or further discussion on the subject requiring more sensitive materials, I may use the Developper Support interface to contact you guys :).

Great news for 2.20 ! If I don't find a reason why our CPU render loop is so relatively slow, I could try to push for an update to 2.20. As soon as it releases I might do some testing to see how it improves our existing application.

Edited June 23, 2025 by K.Wagrez