ProfilingSample usage in custom SRP

I am writing a custom render pipeline and have been struggling with the frame debugger. I am using ProfilingSamples to organize the frame debugger output but I constantly get issues and am wondering if there are certain rules that must be followed in order to get consistent results.

I don't feel like I am doing anything too complex: I have a simple deferred pipeline and ideally want a top-most samples for each camera, with samples inside for clears, culling, deferred passes, etc.

In practice, I have a few "unknown scope" headers, multiple nested "Main Camera (0)" (camera name and index), unnamed/unparented subpassesand, incorrectly (I think) ordered instructions, and, at worst, an infinitely recursed dropdown of just the main camera.

What is most confusing is that sometimes it works and sometimes it doesn't. For example, none of my ProfilingSamples seem to take on the name passed to it except for my lighting pass, which seems to work and update just fine even though the process for creating the sample is the same.

I can see that the exact approach I am using is used in the LWRP and HDRP but can't discern what I am doing differently. Has anyone had any success with creating legible samples in their custom render pipelines? I have seen online some people mentioning some calls break the profiler (like clearing surfaces). Are there more of those and are they documented anywhere?

 

I was bewildered by the same thing too, but after reading both ProfilingSample and CommandBufferPool, I realized a few key things:

- First, your command buffer name must match your BeginSample/EndSample name, otherwise Unity will throw errors about BeginSample/EndSample must match.

- Second, if you want to nest 2-level of BeginSample/EndSamples, as in:

BeginA
BeginB/EndB
BeginC/EndC
EndA

What you need is 2 command buffer, in short, Unity won't allow you to nest BeginSample/EndSample in a single CB.

- Third, always ExecuteCommandBuffer() and Clear() after BeginSample as well as EndSample, doing this is redundant in some cases (in some cases you can reuse CB), but it's always safe to just run them.

====

If you do ALL these right, then you should see something like this, which is closer to what LWRP does.

 

This is incredibly helpful, thank you for investigating!

I'll try these out when I get some time to go back to by SRP project and update the thread!

 

Thanks for your key things!
But there's still one thing that I'm wondering:
Some set the first parameter (which is class CommandBuffer) of new ProfilingScope() as null,
e.g.
NativeRenderPass.cs and ForwardLights.cs

Code (CSharp):

1. using (new ProfilingScope(null, Profiling.setupFrameData))
2. {
3. // do something
4. }

Code (CSharp):

1. using (new ProfilingScope(null, m_ProfilingSampler))
2. {
3. // do something
4. }

What is this usage aimed for? When should I use ProfilingScope like this?

 

Add that, command buffer name MUST NOT match your ProfilingSampler name, or the Profiler Window report errors. URP C# code also remind this :

Code (CSharp):

1.             // Caution: Name of sampler MUST not match name provide to cmd.BeginSample(), otherwise
2.             // we get a mismatch of marker when enabling the profiler.