Xavier & TX2 suffering from consistent VSync tear at top of screen. Affecting 4k resolutions

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

The monitor models tested on are:

  • Samsung U32H 850UMU
  • MultiSync X841 UH NEC - 2SST

We’ve been able to replicate the following on the TX2 and the Xavier with the same result.

The top point of the screen has a subtle yet consistent VSync tear. When the PC monitor was used in portrait mode the tear was barely visible. The landscape mode is most impacted by the tear.

This can be easily replicated by running a full screen application with motion in 4k on either of the Jetson devices. It’s worth noting we used an HDMI 2.0 cable.

This is a significant issue and will influence whether we will be able to utilize the Jetson range within our distribution.

Any help and feedback would be very beneficial.

Many thanks in advance,

Lance

2

Hi Lance,

Thanks for reporting this issue.

1.May I have some of the pictures from your screen for your tearing issue?
2. could you tell us how you configure the landscape and portrait mode?
3. If you run a vsync application (e.g. EGL or gstreamer), would you see the tearing issue?

3

Hi Wayne,

Thanks for getting back. Just following up here from Lance’s team.

  1. Please find on https://we.tl/t-l1hSNIh0FD a video showing the screen tear issue
  2. Landscape mode 4k 86" screen, changed via the GUI (Linux > System Settings > Displays). We tested on a 120hz screen and on a 60hz screen and result is the same. See more details on the output log quoted below.
  3. This is an application using SDL Vulkan renderer. It’s built in Unreal Engine. Vulkan mobile (ES3.1) gives the same screen tearing result.
    I can’t replicate the issue with gst-launch-1.0, but I couldn’t get gst-launch to go full-screen and the tx2 dev kit camera is not 4k anyway, so that might not be a good test.
[2020.01.24-12.27.15:715][  0]LogInit: Initializing SDL.
[2020.01.24-12.27.15:838][  0]LogInit: Initialized SDL 2.0.10 revision: 12952 (hg-12952:bc90ce38f1e2) (compiled against 2.0.10)
[2020.01.24-12.27.15:838][  0]LogInit: Using SDL video driver 'x11'
[2020.01.24-12.27.15:838][  0]LogInit: Display metrics:
[2020.01.24-12.27.15:838][  0]LogInit:   PrimaryDisplayWidth: 3840
[2020.01.24-12.27.15:838][  0]LogInit:   PrimaryDisplayHeight: 2160
[2020.01.24-12.27.15:838][  0]LogInit:   PrimaryDisplayWorkAreaRect:
[2020.01.24-12.27.15:839][  0]LogInit:     Left=65, Top=24, Right=3840, Bottom=2160
[2020.01.24-12.27.15:839][  0]LogInit:   VirtualDisplayRect:
[2020.01.24-12.27.15:839][  0]LogInit:     Left=65, Top=24, Right=3840, Bottom=2160
[2020.01.24-12.27.15:839][  0]LogInit:   TitleSafePaddingSize: X=0.000 Y=0.000 Z=0.000 W=0.000
[2020.01.24-12.27.15:839][  0]LogInit:   ActionSafePaddingSize: X=0.000 Y=0.000 Z=0.000 W=0.000
[2020.01.24-12.27.15:839][  0]LogInit:   Number of monitors: 1
[2020.01.24-12.27.15:839][  0]LogInit:     Monitor 0
[2020.01.24-12.27.15:839][  0]LogInit:       Name: EP5814K 57"
[2020.01.24-12.27.15:839][  0]LogInit:       ID: display0
[2020.01.24-12.27.15:839][  0]LogInit:       NativeWidth: 3840
[2020.01.24-12.27.15:839][  0]LogInit:       NativeHeight: 2160
[2020.01.24-12.27.15:839][  0]LogInit:       bIsPrimary: true

[...]

[2020.01.24-12.27.15:948][  0]LogInit: Using SDL_WINDOW_VULKAN
[2020.01.24-12.27.16:812][  0]LogVulkanRHI: Display: Nvidia User Driver Version = 32.1

Let me know if you need more info.

4

I remembered once had sdl issues on this forum before. Actually, we don’t have any SDL based application.

Please try to use a egl based sample if possible.

5

Hi Wayne,

That’s not possible for us, as far as I understand. We don’t develop the engine.

From a quick research I found the following comments in the engine’s release notes https://docs.unrealengine.com/en-US/Support/Builds/ReleaseNotes/2016/4_14/index.html:

New: Added "offscreen" video driver to SDL so the engine can now create GL context on headless machines not running any display servers (EGL is enough).

Bugfix: Fixed an issue with SDL EGL API binding.

Seems to me like it uses EGL under the hood after all.

Is there any extra info or resource I can provide for you to be able to check on that? Any thoughts of where the issue might be?

6

Hi PauloRenan,

Let me check with our internal team for this case. I will reply you after we have some update.

7

Hi,

Sorry for one more question.

Landscape mode 4k 86" screen, changed via the GUI

Is using landscape mode a “must-have” to reproduce the vsync problem?

