I have tried this in 5.5.1 on two separate machines. One with Ubuntu 24.04 with nvidia-driver-565, and the other is a fresh Linux Mint install with nvidia-drivers-550.
Doing basically anything in the editor causes the main editor window to freeze, sometimes for minutes on end. The editor never crashes, but it’s infuriating trying to get work done when I have to stop and wait for the editor to catch up. I can feel the editor hit some massive stutters/hitches as well. Just moving my mouse over certain things can trigger a massive freeze/stutter.
Here’s an example of the stutter while just moving my mouse over stuff:
Here’s the entire editor freezing when I just try to select a new material being applied to a spline mesh that isn’t loaded:
The editor froze for about ~30 seconds.
I’m honestly not sure if it’s my computer, OS, project, or UE5.5.1, but I tried two different machines with different OSs and nvidia-driver versions, so that leads me to believe it’s my project config or the editor. The editor is the only thing that freezes, other applications and my desktop seem unaffected by it.
My computer specs:
Ryzen 9 7950X
64GB RAM
Nvidia RTX 4080 Super
SSD (OS, UE5.5.1, and my project are on the same SSD)
Any ideas? I can provide more information or files upon request.
Do you have a specific command you know of that I should run? There are a lot of commands show in the link you sent.
I have looked at “stat GPU” and “stat unitgraph”. I don’t think those are really relevant here though because the counters don’t really change when I make the editor stutter by hovering over stuff. Additionally, I can click play or package my game, and the game runs perfectly smooth.
118 ms is slow, sure, but it’s not a “30 second lag.”
You need to “catch it in the act” while running the tracing to figure out what’s taking so long.
You can also run system-level tools like “top” or some of the fancier versions (like “atop”), or a sampling system-level profiler like oprofile or its newer cousins. Start profiling, make the glitch happen, dump profiling information, and see where the time is spent.
It’s totally possible the time is spent in some dumb area like a device driver waiting for some temperature sensor or whatever, not at all related to Unreal Engine. The only way of knowing is to measure!
There are two separate things happening here. Stuttering and freezing. What I demonstrated with the screenshot of the trace and the first GIF in my original post is the stuttering. The second GIF that I attached in my original post demonstrates the freezing issue.
I believe I did catch it in the act during that trace, you can see many large spikes from the stutter whenever I hover over things. And the screenshot I posted is from one of those large stutter frames.
Using unreal insights, is there any way for me to drill down further and figure it out what the threads are waiting on? Because I see waiting for task a lot even some of my other games which isn’t very helpful without knowing what they’re waiting on.
Given that FlushRenderingCommands is in there, it looks like there’s something synchronizing with the GPU – some kind of stall or read-back or barrier.
Given that Linux doesn’t use the D3D12 renderer, there may be something in the Linux renderer (is it Vulkan or GL these days?) that isn’t as optimized, or something in the nvidia driver or linux kernel that makes timing work out poorly.
I think you’re going to have to insert additional instrumentation around the called out areas of Slate and the renderer, to see what’s going on. You can make a stack-based timer object that prints to standard out only when it gets destroyed more than 30 milliseconds after it’s created or something like that; sprinkle it through the call path to see where it is spending the time.
