Why is my GPU not working at 100%?

This is the first time I’ve noticed this because I always work at 30FPS (t.maxFPS 30)… I limit it for various reasons.

The thing is that today I wanted to try without limiting the FPS and I realized that the GPU does not work at 100% if needed.

That is, on a completely empty map I only reached between 100 and 110 FPS.
GPU at 20% and CPU at 7%.

But even more worrying is with a map that is not empty.

Even though the map is tiny and has very few things, the FPS drop is very large.


And I have disabled a lot of things like (shadows, raycasting, fog, lumen)

But the GPU does not work more than 20% - 30% and the CPU only 10%.

I tested the FPS in Counter Strike 2 with default settings and I get a stable 100 FPS all the time.

How can I make the hardware work without limits?
Or maybe the problem is something else?

Thank you so much!!

1 Like

Greetings @Ivan3z

Do you run any sort of software in the background like Afterburner? If so, try turning that off, restarting, and test again. I’ve had this same scenario while using it. If not, I’d go into a more detailed look at your CPU and see if it’s something like 1 or 2 cores working at 100% while the rest are unused. (Depends on which CPU you run as to how many it could be with performance cores vs efficient cores)

2 Likes

Hi @FrostyJas
I don’t use overclocking…
But you’re right. For some strange reason it’s only using one thread.


My CPU is very old… i thing all the cores are efficient…

Do you know how to make it work with more cores?

Thank you so much!!

I found this

They are using a threadripper… so must be a way to make it work


Performance Notes

The spec below represents a typical system used at Epic (a Lenovo P620 Content Creation Workstation, standard version). This provides a reasonable guideline for developing games with Unreal Engine 5:

  • Operating System: Windows 10 22H2
  • Power Supply: 1000W power supply unit
  • RAM: 128GB DDR4-3200
  • Processor: AMD Ryzen Threadripper Pro 3975WX Processor - 128MB Cache, 3.5 GHz base / 4.2 GHz turbo, 32 Cores / 64 Threads, 280w TDP
  • OS Drive 1 TB M.2 NVMe3 x4 PCI-e SSD
  • DATA Drive 4 TB Raid Array - 2 x 2TB NVMe3 x4 PCI-e SSD in Raid 0
  • GPU: Nvidia RTX 3080 - 10GB
  • NIC 1GBPS on-board + Intel X550-T1 10G PCI-e Ethernet adapter
  • TPM Compliant

And this is interesting… not a solution but interesting…


This make thing:

https://www.reddit.com/r/unrealengine/comments/cxj4e5/is_unreal_engine_still_single_threadednot_editor/
Ok maybe you want 32 Cores to compile faster but…
¿Why do you want a RTX 3080 if you only can use the 20% off it?.. it make no sense…
I hope UE5 does not work like UE4


Any help to use a few of threads more is wellcome…
Now i feell i’m using an “Sinclair ZX Spectrum” intead a “Intel Xeon” :frowning:

Thank you so much

Your game logic loop is tanking your performance at 35.95 ms. I’m guessing this is causing the GPU to have to wait for calculations done on the CPU. It would be better record an session of unreal insights that we could have a look at.

You and the user base could drill down into the recorded functions. Better to turn on Stat Named Events in insights to better narrow down functions.

insight

I’m guessing some functions are probably waiting for a slow async operation that could be clogging up the system.

Does the GPU usage drop once you go down from Cinematic quality or is it still stalled by game logic?

Other things to check

  • does the scene use virtual shadow maps? (can be expensive)
  • are you using lumen
  • are you using nanite
1 Like

Hi @3dRaven
Thanks for teaching me this

Yes, there is no change in performance if I switch between the different scalability levels.

Yes, I’m not using any of those things. I disabled them a long time ago. I had a very bad PC, it was impossible to use Unreal with those things enabled.

Can you tell me if I’m doing it right?

