Qt Sync Performance Issue on Integrity

Customer submitted comparison between Integrity (Nvidia DriveCX/Tegra) and Windows of the same app (Qt3D Qml application).

As a summary our current understanding is that customer has code:

               [+] mRenderer.render(): 23938 us (73.7%), unreg: 0.2%

                              [+] makeOffscreenCurrent(): 223 us (0.7%)

                              [+] mRenderControl->polishItems(): 13 us (0%)

                              [+] mRenderControl->sync(): 16268 us (50.1%)

                              [+] mRenderControl->render(): 5540 us (17%)

                              [+] mWindow.resetOpenGLState(): 792 us (2.4%)

                              [+] mGlContext.swapBuffers(&mWindow): 904 us (2.8%)

                              [+] emit frameReady(): 20 us (0.1%)

                              [+] mGlContext.doneCurrent(): 125 us (0.4%)

Where sync() function is taking too much time on Integrity.  So far we don't have simple Qt example to reproduce this problem. We are working on it with the customer. But we would like to get initial ideas and suggestions.

3 documents with measurements from customer are attached.

Here is their description:

• target_frame_30_FPS shows you the call hierarchy for rendering one frame on the target
  • It takes 32.5 milliseconds to render the frame.
  • You can see that our rendering takes almost 74% (line 35) of the overall time for rendering the frame (all measured times are physical time, not CPU time!)
  • Of these 74% 50% are spent in sync() (line 38), another 17% are spent in render() (line 39). There are only Qt calls in these functions.
• windows_frame_376_FPS shows the same measurements under Windows (the scene is different). If you compare the results:
  • It takes 2.5 milliseconds to render.
  • Rendering takes 90% of the now much shorter time (this is not an issue since we don’t sleep anymore to get to only 60 FPS).
  • The render() call to Qt takes 44% of that but sync() only takes 0.6%, even though the time spent for rendering this frame is not even 1/10 of the time on the target.
• Both measurements are only done for single frames. However, the impression that sync takes much too long is confirmed. In functionCalls we aggregated the results of these measurements for 1214 frames. Since we measured the physical time I advise you to focus on minimum and average times, since maximum times are most likely edge cases including expensive tasks like memory allocation.
  • You can see that on average sync() takes 25% of the 65% used by our rendering. Qt’s render() takes another 25%. The high standard deviation for both indicates that in some cases significantly higher percentages are expected.
  • We also split the results up into 10-FPS-blocks. I suggest to ignore the blocks up to the 30-40 FPS range (line 224) since there are so few measurements in the blocks below that that they are most likely edge cases. Here you can see again, that sync() is responsible for much of the time spent during rendering in the critical 30-40 and 40-50 FPS range. So the high average percentage of sync() is not just from correctly rendered 60 FPS frames where it happens to take longer relative to the other function calls. Instead it contributes significantly to the long frame times.
  • You can also check sync()’s minimum percentage: The lowest value is 2.6%, which is from one of two frames below 10 FPS, most likely an edge case. In every other block the minimum is around 10%, nowhere near the 0.6% of Windows.

Having said this, we have measurements where Qt performed significantly worse, contributing to up to 90% of the time spent in rendering with sync() and render() combined.