This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Frame rate in Streamline

Hi guys

I'm getting some frame rate values (in a Samsung S10e - G970F) I can't really explain in Streamline, so I was wondering if you could clarify this. The Frame Rate counter seems to be based on EGLContext, so my assumption is that it's simply measuring EGLSwalBuffers times (please clarify/correct me). However, I'd expect this to be locked to the HW v-sync to I'm surprised to see some values going "all the way up" to 63 FPS. Would you be able to elaborate a bit on this?

A second question also related with frame rate (in general) but on an A202F. I noticed that when I start capture the frame rate I get logged on screen (by our internal logger) drops "considerably" during the capture (around 10-15% in high 50s). Having said this, it is consistent during capture (our logger vs Streamline's). Is this related with how "heavy" the interceptor library is? If so, any tips on how to reduce this? I tried the following Capture and Analysis options:

  • Reducing the number of counters to roughly a dozen (the default I get for the A20)
  • All sampling rate modes (down to none)
  • Buffer modes
  • Disabled call stack unwinding and Process Extra Debug information disabled (probably not relevant though)

Any help would be great,

Cheers

  • Hi JPJ, 

    I'd expect this to be locked to the HW v-sync to I'm surprised to see some values going "all the way up" to 63 FPS. Would you be able to elaborate a bit on this?  

    You are correct with your supposition that we are simply measuring swap timing. The GPU part of the swap chain is really decoupled from the display controller, so it's possible to get frame swap timings that are above 60 and below 60, even if the display controller still displays "on average" at 60 during that period. If you're seeing prolonged periods above 60 that sounds like we might be getting some error creeping in somewhere.  

    Is this related with how "heavy" the interceptor library is?  

    We have two interceptor libraries (both with the same name, just to be confusing). 

    If you want to use Graphics Analyzer to actually capture and debug frame rendering you need to use the full GA interceptor. This version of the library does a lot of state tracking to allow frame debug "later" so it has a high probe cost - 10-15% sounds like what I would expect. The path for this one is:

    • <install>\graphics_analyzer\target\android\arm\unrooted\...

    If you just want the software counters, with sufficient light weight tracing for Performance Advisor you can use the light weight interceptor. This doesn't support frame capture in Graphics Analyzer, but it has much lower probe cost for use in performance monitoring (~1%). The path for this one is:

    • <install>\performance_advisor\lwi\target\android\arm\unrooted\...

    HTH, 
    Pete