8

No, it’s not a must-have.
We reproduced this in a portrait mode 4k 60hz 32" monitor, but the tearing was a bit less noticeable.

9

We will try some samples from UE and see if we could reproduce this issue.

10

Hi PauloRenan,

We tried some UE4 demos application and cannot see any tearing.

Could you share your sample to us to reproduce issue? For full screen application in X11, we should not see any tearing. Is your application a full screen one?

11

Hi Wayne,

Please find attached a very simple packaged project we put together only to show the screen tearing.
https://we.tl/t-AXUV5TSgZj

If you test on a xavier, just run

./VsyncTest-AArch64.sh

If you test on Nano or TX2, you can run

./VsyncTest-AArch64.sh -vulkan -featureleveles31

You may have to add permission to execute as a program, but surely that’s now news for you.

sudo chmod +x VsyncTest-AArch64.sh

We would be grateful to receive assistance on this matter as soon as possible, as we are deep in production and keen to stick with the Jetson platform for this project. Please don’t hesitate to ask if you need any further information.

Many thanks in advance!

12

Hi PauloRenan,

Thanks for sharing. Let us try to reproduce this issue on our side.

13

Hi Wayne,

Just curious, is there any update on that thread?

14

I’ve done some digging, and I noticed a few things:

  1. Horizontal screen tear is present in full-screen (at fixed place at the top with vsync on, and everywhere with vsync off)
  2. No screen tear in window mode.
  3. cat /sys/class/graphics/fb0/modes does not list any 4k@60 mode available
  4. xrandr doesn’t show any 4k@60 mode available. If I do xrandr --current --rate 30 I get “Rate 30.00 Hz not available for this size”. Tried setting rate 50, and it defaults to 30. Anything beyond 50 defaults to 24.

I tried:
• changing modeline with xrandr to activate/deactivate vsync/hsync
• setting vsync and hsync to low/high with fbset
• made sure hdmi cable and monitor are 4k@60 capable
But so far nothing helped.

I’m really hoping for some direction of where to look at to go around this issue. Whether there is a way to calculate the display timings and set manually via fbset, or there is some tool that should fix sync issues like that?

That is reproducible in three different 4k monitors I tried so far.

15

Hi PauloRenan,

Thanks for your update. Actually we already filed an internal ticket for this issue. Unfortunately we don’t have resources at this moment so need to prioritize it.

As for your problem:

  1. cat /sys/class/graphics/fb0/modes does not list any 4k@60 mode available
  2. xrandr doesn’t show any 4k@60 mode available. If I do xrandr --current --rate 30 I get “Rate 30.00 Hz not available for this size”. Tried setting rate 50, and it defaults to 30. Anything beyond 50 defaults to 24.

The monitor modes may be filtered by our driver because some display has non-CEA mode which tegra doesn’t support.
Also, all the modes or refresh rate must be defined in your monitor so that xrandr can use it.

16

Hi PauloRenan,

I am also wondering… does change different monitor modes could avoid this issue? Since your post said 4k@60 is not shown, you are using 4k@30 to reproduce this mode,right?

17

Hi.

Could you also try to add ForceCompositionPipeline in your xorg.conf and see if the FPS gets any difference? or if this issue is resolved?

18

Hi Wayne,

Thanks for getting back. I understand resourcing is not unlimited and has to be prioritized. As you surely can appreciate happens on our end too. At some point it becomes not worth digging too deep into the graphics driver to fix things we don’t specialize on.

Changing different monitor modes does not avoid this issue. I tried all available modes in /sys/class/graphics/fb0/modes to no avail. Same with plugging cable off-and-on, restarting device, doesn’t seem to help. In fact thanks for asking. I tried now even with lower resolution, and I still get the same tearing issue. More or less noticeable depending on the framerate application can render, and so on, but the tear is still there.

My xorg.conf looks like this:

Section "Module"
        Disable         "dri"
        SubSection  "extmod"
        Option          "omit xfree86-dga"
        EndSubSection
EndSection

Section "Device"
        Identifier        "Tegra0"
        Driver             "nvidia"
        Option            "AllowEmptyInitialConfiguration" "true"
EndSection

How exactly should I “add” ForceCompositionPipeline to the file? Last time I tried modifying this file I did it wrong and had to re-flash the board. (I can use sudo gedit, just don’t know where the tag is supposed to go)

PS: I compiled the same application for Linux x86_64, portable ubuntu 18.04 in a usb stick, with default drivers (Ryzen 3400G APU) and out of the box, no screen tear. Unreal offers official support now for linux aarch64, so I was able to compile for different target and cross-check.

19

Hi,
I am sorry that don’t have a xorg file to show you directly at this moment. You need to put it under the device section as an option with “On”.

You could refer to some result from google search too since xorg file is a general file on both ubuntu host and L4T.

20

Screen still doesn’t work at 4k@60, but no screen tear with this change! Thanks!
Just added the line

        Option            "ForceCompositionPipeline " "on"

below the other existing option under “Device”