-First I click somewhere where the time is greater than 16.7 ms (60fps)
-Then I sort from largest to smallest in the right window.
-Then I click one by one in descending order until something opens in the window below.
-And I look inside the tree until I see something that is familiar to me.

It’s right?

In this case I found a Niagara particle system.
I think they might be responsible for the frame drops.

That particular system has collisions (13.9 ms).

I only care about the ones colored red, right?
Because in the same tree I also see others in green (400 ms). Like this.


They are tasks of the behavior tree. It seems that an AI used this weapon to shoot.

I also have the muzzle of the weapon animated, it seems to also consume some time.


Should I be worried about this? (1.6 ms).
From how many milliseconds should I worry?

Thank you so much @3dRaven

World tick time has been discussed on the forum quite a bit. It’s time penalty seems to have risen quite a bit ever since going from ue 4 to 5.

You can only hope that in 5.5 full release Epic may have tracked down what is causing the increase in needed compute time.

If changing the scalability isn’t changing the GPU processing then you could be CPU bottle-necked.

I would for now focus on this area:

You have many actor components that are ticking (728 counts). Do they need to? It’s eating up nearly 19 ms. Go through your actor component and check if they have tick enabled by default.
If you don’t need the tick the disable it. If it is crucial then look into if the tick interval can be increased to not tick every frame.

Also check if you do need tick if you can optimize the code to perhaps cache some logic to not calculate it every frame, but rely on parts of cached information.

You also have many tasks queued up. I’m guessing they are async nodes maybe? Perhaps look into if you can offload some of the calculations to a separate thread via FRunnable.

If you are using Niagara particles for display purposes then maybe try offloading them to the GPU where possible. You really need to free up some CPU power at the moment.

1 Like

Ok, I deleted it from all my actors components…
I’m using the tick function in a few places only.
I only use it in five components

And three actors who have extremely simple movement.
The code in all cases is a few lines… more or less like this:

void AMill::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);

	if (FlipFlop)
	{
		SetActorLocation
		(
			GetNextLocation(Side2, DeltaTime), 
			true, 
			nullptr, 
			ETeleportType::None
		);
		FlipFlop = !(Distance<=Tolerance);
	}
	else
	{
		SetActorLocation
		(
			GetNextLocation(Side1, DeltaTime), 
			true, 
			nullptr, 
			ETeleportType::None
		);
		FlipFlop = Distance<=Tolerance;
	}	
}

After disabling the tick on the components, some calls were still counted


I think it’s because the weapons also rotate… they have a rotational movement component… I guess it also uses the tick function.

The only way I could get the motion to look continuous and fluid was to calculate the position at every tick… but I’m willing to not use that actor if it compromises performance…

Anyway I’ve been doing some testing… since my level is so small and I have so few things it’s very easy to delete things and see what happens very quickly.

-First I deleted all the moving actors. FPS only improves a very small bit (from 50FPS to 55FPS or so)

Then I deleted the eight AI Pawns and gained more or less 5FPS

Then I deleted other static actors but they had Dynamic material and they also used the Tick() function… I think this was an explosive mix because with them I gained about 10FPS

Finally i deleted the rest, some static meshes with some emissive colors…

In total I managed to recover about 25 or 30 FPS (from 50 to 80 more or less)
But the level is completely empty now…

Even with the level completely empty there are some strange gaps in FPS.
I saw that the clouds were jumping… they were not moving continuously.
Then I did another test.

The empty world also causes FPS drops.
And for some strange reason at the end of the list appears a Niagara system from the explosion of a projectile… but I am totally sure, the world was empty.

Maybe they are delegate. i have a lot of delegates… if the engine handle delegates as threads then it can be… Otherwise, they are not mine, maybe they are editor threads.

Ok, I’ll do it!!

You still seem to be getting quite large spikes in your timeline. Try clicking on the tall parts of the graph and focus in with the F key to see what is causing these stutters.

I would suggest looking at some optimization videos that might push you in the right direction

like:

You can also upload just the utrace file to the cloud somewhere and link it.

