this is a known issue in jetpack 5.X as well. confirmed on an xavier nx devkit running 5.0.1.
this is not jetson specific either… it is an issue with all nvidia gpus running xorg, there have been many reports in the nvidia forums over the years. it is just less and less noticeable the faster the cpu is in the running system.
How this isn’t top priority above all other issues is beyond me. especially since nvidia keeps pushing to keep using xorg even on modern linux distros
I’d also like to point out that the original issue was opened over a year ago… And the public was told a fix was released.
This seems ridiculous–promising a fix, pretending a fix is released, not actually fixing the issue, and then saying you have to buy one of our newer (all sold out or upsold at ungodly prices I might add) boards and trust us that we’re actually going to fix it this time in order for basic functionality to work.
For using Jetpack 4+ Jetson Nano, please not to use this mode.
Seriously? X11 is a fundamental part of using a graphical environment on these devices, especially as Wayland has its own issues on them. “Just don’t rotate the screen with X11” seems like a tall request given prod modules are marketed as having a working Linux OS and clients of yours are actively using these modules in a capacity which requires X11 rotation for the device to be viable for usage.
Either add t210 support to JetPack 5.x or give us a real fix for this issue that was supposed to be fixed ages ago.
also just incase anyone forgot how terrible it is… here is a screenshot comparison
no composition:
What is the recommended course of action for Jetson Nano users to avoid this critical bug that we were told was already fixed?
Hi,
On Jetson Nano, please run in default landscape mode and not enable ForceFullCompositionPipeline.
Hi,
Just want confirm this. Is it possible to use EGL app instead of GLUT or SDL?
all applications, the desktop, and everything rendered to the display is affected. It does not matter if it is GLES, EGL, opengl, vulkan, SDL2 (using opengl), etc. everything passes through your broken composition pipeline and is affected. the developers know this.
the application choice is purely for reference so that you can easily observe the issue. the framepacing issue happens on everything.
Because I was asked elsewhere, this frame time graph is generated with mangohud (which can also do long term logging and frame time visualization). Compiling/install g assumes you have a high enough meson version available (you can install newer meson with pip)
git clone https://github.com/flightlessmango/MangoHud.git
cd MangoHud
meson build --prefix /usr -Dappend_libdir_mangohud=false -Dwith_xnvctrl=disabled
sudo ninja -C build install
Are you able to provide any updates on progress dealing with this issue?
@WayneWWW @kayccc Quoting Nvidia’s official statement:
JetPack 4.6 will be the last major release for Jetson Nano, Jetson Nano 2GB, Jetson TX1, and Jetson TX2 series (Jetson TX2 NX, Jetson TX2, Jetson TX2 4GB and Jetson TX2i). After JetPack 4.6, the JetPack 4 codeline will transition into a sustaining mode with continued software support via JetPack 4.x releases for security updates and critical bug fixes.
The issue described here (and in the original post) has gone unfixed after notification for 1.5 years. It remains an issue in 4.X and 5.X codeline. As agreeded by nvidia devs, this is a critical bug and must be fixed. Your developers may chose to fix this bug or please update all official nvidia wording and notify developers as follows (example modification to the official statement).
After JetPack 4.6, the JetPack 4 codeline will be abandoned with NO software support via JetPack 4.x releases. All developers must update their hardware to receive software support including security updates, bugfixes, and new features.
Your hardware can perform rotation of the display output image easily 1000s of times per second. Remove xorg rotation from your composition pipeline and perform it via VIC as done in your android stack. Full composition is not necesssary for rotation.
Hi,
I understand you are upset about this. Believe it or not… the truth is we indeed fixed this issue for a while , but somehow this got broken again after rel-32.7.1. Sorry that I didn’t re-test that again when rel-32.7.1 released.
And we reopened your issue and checked as your request. Unfortunately, we are not finding the root cause yet.
Actually, it is more likely we will use Orin or NX/AGX to debug on jetpack5 first and if we find the cause, we will see if that could be back port to nano.
Believe it or not… the truth is we indeed fixed this issue for a while
thats right I don’t believe it. I have requested before and will do so again, if you truely “fixed” the issues, you could post a binary release or patchfile built from the source at that point in the history so that it can be tested. Your developers could also share either code snippits or a short paragraph writeup of what they changed to fix it at that time. Right now all I have is your word which doesn’t mean much.
Bumping because still unfixed in latest r32 release, r35 release as well as Nvidia desktop GPU drivers.
Hi,
On Jerson Nano, we would suggest use landscape mode. This is the default mode and tested in each release.
Cool. What about portrait?
Hi,
On Jetson devices, portrait mode mode may not be as stable as landscape mode. Would like to suggest use landscape mode.
To reiterate:
The problem is:
Nvidia composition pipeline for Xorg has a terrible framepacing issue when enabled.
Using a native portrait display in landscape mode (very common in the embedded world where the tegras are SUPPOSED work well) or any other method of rotating the screen causes the aformentioned terrible composition pipeline to be enabled.
The problem exists on ALL currently released Nvidia GPU drivers (32.X, 34.x, 35.X embedded Tegra BSP drivers and Nvidia Desktop GPU drivers).
As I previously suggested, the nvidia drivers should be reworked so that xorg rotation does NOT go through the composition pipeline at all, this should never have been a requirement. VIC (on tegras) should be used for transformation and rotation of xorg like it is done in the multimedia apis.
Hi,
Since landscape mode is well tested, we would suggest use this mode. Portrait mode may not be as stable as landscape mode.