search

baldurk / renderdoc

RenderDoc is a stand-alone graphics debugging tool.
https://renderdoc.org
MIT License
9.03k stars 1.35k forks source link

Add graphing/visualisation tools for performance counters #967

Open JensRestemeier opened 6 years ago

JensRestemeier commented 6 years ago

Description

Would it be possible to draw performance counters in the timeline? (And maybe position events by GPU or CPU timestamp?) At the moment I'm exporting the performance counters into CSV and graph them in OpenDoc.

Unless an option like that already exists and I'm just missing it, of course.

Environment

baldurk commented 6 years ago

I don't want to overload the timeline view, as it has a particular purpose and shouldn't be muddied with other things - for the same reason that the counters aren't displayed as extra columns in the event browser. But the general principle of having a way to natively graph and visualise data from performance counters is an entirely reasonable request and follows naturally from what's available at the moment.

This isn't something I'm going to look at for the foreseeable future though. RenderDoc is not a profiler and isn't advertised as one, so features like this are not a priority. There's enough work involved in making a good debugger, and I don't want to split my focus between two tools and half-ass both efforts.

pixelmager commented 6 years ago

While I appreciate and respect not turning Renderdoc into a profiler, allowing the TIMEline to show TIME (see what I did there? :D ) - seems a natural extension. It is also one available in most other debuggers/profilers - and currently pressing the EID-header on the timeline with no result is somewhat confusing :)

baldurk commented 6 years ago

I think though that other tools with a display like that are all profilers - since it is a profiling based view. As you mention I'm deliberately fairly strict in scoping RenderDoc as a debugger and not a profiler, and I don't want to get into a mess with adding half-finished features and features that aren't really the best solution to a problem. I could be wrong, but I don't see any reason while debugging to want to scale the timeline bar by duration, which leans towards the idea that such a feature is out of scope even if I agreed that this was the right place to put it.

But fundamentally I think that the panels should not be overloaded in their purpose. The timeline bar and the event browser both provide different ways of navigating and visualising the structure of the frame, not the performance of its contents. The timeline bar is provided because it can be useful to visualise how the frame is structured in different ways, as well as viewing e.g. the resource usage that is graphed there.

By comparison viewing the frame scaled by frame-time is more appropriate for a profiling/performance oriented view which can be dedicated and tailored to that workflow, rather than a panel being a mediocre middleground that's not one thing and not another.

JensRestemeier commented 6 years ago

While someone could argue that the line between debugging and profiling can be a bit fuzzy when it comes to graphics programming I appreciate the focus on pure debugging. I'm currently trying the vendor provided profilers for NVidia and AMD, and both seem to trigger spectacular crashes, so I can understand if someone doesn't want to deal with profiling.

herb-amd commented 6 years ago

Hi Jens, Can you give us more information on the platform, AMD GPU, and repro steps to address the issue you're having? Thanks, Herb

JensRestemeier commented 6 years ago

Hi Herb, As this is off-topic for RenderDoc I'll send it to your address at AMD.

Cheers, Jens

alecazam commented 3 years ago

There's already a precedent for drawing GPU timings proportionally to their render time in the Oculus version of RenderDoc. When I use NVPerfHud, PIX, NSight, GPA, and Metal GPU Capture seeing draw calls proportional to time is a fundamental service. This doesn't have to turn RenderDoc into a profiler, and it already presents timings in the event capture. Typically once I have a capture, I seek out sections that are slow, and then need the debugger and repeatability of a frame to optimize them. RenderDoc also has the repeatability of captured commands and could display platform/console-specific counters that can't be generated easily during large capture. Seeing draw calls all equally weighted in the timeline, conveys more importance to the number of draws instead of the time taken to process the calls.