Also if you have user widgets that are static and do not animate you can turn their tick from auto to never.

1 Like

Thanks for the tips

I’ve made a ton of changes and still don’t see any improvement in the editor. It always runs between 50 and 80fps

However, in Standalone it goes relatively well. I get 120 fps more o less
Except when I generate particle systems then the fps drops between 80 and 100…

I wish I could do this in the cooked game too.

I will continue to look for things that can be improved.

Thank you @3dRaven

I missed quite a bit of the conversation here, I see. I am glad that you made some progress on the issue in terms of finding the cause. I’ll keep my eyes peeled for anyone with the same problem and a solution.

1 Like

Thank you very much.

I’ve been optimizing everything I can for several days.
Particle systems. Disabling ticks. Removing timers. Removing polygons from meshes.
All my codes are in C++.
I have not lighting.
I have not textures.
I have not fog.
I have not shadows.
I have not reflections.

Nothing I do gets more performance.

I’m starting to suspect that my behavior tree may be largely to blame.
I have a very complex behavior tree.
But it has to be that way because I want my AIs to be as human as possible.
I’m not going to change it. It took me a lot of time and work to get it that way.

Olso I think running the game in the editor hurts the actual performance of the game a lot (a single thread is not enough).

When I run the game in Standalone it uses six threads and the FPS never drops below 80 (With my GPU which is quite basic for today → GTX 1080Ti). I guess with better GPUs you can get more FPS.

Thank you very much.
Best regards!!

I had a similar issue in a game I was playing a couple of years back where my CPU was only using 1 core for it. I’m not sure if it was something with the game or my CPU itself. I ended up going into the BIOS and disabling c-states and it started using the other cores. I’m not sure if that would help your situation with UE. But, it might be worth looking into.

1 Like

I’ll look into it
Thank you very much for the idea :heart:

You’re welcome! I hope it’s helpful.

1 Like

Hi @3dRaven

Do you know some way to get “Recast Path Finding” not to be so heavy?

I calling this function in my behavior tree

const UNavigationPath* NavigationPath = UNavigationSystemV1::FindPathToLocationSynchronously(World, MinTeleportPointOut->GetActorLocation(), Destiny);

Increasing the tick interval does not help because when it runs, it runs with all its FPS destroying power anyway.

And I don’t see the way to program this any other way.
I simply need to calculate the shortest path through a (or several) teleportation cabin. :upside_down_face:

Thank you so much!!

Try in NavigationSystem.h

NAVIGATIONSYSTEM_API uint32 FindPathAsync(const FNavAgentProperties& AgentProperties, FPathFindingQuery Query, const FNavPathQueryDelegate& ResultDelegate, EPathFindingMode::Type Mode = EPathFindingMode::Regular);

Here is a thread that mentions some extra steps for it.

I’m sure there are also tutorials that mention it.

Other option is to write your own function with FRunnable and implement A* on the vertices of the nav mesh (would need extra work to add modifiers though).

1 Like

Thank you so much @3dRaven :heart:

Hi @3dRaven
I have realized a very curious thing.
My weapons rotate on the Z axis (10 weapons).
When the player looks at them they rotate, but when he doesn’t look at them they don’t rotate.
I guess the engine does this to save resources.
But when the player looks at them the FPS also drops.
In the editor it is very noticeable.
10 FPS drop in total (one FPS for each weapon). Just for rotating!!
In Standalone it is not so noticeable… in fact in standalone the FPS stay between 150-100FPS almost all the time.
I don’t really see the rotating component of movement taking up too much CPU time. (40 microseconds each weapon). But I’m sure the weapons are causing the FPS drop.

What do you think about this?

Do you think it would be a good idea to remove the Rotating Movement component and rotate the weapon using a thread?

Or maybe just remove the movement component?

Or maybe the problem could be something else?

Thank you so much!!

One way you could optimize the rotating motion would be to use VAT (vertex animation texture). I’m guessing this is a spinning motion for a pickup of the weapon?

1 Like