Reducing delay from OpenGL command to pixels being visible


I’m making a scientific application where I need to have as little time as possible between OpenGL drawing commands and pixels lighting up on the screen. I test this round trip time using a computer running a real-time OS running at 4 kHz connected to a photodiode. The general process is: RTOS sends a command to draw, 2nd computer receives the command and uses OpenGL to draw simple 2D shapes on the screen, RTOS reads the photodiode to see how long the process took.

Historically the 2nd computer has been Windows based and now we are trying to use either a TX2 or a nano. The Windows computer uses integrated Intel HD630 graphics. On our reference system (using a 60 Hz display with an HDMI connection, Windows 10 computer for drawing) this would normally produce latencies on the order of 34ms from RTOS command to pixels lighting up.

Using both the nano and TX2 in our reference system (Windows 10 computer removed) the time from RTOS command to pixels lighting up is 46ms. Running the program with “jetson_clocks” made it worse at about 51ms. Applying all updates to the nano and TX2 didn’t make any difference. Using linux gamemode did not make any difference.

The code to listen for drawing commands is written in Java (so it can run on Windows or Linux) and using JOGL to draw to a full screen window. The drawing is all OpenGL 1.1 compatible. For the testing scenario, 5 circles are drawn using a triangle fan with about 30 vertices. So the drawing is not particularly intense.

Does anyone have an idea where the extra 12 ms may be coming from for the nano and TX2? Does anyone have any ideas about how to reduce this?

Please let me know if there are any other details I should provide.


For information, please share your release version( $ head -1 /etc/nv_tegra_release ).
And you can run sudo tegrastats to get overall system loading. May be able to see where the bottleneck is.

Hi Dane,

The version of the TX2 is:

# R32 (release), REVISION: 3.1, GCID: 18284527, BOARD: t186ref, EABI: aarch64, DATE: Mon Dec 16 21:38:34 UTC 2019

The output of tegrastats while the program is running is:

RAM 2769/7859MB (lfb 575x4MB) SWAP 0/3929MB (cached 0MB) CPU [95%@2000,off,off,94%@2000,96%@2004,94%@2004] EMC_FREQ 8%@1600 GR3D_FREQ 23%@216 APE 150 PLL@43.5C MCPU@43.5C PMIC@100C Tboard@37C GPU@40.5C BCPU@43.5C thermal@42.5C Tdiode@40.25C VDD_SYS_GPU 229/229 VDD_SYS_SOC 689/689 VDD_4V0_WIFI 19/25 VDD_IN 5326/5262 VDD_SYS_CPU 1914/1888 VDD_SYS_DDR 1286/1260

Thanks for the help!

Looks like CPUs are at full loading. Please execute sudo nvpmodel -m 0 and sudo jetson_clocks. See if running at max performance mode helps.

Sorry for the delayed reply!

I used both sudo nvpmodel -m 0 and sudo jetson_clocks and ran my program. Tegrastats during my program running showed:

RAM 2534/7859MB (lfb 916x4MB) SWAP 0/3929MB (cached 0MB) CPU [5%@2005,7%@2035,8%@2034,1%@2035,0%@2034,0%@2035] EMC_FREQ 1%@1866 GR3D_FREQ 2%@1300 APE 150 MTS fg 0% bg 0% PLL@33.5C MCPU@33.5C PMIC@100C Tboard@29C GPU@31.5C BCPU@33.5C thermal@32.7C Tdiode@30.75C VDD_SYS_GPU 306/306 VDD_SYS_SOC 842/842 VDD_4V0_WIFI 19/19 VDD_IN 3985/3985 VDD_SYS_CPU 536/536 VDD_SYS_DDR 1228/1228

As I mentioned initially, my mean latency jumped from 46ms to ~51ms. So not it’s taking 5ms longer for pixels to light up.

I rewrote part of my application to use OpenGL 3 and ran again using sudo nvpmodel -m 0 and sudo jetson_clocks. The Tegra_stats for this looked like:

RAM 3141/7859MB (lfb 498x4MB) SWAP 0/3929MB (cached 0MB) CPU [6%@2031,7%@2034,6%@2035,0%@2034,0%@2035,0%@2035] EMC_FREQ 1%@1866 GR3D_FREQ 3%@1300 APE 150 MTS fg 0% bg 0% PLL@34C MCPU@34C PMIC@100C Tboard@30C GPU@32C BCPU@34C thermal@33.4C Tdiode@31.25C VDD_SYS_GPU 306/306 VDD_SYS_SOC 842/842 VDD_4V0_WIFI 19/19 VDD_IN 4251/4251 VDD_SYS_CPU 536/536 VDD_SYS_DDR 1228/1228

So no major change from using OpenGL 1.1 to 3.0. The time for pixels to light up on the screen was still 51ms.

I reran my test using the same program on windows 7 and found the time for pixels to light up was still ~34 ms (for both OpenGL 1 and 3).

Any other idea about why there is the extra latency would be very appreciated.


I’ve tried a few more settings and openGL calls. This one looked promising since he was talking about exactly what I needed:

Unfortunately this added at least 2 more frames (70+ ms for pixels to light up).