When capturing with Nsigh Graphics, it shows the FPS at the top left, there’s a fairly large fluctuation of FPS it seems.
Sometimes this is much higher and sometimes much lower - I would like to capture a frame that took a lot longer and one that took a lot shorter to see what’s going on.
Obviously, this is not possible to do by shortcut, is there a way to make nsight capture the first frame that took below or above a certain time to render?
The Nsight Graphics GUI does not have a built-in mechanism to automatically capture frames on a condition.
However, your scenario can be solved via the Nsight Graphics SDK, which is part of the overall Nsight Graphics installation.
Basically, your application would need to take its own timing measurements (e.g. D3D12 Queries, or Vulkan Timestamps), and use those to decide when to call NGFX_Injection_ExecuteActivityCommand().
This approach ought to work in any situation where back-to-back frames are producing a consistent result, since the timings are on past-rendered-frames, by the time the CPU gets to read them. It will not catch the very first frame, since capturing happens after the ExecuteActivityCommand call; it won’t be able to catch one-time blips.
There is a sample program that illustrates the full use of the SDK, in a path like this:
Hope that helps!
Yes, unfortunately, I do think these are one-time blips. Would it be possible through the SDK to “initiate” a capture, then discard it at the end if it didn’t hit a certain time threshold? Or would the capture process falsify the timings at the end?
Is the SDK only available for Windows? I’m on Linux and I cannot find the SDK folder in my installation.
Hello,
Yes, unfortunately the SDK is only available on Windows. Sorry for any confusion.
Regards,
Unfortunately there is no existing mechanism that would fit the flow you described. Some capturing procedures are also more invasive (e.g. C++ Capture must copy gigabytes of memory & textures), which would falsify the timings.
If you are willing to share some more info with us via NsightGraphics@nvidia.com, I’d be happy to add this to our feature database. Helpful info would include the application you’re developing and the types of performance loss scenarios you’re encountering.
Thanks and Best Regards.
Sure, here are some details, let me know if you want me to send a summary to the email. My primary concern is GPU performance counters, which I think should be “lighter” and not falsify the timings as much.
I have some vkCmdDrawIndexed calls that are taking long to complete (~0.4ms each), I’m assuming due to fill rate, as they are simple quads or 2D polygons with few triangles, but covering a large portion of the screen and using high-resolution (non-mipmapped) textures (2k or 4k).
But then sometimes the FPS counter from Nsight tells me I’m hitting 1000 FPS, and those 2 things seem like they can’t both be true: .4 * 5 = 2ms, so at most I should hit 500 FPS, and that’s without counting CPU time, which is about 50% of the frame.
I rebuild my command buffers every frame, so I’d expect timings to be similar for each frame given the same geometry, textures, etc. but they vary wildly from highs of 1000 to lows of 130, so I’m trying to understand what’s going on.
