Libargus-Daemon Excessive CPU Utilization

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
1

Hi,

I’ve been running some benchmarks on the Xavier NX, and noticed that, with any gstreamer pipeline, for example:

gst-launch-1.0 nvarguscamerasrc aelock=true ispdigitalgainrange="1 1" gainrange="1 1" aeantibanding=0 wbmode=0 ee-mode=0 tnr-mode=0 ! 'video/x-raw(memory:NVMM), format=(string)NV12, width=(int)1440, height=(int)1080' ! fakesink -e

In this pipeline nvargus-daemon uses 22.5%, other pipelines that convert the pixel format, limit framerate or any other basic task, nvargus-daemon can use up to 40% of the CPU.

I don’t understand why the usage is so high, my understanding is that Libargus has access to 2 ISPs, which should offload some of the work done on the CPU. Does anyone know why CPU usage is so high?

3

Hi,
Please run sudo jetson_clocks and sudo tegrastats to get system loading. It shows loading of each CPU core and is more accurate and clear.

4

Dear @DaneLLL. Thanks for the advice, I tried running that and got the following results:

core 1: 13.34%
core 2: 12.28%
core 3: 12.1%
core 4: 8.97%
core 5: 4.66%
core 6: 4.72%

Some of the more senior people in my team believe that this CPU usage is still high for simply pulling frames from the ISP of the Xavier, and moving them to the DMA buffer and other locations. Would you be able to explain why the CPU usage is relatively high? Perhaps it can lowered/optimised?

Thanks,

Alexis

5

Hi,
Please share the print like:

GST_ARGUS: 2592 x 1944 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 16.000000; Exposure Range min 34000, max 550385000;

GST_ARGUS: 2592 x 1458 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 16.000000; Exposure Range min 34000, max 550385000;

GST_ARGUS: 1280 x 720 FR = 120.000005 fps Duration = 8333333 ; Analog Gain range min 1.000000, max 16.000000; Exposure Range min 22000, max 358733000;

GST_ARGUS: Running with following settings:
   Camera index = 0
   Camera mode  = 1
   Output Stream W = 2592 H = 1458
   seconds to Run    = 0
   Frame Rate = 29.999999

Would like to know all sensor modes and which sensor is running. And is it the result of running single camera? Or multiple cameras?

6

Hi @DaneLLL,

The high CPU usage was with just 1 camera.

Here’s the stdout you requested:

GST_ARGUS: Available Sensor modes :
GST_ARGUS: 1440 x 1080 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 0.000000, max 480.000000; Exposure Range min 29000, max 15110711000;

GST_ARGUS: 704 x 540 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 0.000000, max 480.000000; Exposure Range min 29000, max 15110711000;

GST_ARGUS: Running with following settings:
   Camera index = 0 
   Camera mode  = 0 
   Output Stream W = 1440 H = 1080 
   seconds to Run    = 0 
   Frame Rate = 59.999999
7

Hi,
The mode you run is 1440x1080p60. For comparing the 60fps case, we run Raspberry Pi camera V2(imx219) in 1280x720p60:

$ gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM),width=1280,height=720,framerate=60/1' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

And get the result:

RAM 2775/7766MB (lfb 470x4MB) SWAP 3/3883MB (cached 0MB) CPU [7%@1420,8%@1420,16%@1420,10%@1420,11%@1420,10%@1420] EMC_FREQ 5%@1600 GR3D_FREQ 0%@1109 VIC_FREQ 34%@115 APE 150 MTS fg 0% bg 10% AO@30.5C GPU@31C PMIC@100C AUX@31C CPU@32C thermal@31.25C VDD_IN 4621/4712 VDD_CPU_GPU_CV 1145/1354 VDD_SOC 1633/1495
RAM 2775/7766MB (lfb 470x4MB) SWAP 3/3883MB (cached 0MB) CPU [7%@1420,12%@1420,15%@1420,16%@1420,10%@1420,10%@1420] EMC_FREQ 5%@1600 GR3D_FREQ 0%@1109 VIC_FREQ 41%@115 APE 150 MTS fg 0% bg 10% AO@31C GPU@31.5C PMIC@100C AUX@31C CPU@32.5C thermal@31.6C VDD_IN 4621/4706 VDD_CPU_GPU_CV 1145/1340 VDD_SOC 1633/1504
RAM 2775/7766MB (lfb 470x4MB) SWAP 3/3883MB (cached 0MB) CPU [9%@1420,6%@1420,13%@1420,14%@1420,14%@1420,10%@1420] EMC_FREQ 5%@1600 GR3D_FREQ 0%@1109 VIC_FREQ 0%@115 APE 150 MTS fg 0% bg 10% AO@30.5C GPU@31.5C PMIC@100C AUX@31C CPU@32.5C thermal@31.45C VDD_IN 4621/4700 VDD_CPU_GPU_CV 1145/1328 VDD_SOC 1633/1512
RAM 2775/7766MB (lfb 470x4MB) SWAP 3/3883MB (cached 0MB) CPU [8%@1420,6%@1420,16%@1420,13%@1420,10%@1420,9%@1420] EMC_FREQ 4%@1600 GR3D_FREQ 0%@1109 VIC_FREQ 2%@115 APE 150 MTS fg 0% bg 11% AO@31C GPU@31.5C PMIC@100C AUX@31C CPU@32C thermal@31.45C VDD_IN 4662/4698 VDD_CPU_GPU_CV 1185/1319 VDD_SOC 1633/1519
RAM 2775/7766MB (lfb 470x4MB) SWAP 3/3883MB (cached 0MB) CPU [9%@1420,8%@1420,14%@1420,13%@1420,12%@1420,9%@1420] EMC_FREQ 4%@1600 GR3D_FREQ 0%@1109 VIC_FREQ 7%@115 APE 150 MTS fg 0% bg 10% AO@31C GPU@31.5C PMIC@100C AUX@31C CPU@32C thermal@31.45C VDD_IN 4621/4694 VDD_CPU_GPU_CV 1145/1310 VDD_SOC 1633/1526

The result is similar to yours. We think this is expected. It still requires certain CPU utilization, although there is ISP engine doing debayering.