making a thread to avoid spam...

[steady stump]

@drowsy brook

here is an engine frame zoomed in a bit

If you have bad internet and these take a while to appear let me know, I can try to make them smaller

[drowsy brook]

gonna read docs before I proceed, not fammiliar with any of the graph.

[steady stump]

here is the tl:dr

the most confusing part about this is that it actually shows the GPU and CPU at the same time

each row here is a different "thread" which have a particular order

The first two are GPU split between compute and graphics (I have no clue when that matters)

I am not great at graphics stuff... I am more familiar with CPU stuff

The next three in this picture are

• The game thread (where 99% of our code tends to live)

• The RHI thread (here it is pushing commands to the GPU)

• The render thread (which takes work from the game thread to send to the the RDG at the end of the frame)

The rest of the rows are mostly task workers that will do task work like animation tasks, parallelfors, and any other UE::Task things. The audio thread is chilling near the bottom too but I have not ever had to look at that so far lol

Most of the time we are going to be looking at the game thread and if it's waiting for work, someone else is being slow

[drowsy brook]

could the GPU ever cost bottle neck for the CPU or nah?

[steady stump]

if the GPU took too long to do the requested work, yes it could be the bottleneck

GPU profiling is a bit advanced and tends to be more confusing than CPU profiling. It's a bit harder for them to narrow down when things happened as it's kind of a second computer you ask to smash numbers together very fast...

stat unit can give you a rough overview on who is the problem I guess

the thing to pay attention to is mainly "who is the largest" of the game, draw/rhi and gpu

this is clear to see in insights but it might help quickly see the numbers here too

since the game thread reported it took the most time to make the frame we can assume it is probably the reason the frame is slow. Of course we use an actual profiler to see wtf is happening

For demonstration purposes I am going to crank the render resolution to 800% to make my shitty game scene cook my gpu

Notice something different? the game thread is waiting for someone else!!

my project has some custom engine changes to add better naming for the game thread tick but you should see something fairly similar

For starters I would recommend enabling stat named events so you can see the names of objects that are making events in some cases

With this setting on you can see my player controller tick here with the name of the BP

As for how to actually reason about this information that is tough... Generally speaking you are going to be fighting to just not waste time doing stuff that isn't important more than trying to make stuff faster with "optimization" especially when working with code you can't really control completely

Also keep in mind

• tracing will incur a small overhead and make things look slightly worse than they really are. Also debug builds of course will be slower than more optimizied code!

• on the other hand our gamedev pcs are generally super OP and will make things look better than they really are on target hardware (on a ps4 this profile would be much worse)

Also @drowsy brook I should mention as one last thing before I forget: As you can see here this is insanely powerful to see WHAT happens in the frame and when even if you don't care about the performance

I would have not been able to figure out how any of the engine systems work without a magic button that shows what happens in order

Not everything is traced in here but generally speaking you should be able to see what happens before it

⁨```cc
TRACE_CPUPROFILER_EVENT_SCOPE(My omega sick tracing event)

oh yeah, you can add your own cpu events like this. I would say try not to use these inside of hot loops as making thousands of them might be costly but I have these everywhere in any code that I need to track