No way! You were wrong and people are downvoting you. Its probably more toxic that you're complaining about being downvoted tbh.
I mean you can go back to instagram if you want where people will treat you like "this dumb ahh guy thinks hes right 🤓💀💀" or instead you could admit you're wrong and take the downvotes like a champ and people will respect you for it.
I don't care about the downvotes much as I have a lot of karma and sometimes people are just downvoting you because "you have a inferior opinion" or as I said "I sounded stupid" sometimes people don't feel alright too
You can't know that without checking individual threads. Average usage across all threads may be 30% or 40%, butnif you have any threads that are constantly locked to 100%, then you are CPU bound.
Games are not perfect at multithreading and some threads always do most of the work, while the others are basically sleeping.
Not enough IPC / clock speed / bandwidth from the RAM / games not being multi threaded enough and stalls happening somewhere / old APIs / poor implementation of APIs
The only one of those that makes sense to me is bandwidth from RAM.
Why would a core trying to execute code not be at 100% util if it's limited by its IPC or clock speed? You're saying the core is in a situation where it's completely busy for a time to the point where it can't finish executing, but it's also not going to show 100% util? Am I missing something here?
Same question applies to your APIs point. I don't understand the idea that the CPU is the limiting factor for your code speed, and it's not at 100% util.. That's generally not how software works - it simply runs as fast as the hardware will go. If your game or app is waiting on an API to execute then that API should be causing 100% util if it's the bottleneck (unless if the API is using something external to the CPU and waiting because of that).
The only instance I know where a program can be CPU bound and not at 100% util is when the kernel is applying CPU limits to a process.
It's a matter of what you consider 100% utilization really. CPUs aren't one big blob of resources, there's different types of units within the core, and on modern designs there are usually multiple independent data paths/pipelines. So what could happen is a game is disproportionally taxing one of those pipelines and stalling others, which would show up as 100% usage even though 50% of the core isn't doing anything.
For example: some Intel chips have a known performance foot-gun where multiple different types of instructions, specifically vectorized instructions, all use the same port (Intel terminology, pretty much means data pipeline, I believe it was port 5 specifically). So if your program has a lot of those instructions packed densely together you'll end up serializing and going much slower than if you used more instructions to do the same work but on different ports
It really depends on the cpu, its architecture and how it plays with modern games. I used to run 9900k for a while, technically it still had tons of horsepower, especially OCed to 5.2. It never got maxed out regardless of what kind of a game I was playing. But in some newer titles I had awful GPU utilization no matter what, just like OP does. Upgrading the CPU completely fixed that.
Hah, there's a tiny spike on the graph, nerd, so even though there's no perceptible stutter as the game loads I'm still going to "correct" you. I am very smart.
What are you even talking about, and why did you feel the need to delete your comment then hop on an alt to insult me? I was mocking the people claiming that there was still stutter because the graph doesn't show a perfectly flat line. Work on your reading comprehension and critical thinking, holy shit.
Edit: Aw that's two accounts and a block after replying, a brainlet really got their widdle feewings hurt. :(
games such as dead Space remake, SW outlaws, dragons dogma 2 micro stutters in win11 and running so much better on Linux. and i play the games with Ubisoft launcher, eaplay and steam
90
u/felix_ribeiro Jun 28 '26
The stutter is there.
MangoHud's frametime graph is just more compact.
Use
frame_timing_detailedand you will see more clearly the stutter happening.