Very Poor Framepacing and Performance When using Xorg Rotation

The use of xrandr rotation or manually specified metamodes causes a significant performance penalty for fullscreen and non fullscreen applications as well as reduces the framepacing consistentcy (which appears as stutter in scrolling text or gameplay).

This has been a longstanding issue for both the embedded and nouveau drivers. Why not use the gpu for display transformations instead of using cpu for transformations (clearly indicated by the increased xorg cpu utilization when rotation is used)?

(purposely using 32.3.1 due to performance issues with newer gpu userspace drivers)

2 Likes

[ 13.178] (II) Module nvidia: vendor=“NVIDIA Corporation”
[ 13.198] (II) NVIDIA dlloader X Driver 32.3.1 Release Build (integ_stage_rel) (buildbrain@mobile-u64-2713) Mon Dec 9 22:49:30 PST 2019
[ 13.198] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[ 13.198] (WW) Falling back to old probe method for NVIDIA
[ 13.323] (II) NVIDIA(0): Creating default Display subsection in Screen section
[ 13.323] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
[ 13.323] (==) NVIDIA(0): RGB weight 888
[ 13.323] (==) NVIDIA(0): Default visual is TrueColor
[ 13.323] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[ 13.323] () NVIDIA(0): Option “RenderAccel” “true”
[ 13.323] (
) NVIDIA(0): Option “AllowGLXWithComposite” “true”
[ 13.324] () NVIDIA(0): Option “AllowUnofficialGLXProtocol” “true”
[ 13.324] (
) NVIDIA(0): Option “AllowEmptyInitialConfiguration” “true”
[ 13.324] () NVIDIA(0): Enabling RENDER acceleration
[ 13.324] (
) NVIDIA(0): Enabling 2D acceleration
[ 13.641] (II) Module glxserver_nvidia: vendor=“NVIDIA Corporation”
[ 13.641] (II) NVIDIA GLX Module 32.3.1 Release Build (integ_stage_rel) (buildbrain@mobile-u64-2713) Mon Dec 9 22:47:49 PST 2019
[ 13.680] (–) NVIDIA(0): Valid display device(s) on GPU-0 at SoC
[ 13.684] (–) NVIDIA(0): DFP-0
[ 13.684] (–) NVIDIA(0): DFP-1
[ 13.685] (II) NVIDIA(0): NVIDIA GPU NVIDIA Tegra X1 (nvgpu) (GM20B) at SoC (GPU-0)
[ 13.685] (–) NVIDIA(0): Memory: 4079284 kBytes
[ 13.685] (–) NVIDIA(0): VideoBIOS:
[ 13.685] (–) NVIDIA(GPU-0): DFP-0: connected
[ 13.685] (–) NVIDIA(GPU-0): DFP-0: External TMDS
[ 13.685] (–) NVIDIA(GPU-0): DELL ST2220L (DFP-1): connected
[ 13.685] (–) NVIDIA(GPU-0): DELL ST2220L (DFP-1): External TMDS
[ 13.691] (==) NVIDIA(0):
[ 13.691] (==) NVIDIA(0): No modes were requested; the default mode “nvidia-auto-select”
[ 13.691] (==) NVIDIA(0): will be used as the requested mode.
[ 13.691] (==) NVIDIA(0):
[ 13.691] (II) NVIDIA(0): Validated MetaModes:
[ 13.692] (II) NVIDIA(0): “DFP-0:nvidia-auto-select,DFP-1:nvidia-auto-select”
[ 13.692] (II) NVIDIA(0): Virtual screen size determined to be 2640 x 1280
[ 13.692] (WW) NVIDIA(0): DFP-0 does not have an EDID, or its EDID does not contain a
[ 13.692] (WW) NVIDIA(0): maximum image size; cannot compute DPI from DFP-0’s EDID.
[ 13.692] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
[ 13.692] (II) NVIDIA: Reserving 6144.00 MB of virtual memory for indirect memory
[ 13.692] (II) NVIDIA: access.
[ 13.695] (EE) NVIDIA(0): Failed to allocate NVIDIA Error Handler
[ 13.695] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[ 13.695] (II) NVIDIA(0): may not be running or the “AcpidSocketPath” X
[ 13.695] (II) NVIDIA(0): configuration option may not be set correctly. When the
[ 13.695] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
[ 13.695] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
[ 13.695] (II) NVIDIA(0): details, please see the “ConnectToAcpid” and
[ 13.695] (II) NVIDIA(0): “AcpidSocketPath” X configuration options in Appendix B: X
[ 13.695] (II) NVIDIA(0): Config Options in the README.

Are you saying there is application performance issue after xrandr rotation and only happens after >=rel-32.4.2?

no this issue is unrelated to my other bug report Performance Regressions in 32.4.2 and newer GPU driver versions
the poor framepaceing with xrandr rotation happens with all releases I’ve tested

I do not have a great easy example to show you besides a open source FlappyBird game that I’ve partially written. It runs perfectly smooth at 60fps when not rotated but immediately when rotating the screen the pipe scrolling is jittery. This can be observed in other fullscreen applications with scrolling text, moving background, etc.

