Question When does URP consume cpu?

when I look at a bunch of 3D objects the cpu usage jumps up
why is that?

I thought that list building happens during culling phase which happens even when you're turning your back to them

has that cpu usage dropped in versions of URP after 8.3?

 

Draw calls and preparing the data for those draw calls. Culling attempts to eliminate them, and is the first step, but the things that aren't culled actually need to be processed and drawn.

 

ok so URP makes a list of stuff that's to be drawn during the culling phase
assuming objects were drawn in the frame before all the geometry and texture are already on the gpu so what next?
specifics

 

That's not really how graphics APIs work. The textures and geometry are there, sure. Perhaps some of the material property blocks + transformation matrices (constant buffers) are sitting somewhere and don't need updated. But you still need to issue draw calls every frame to tell it what to draw. The APIs (DirectX/Vulkan/OpenGL/Metal) have to validate parameters and issue commands to the graphics drivers. Then the graphics drivers need to process these commands on the CPU before writing them out to the graphics bus.

 

so the display list with the matrix transform is what URP sends to the driver who then uploads to the gpu. doesn't seem like to much data for a couple thousands of objects. i mean per frame i can do 10k distance calculations with burst and it's taking up 0.4ms on a switch so which part actually sucks cpu juice in that display list stuff, on URP?

 

You can use RenderDoc or the Frame Debugger to see exactly what happens each frame in your game.

It's not the sending of the data to the GPU that's slow unless you have pipeline stalls or are sending meshes/textures to the GPU every frame. It's the draw calls. Unity needs to prepare/transform the data into a format the API understands, then the API and drivers need to prepare/transform that data into a format the graphics card understands.

That's why batching (dynamic, static, and SRP's shader-based) and instancing are so important. Batching and instancing don't reduce the amount the GPU does (they might increase it), but rather reduce the number of per-frame draw calls on the CPU.

 

Skins are computed on the gpu and most of the creatures use mesh snapshot which I believe are cached on VRAM plus the unified memory of the tegra doesn't show much cost to uploading (I think it's just changing pointers)and from looking at the bandwidth graph it doesn't go up when the cpu tanks, also not fillrate bound as it's auto scaling down within specs. so this seems related to that phase of unity+driver preparing data.

Do you know how much data gets transformed/prepared per draw call? Is there a constant cpu cost? Is it per transforms? If that's the case then each bone has a cost = to an object. My google-fu is rusty, if you have a link where I can read more on that particular aspect of the graphics pipeline I'll gladly spend a few hours on it.

In the mean time I fired up the frame debugger. 800 draw calls.
I dug deeper and see that, when the camera sees the bulk of the scene, main thread:

1. physics ms nearly doubles
2. render ms increases just a little

(wish there was an option to color code hierarchy overview to match graph)
I like how the gfx job system dispatches to a new worker only if it's really busy, it does a great job.

so in summary this doesn't look like a graphics problem and is a good thing because i spent a lot of effort optimizing this stuff. anyway it's always nice to know more.

looking away

looking at

 

The first part of this series talks a bit about it: https://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/ Obviously on Switch there are some differences (and graphics APIs have come a long way since 2011 -- in particular, Vulkan, Metal, and DX12 were designed to fix some of the inefficiencies of DX11/OGL and bring the APIs closer to the hardware

Really, I would say if you're curious download RenderDoc, it's well integrated with Unity: https://docs.unity3d.com/Manual/RenderDocIntegration.html . You can see the exact set of API calls it makes (at least on PC) and what's happening at each point. Exploring this will help you get a better idea of exactly what your game is doing every frame.

For URP, search for "Universal" in the filter box and you'll find the specific draw calls you care about. You can see for mine that API calls 906-1406 are URP.


Then clear the filter (delete the word and press enter, kinda annoying you have to do this) and you should see the actual API calls:



Click on some of those calls you're interested in. The texture viewer part shows you the result of that call among other things:



Clicking the little clock will make it estimate timing. DO NOT TRUST THESE NUMBERS, but they can give you a ballpark of what's taking a long time:

 

It looks similar to NVN debugger. I'll check it out when I'm done with this.
Thanks.