Libargus Performance

[zschutschke]

Hi,

We observe a high CPU load and multiple processes spawned by libargus for a single cam (12MP Color@20fps), basically just a free running image pipeline:

█████████████████████████████████ 5.45 % CaptureSchedule (6453) 0 [20]
███████████████████ 3.12 % SCF Execution (6440) 0 [20]
███████████████████ 3.10 % SCF Execution (6436) 0 [20]

I saw similar questions around, which not really got answered though:

Argus high cpu usage streaming cameras

We have six csi cameras that we get images from using argus @ 30fps. We’ve noticed that just streaming the cameras by calling iFrameConsumer->acquireFrame() incurs a pretty high cpu load (~110% according to top). So it’s taking more than a core just to stream the cameras without any other processing. We’d love to reduce that if possible. Currently we are using JetPack 4.2.2 with argus in single process mode. Based on profiling results, the biggest parts appear to be: SCF_Execution. Looks like …

High CPU usage streaming from CSI2 cameras on Jetson NX

Hi Jerry, Thank you! I’ll stay tuned to see what you discover.

Questions:
(1) What are these doing? (I assume some CPU side processing for the ISP)
(2) Why is this that running with ~10% CPU, when there is a hardware ISP available?
(3) Is there a way to diagnose this any deeper? (Maybe this could be reduced by options on the argus pipeline)

Best,

Axel

[JerryChang]

hello zschutschke,

it’s camera application and EGL streams consume CPU resources, EGL is used by Argus APIs for buffer/stream management. mostly CPU usage was taken by argus_camera application due to buffer transmit. however, camera pipeline still need CPU to run lots of algorithms like AE, AWB, ToneMap…etc.

you may give it a try to disable camera preview frames, fetch the streaming by reporting frame-rate only.
this should result lower CPU usage since display rendering has disabled.
for example,
$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

[zschutschke]

Hi Jerry, thank you for your quick reply!

So basically, the auto-features are implemented as soft-ISP? I see that there will always be some overhead when it comes to buffer management and frame hand-over (on our side as well, the data needs to go somewhere obviously).

Is there a list of ISP features and whether they are solved in HW or in SW?

Best,

Axel

[JerryChang]

hello zschutschke,

may I have your expectation of CPU usage?

FYI, we’ve evaluation of the CPU usage by running 6-cam reference board on AGX Xavier, all of them were running at 1920x1440@30-fps.
the result shows the linear increase with multiple image sensors, which is 2% per camera.

[zschutschke]

I don’t have a fixed expectation. Just curious, why there is a significant CPU load to begin with, when we are talking about a system with an advertised hardware ISP. As I learn from your previous answer, parts of the ISP are implemented in software.

Is there a list of ISP features and whether they are solved in HW or in SW?

Best,

Axel

[JerryChang]

sorry, there’s no public documentation to list ISP features.

[zschutschke]

Thank you Jerry! I think this coarsely answers the question what the processes are doing.

One final question: we see two SCF Execution processes running for a single camera stream. Is this the expected behavior, or this an error on our side?

Best,

Axel

[JerryChang]

hello zschutschke,

please also share the complete steps, which application you’re used to enable camera stream.
what’s the app you’re used to monitor the CPU usage, BTW, had you try $ ps aux for checking its CPU usage also?