You are welcome to attempt to compile my code here or run the flappy_install.sh (which installs a precompiled binary) which I assume will work on other jetson nano’s fine

Did you add ForceCompositionPipeline and TrippleBuffer in your xorg.conf?

ForceCompositionPipeline will force composition always, so if it’s a GPU compositor, extra GPU bandwidth is used.

My above log shows a snippet of the settings I had enabled. At the time I did not have either of those settings you mentioned enabled.

forcecompositionpipeline automatically gets enabled when the screen is rotated, the composition pipeline is the problem, not the solution. If set forcecompositionpipeline to true, even an unrotated screen has the framepacing problem (I just tested for you). TrippleBuffer has no affect positively or negatively here.

Is it possible to use some simple GL app or our sample code to show what you’ve seen? I have my difficulty to use your application to reproduce this issue. It is not a problem from your app. But it would be better to use such GL app to reproduce so that our engineers can check it easily.

I have a relatively simple GL app here GitHub - theofficialgman/gl-gsync-demo: Unofficial OpenGL G-SYNC Demo for Linux which normally is used to test vsync and gsync
I made a couple of comments to disable the gsync function.
the moving line will stutter when the screen is rotated and will remain smooth when not rotated.

sudo apt install freeglut3-dev libglew-dev libxnvctrl-dev
git clone https://github.com/theofficialgman/gl-gsync-demo
cd gl-gsync-demo
make
./gl-gsync-demo

you are welcome to have the engineers test this application in the desktop gpu lineup as well in regards to rotation

Hi,

Sorry for one more question here. Will you see such stutter if you run the 00_video_decode from our MMAPI sample?
We are running out of test devices at this moment so I cannot test this for you. If you can wait, then we can check it later.

This issue seems reminds me two old topics. Since the graphic driver is compatible between every jetson platform, what happened to other platforms can leverage to jetson nano too. For example, I checked your flappy code and it is based on SDL. We once had a user asking FPS drop issue with SDL on TX2. Also, we have another topic talking about GLUT3 app will have tearing under dual monitor and rotation case on TX1. And the gl-gsync-demo you are using has GLUT in use too.

Thus, need to clarify what kind of cases will hit this issue while others don’t.

I think it happens with that sample decoder as well but its hard for me to tell because I don’t have a sample video at 60fps with a white bar scrolling to the side. The best I could test that decoder was from this youtube video (Black and White Optical Illusion Tunnel Psychedelic Stripes Lines 4K 60fps Wallpaper Background - YouTube) which I converted to h264 (you can get it from my google drive link here: zooming_bars.h264 - Google Drive) and played using 00_video_decode.

Again though, this comes back to the anything going through the
compositor which can lead to jittery desktop performance and non-smooth scrolling in things like webpages.

Is this issue related to what you see here?

I have been testing my issue on 32.3.1 (jetpack 4.3) and not jetpack 4.5 so I don’t think they are related issues. The compositor/xorg stutter/framepacing issue that I am reporting is apparent on all versions I’ve tested (4.3 up to 4.5.1).

I can confirm that the “graphic flickering on jetpack 4.5” does exist for me on jetpack 4.5.1 on the TX1/nano when rotated as well and is not a problem on 4.3 (what I typically use).

Got it. We will check those.

BTW, sorry for my poor English reading. Does your last comment here mean even the MMAPI sample can see the stutter?

Again though, this comes back to the anything going through the
compositor which can lead to jittery desktop performance and non-smooth scrolling in things like webpages.

what I intended to say by my last comment was that I am not sure if I can see the stutter or not in the MMAPI sample. I do not have a good test video to check for stutter. I think I observe stutter, but I am not certain. Maybe your engineers have a better video to test that would be easier to observe any stutter.

As far as I can tell, anything that uses the xorg compositor should stutter. You can force the compositor to be used by setting forcecompositionpipeline to true or rotating the screen (which forces the composition pipeline on).

just to add to the developers/engineers testing this. it seems that the use of nvidia x server settings and enabling the graphics API visual indicator helps with debugging the issue. You can see that the reported FPS drops (as low as 40fps in my testing) when the xorg compositor stutter is bad (so either when rotated or when the fullcompositionpipeline is enabled) . Vsync has to be enabled otherwise the overlay will report a constant 60 even when there is visual stutter.

Unfortunately the indicator doesn’t seem to show a low framerate on the gl-gsync-demo code but I think the stutter is visually clear on that demo already assuming you can reproduce it.

Hi,

May I know what is your method to enable graphics API visual indicator?

sudo apt install nvidia-settings
open nvidia x server settings → x screen 0 → openGL Settings → turn on Enable Graphics API Visual Indicator
Sometimes the indicator gets hidden behind an application but it always shows on top when the compositionpipeline is enabled (ie: rotated or ForceCompositionPipeline)

Hello,

I tried to reproduce your issue but it is little bit hard to tell whether we really hit the error or not.

With the second sample you are using

It seems the fps “value” on the screen is always 60fps after I enable Graphics API Visual Indicator. And I didn’t see the stutter.

Are you able to use phone to take a video for this sample and share us the error you saw?