HDRP performance (Gfx.WaitForPresentOnGfxThread, again)

Unity Engine
, , ,
1

Hello,

I’m experiencing a really bad performance with HDRP, since forever.
Now I really need to get this working.

I managed to optimize my meshes and materials (all Substances, HDRP/Lit), the scene renders with just 22 passes.
Using the SRPBatcherProfiler, my scene renders in ~8 ms, but the main loop takes ~51ms / 19 FPS. (first attached image)
Stripping everything from the scene, what remaisn is just Physical Sky and Fog, render takes ~0.12ms and the main loop ~26ms / 38 FPS. (second attached image)
There’s nothing else happening on the CPU, just a rotating cube (I’ve seen a few reports that the CPU needs some distraction, so just in case…)
A few lucky frames takes 7.8ms. That should be the normal!
Some takes 100ms! (without the usual Editor spikes)
This is completely nuts and unnaceptable.

Profiling, it’s clear that Gfx.WaitForPresentOnGfxThread is what’s causing it to take so long. I’ve seen many many threads about this, this thread just wait for the GPU do so something but no one can tell WHAT it is waiting for. The current profiler, which is awesome, also shows all the render thread and jobs, and we can confirm that it takes around the same time by the SRP BatcherProfiler. So what the hell, the GPU job is done!
There’s nothing else running in parallel, no Chrome, no Video player, no external display, and VSync is disabled on Quality setting.

Sometimes the render jobs leaks to the next frame, that would be a good excuse for the Gfx.Wait thread, but it does not unlock when it ends.

When the Gfx.Wait thread ends, there’s some tiny jobon the Render thread, is that what it was waiting for? Zooming in, it’s AsyncUploadManager.AsyncResourceUpload. What is that? (third attached image)
Whatever the Gfx.Wait thread is waiting, we should be able to see on the profiler!

For my surprise, I was unable to activate the GPU profiler, because IT DOES NOT WORK ON METAL.
Seriously? Metal is the default on macOS for what, 3 years now?

A Release build performs slightly better. Since there’s no EditorLoop, I bet Gfx.Wait is still there.
Sending the build to a friend with a top Mac Pro, it never gets over 40FPS.
Inside a 1920x1080 window!

iMac (Retina 4K, 21.5-inch, 2017) 32GB RAM
macOS 10.15.6
Unity 2020.1.8f1
HDRP 8.2.0

6443474--721232--Screen Shot 2020-10-20 at 00.54.35.jpg
6443474--721232--Screen Shot 2020-10-20 at 00.54.35.jpg3940×2022 937 KB
6443474--721235--Screen Shot 2020-10-20 at 00.55.32.png
6443474--721235--Screen Shot 2020-10-20 at 00.55.32.png3934×2014 1.16 MB
6443474--721238--Screen Shot 2020-10-21 at 23.22.25.png
6443474--721238--Screen Shot 2020-10-21 at 23.22.25.png876×426 21.6 KB

2

I’m not sure how you can tell given that, as you yourself noted

So non of this is giving you any indication of GPU activity. Yes Rendering on the CPU is done but that is just the work needed to issue commands to the GPU.

And yes, we are aware that the GPU profiler doesn’t work in quite a few settings, Metal included. Work to mitigate that is underway. Unity’s multi platform support and the fractured hardware environment with varying support for GPU software time queries across all sorts of GPUs and APIs is slowing this effort down somewhat though.

In the meantime, could you maybe try to use Intel GPA (in case your i5’s integrated GPU decided to do process the editor work, which I guess would be a very good reason for these times, here’s how to check) or AMD’s Radeon Profiler if your dedicated GPU is working on this?

Not entirely sure, someone with more insight into HDRP might be able to give you more specifics. Though since this triggers just after the wait, I would assume that it is just something that gets triggered after the frame is done. It could be a RenderTexture that needs to get shown to the screen once it got the final result?

Agreed, and on some Graphic APIs you’d be seeing a Gfx.Present sample on that Render thread where the big gap is here. Not that that tells you a whole lot more. To be able to show you more, we’d need GPU timings and integrate them into Timeline.

Is vSync also disabled in the Game View? Are other views still open, e.g. Inspectors with Material or other Preview views? Are you using the Profiler in the default way or is this the Window > Analysis > Profiler (Standalone Process) version? judging by the regular spikes in Others, I assume it isn’t so you might want to switch to using the Standalone Profiler for Playmode and Editor Profiling.

Have you tried profiling a Development build to check?

3

Hi Martin,

VSync is disable on the Game View, and it’s the only visible view.
(no scene view, I know it kills culling)

So the Render Thread has nothing to do with GPU work? It’s just preparing the render?
The SRPBatcherProfiler is very misleading then, it should also display how long the actual render takes.

This machine has only the AMD processor.
The AMD Proifiler is not available for macOS.
Any other way to profile GPU on mac?

Yes, and had similar results as in the Editor.

The fact is that an empty scene can’t get to 60FPS, mysteriously trapped into a phantom thread.
How we’re supposed to add a game into this?

Something must be really off here, so I created a bug report
https://fogbugz.unity3d.com/default.asp?1286855_rvflsafhb9r5dlaa

4

Whoops, sorry, I was going by specs I found on google given the iMac specifics you mentioned and didn’t double-check the AMD profiler for a Mac compatible version. Maybe XCode Instruments can help?