Simple EGL vsync app drops frames and stutters on Nano (but not TX2)

Please help me diagnose and resolve this juddering frame drop issue.

I wrote a simple EGL program that reproduces a problem I’m having with vsync on the Nano.

My simple application experiences juddering (frame drops) on the Nano. But on a TX2 board, the output is silky smooth. So I suspect it’s something specific to the Nano. I’ve tried multiple Nano boards - they all exhibit the same problem.

The code to reproduce the problem is available at GitHub: https://github.com/wyckster/vline. It just renders a moving vertical line that moves at a rate of 16 pixels per frame. The motion makes any failure to maintain vsync (tearing and frame drops) easily noticeable to the naked eye.

I observe that this application goes from rendering at 60 fps with smooth output for a few minutes, then will judder at 30 fps for a few minutes, then go back to 60 fps. It repeats this pattern, as if there were some phase difference between the refresh and output that is going in and out of a good state in a cyclic / sinusoidal period of several minutes. The problem always appears within at most about 5 minutes.

Being able to maintain good vsync and render at 60 fps is a critical performance aspect to my application. If it were just a single frame dropped here and there, it would be tolerable, but this is long periods of juddering, dropping from 60 fps to 30 fps for many minutes at a time, even in this very simple application with minimal load on the machine.

I happen to be displaying on two Optoma ML550 projectors at 1280x800 resolution.

Output of xrandr follows:

Screen 0: minimum 8 x 8, current 1280 x 1600, maximum 16384 x 16384
HDMI-0 connected primary 1280x800+0+800 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800      59.81*+  59.81
   1920x1080     60.00    59.95    50.00    24.00    23.98
   1680x1050     59.96
   1366x768      59.79
   1280x1024     75.03    60.00
   1280x960      60.00
   1280x720      60.00    59.94    50.00
   1152x864      75.00
   1024x768     120.05    75.03    70.07    60.01
   832x624       75.05
   800x600      120.09    75.00    72.19    60.32    56.25
   720x576       50.00
   720x480       59.94
   720x400       70.04
   640x480       75.00    72.81    67.06    59.94    59.94
DP-0 connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800      59.81*+  59.81
   1920x1080     60.00    59.95    50.00    24.00    23.98
   1680x1050     59.96
   1366x768      59.79
   1280x1024     75.03    60.00
   1280x960      60.00
   1280x720      60.00    59.94    50.00
   1152x864      75.00
   1024x768     120.05    75.03    70.07    60.01
   832x624       75.05
   800x600      120.09    75.00    72.19    60.32    56.25
   720x576       50.00
   720x480       59.94
   720x400       70.04
   640x480       75.00    72.81    67.06    59.94    59.94

Hi,
Do you run ‘sudo jetson_clocks’ before running the application? Please also run ‘sudo tegrastats’ to profile loading of hardware blocks. GPU capability is much different between TX2 and Nano. You may hit performance limitation on Nano.

Hi wyckster,

We tried to reproduce issue with your code on r32.2/Jetson-Nano.
Running 30 mins, I don’t see the frame drops issue by naked eye.
Are you only running “vline” application? or you have run others application at same time?

@DaneLLL I did not run jetson_clocks. I will give that a try, though. I will also try the tegrastats thing.
I’m curious though: How can there be a performance limitation that prohibits me from basically just doing an eglSwapBuffers call at 60 fps? The system should be idle for 16 of every 16.67 ms don’t you expect. Can you please explain the performance limitation?

@carolyuu I only run vline. Did you test the same resolutions? Is it specific to the video mode / resolution? Is it only when driving two displays? Did you really do the same test as me?

No, we only drive it in single monitor with 1080p@60 mode. We could try to use dual monitor case today. However, please note that we don’t have a monitor that is identical to yours with 59.81 fps.

Please also try to narrow down the cause on your side. For example, try a single monitor case.

Also, do you observer this error with naked eye? If so, what is expected to see during the test? Will we see the bar moving slower at sometime and back to normal speed (60fps) then?

jetson_clocks solves the problem.

Maybe I’m presuming too much, but, I feel like it is a bug (or a design flaw) that the system fails to perform adequately to swap buffers in a timely manner without having run jetson_clocks. Why can’t I have DVFS and vsync together? Why does it stutter if jetson_clocks has not been run?

** I SPOKE TOO SOON **

I have been testing this all day. And I still get stutters.

jetson_clocks seems to improve performance, but it doesn’t completely eliminate the problem. It now takes about 3 hours for it to get out of sync.

When it is out of sync. You can press Ctrl+C and kill the app, and then re-launch it, and it will stay out of sync. It seems to precess over a long period. Is there a bug of some kind with 59.81 Hz modes?

Hi,
For more information, could you try 59.94 and 60 Hz to check if it is specific to 59.81 Hz?

I do not know how to “try 59.94 and 60 Hz”. Can you provide steps?

It seems like just about anything will make it tear. If I rearrange the layout of the monitors on my desktop (like place them one on top of the other instead of side by side, or put one in flipped mode, or offset one slightly like 1280x800+0+15) then the tearing gets MUCH worse. This makes me guess that there is some ideal mode (maybe 1920x1080 @60Hz?) where it might be ok (I haven’t tried). But basically this thing tears like crazy all the time.

I’m pretty unhappy about that. What can I do? I’m not sure how to force it to output a specific 60 Hz mode that my projectors can handle. Anyway, the thing shouldn’t tear, regardless of the mode. So I claim this is a bug. :(

Hi,
Since we don’t have the device which can output in 59.81Hz and don’t observe the issue when running in 59.94 and 60 Hz, would like to suggest you try 59.94 and 60 Hz.

We will try a longer long-run test to reproduce the issue.

@DaneLLL, I will need instructions on how to try 60Hz, please. I assume there’s some way to change the refresh rate - I don’t know what it is.

Hi,
Please try xrandr

I don’t think the EDID will allow it. Here’s what I tried.

$ cvt 1280 800 60
# 1280x800 59.81 Hz (CVT 1.02MA) hsync: 49.70 kHz; pclk: 83.50 MHz
Modeline "1280x800_60.00"   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync
$ xrandr --newmode "1280x800_60.00"   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync
$ xrandr --addmode DP-0 "1280x800_60.00"
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  18 (RRAddOutputMode)
  Serial number of failed request:  27
  Current serial number in output stream:  28

More Info:

It works correctly with only one display (if I disconnect one display, the other works fine). So this likely has something to do with multiple displays.

Screen 0: minimum 8 x 8, current 1280 x 800, maximum 16384 x 16384
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800      59.81*+  59.81  
   1920x1080     60.00    59.95    50.00    24.00    23.98  
   1680x1050     59.96  
   1366x768      59.79  
   1280x1024     75.03    60.00  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768     120.05    75.03    70.07    60.01  
   832x624       75.05  
   800x600      120.09    75.00    72.19    60.32    56.25  
   720x576       50.00  
   720x480       59.94  
   720x400       70.04  
   640x480       75.00    72.81    67.06    59.94    59.94

Hi

What we wanted to suggest is please use something like

xrandr --output HDMI-0 -s 1920x1080 -r 60.00
but not adding a new mode. Our driver is not allowed to add a new mode.

Could you help take a video for us to understand your problem more clear?