eglstream with gstreamer pipe problem in TX1 28.2.1 with Jetpack 3.3

Hi DaneLLL,

Sorry, it’s my mistake.

Our platform is IMX274 module with our carry board,
but we use the BSP and file system is based on L4T28.2 and Jetpack 3.3.
So, did you have any advise that we could try to fix this problem?

If you need more information please feel free to ask, thanks.

Best Regards,
Walker

Hi,
Please get libcuda.so.1.1 of r28.3, overwrite it to r28.2, and give it a try.

/usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1.1

It is better that we can reproduce it locally and do further debugging. However, libcuda in new release may help the case and is worth a try…

Hi DaneLLL,

Got it, thank you very much.

Btw, could you provide the library for us, please?
Because we don’t have the 28.3 environment currently,
if you could provide the library,
we can double confirm the md5sum with you’re platform,
thanks.

Best Regards,
Walker

Hi,
It is in https://developer.nvidia.com/embedded/dlc/l4t-jetson-driver-package-28-3-tx1
Please extract downloaded package and then extract Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2

Hi DaneLLL,

I Got it,
but after I change the cuda library to 28.3,
I try to rebuild the sample code, and we force the compile error as below.
Maybe I need update other libraries for this test?

Scanning dependencies of target argus_gstvideoencode
[ 39%] Built target argus_bayeraveragemap
[ 41%] Building CXX object samples/gstVideoEncode/CMakeFiles/argus_gstvideoencode.dir/main.cpp.o
[ 42%] Building CXX object samples/histogram/CMakeFiles/argus_histogram.dir/main.cpp.o
[ 43%] Building CXX object samples/cudaHistogram/CMakeFiles/argus_cudahistogram.dir/main.cpp.o
[ 44%] Linking CXX executable argus_facedetect
[ 46%] Linking CXX executable argus_cudahistogram
[ 46%] Built target argus_facedetect
/usr/bin/ld: warning: libnvidia-fatbinaryloader.so.28.3.0, needed by /usr/lib/gcc/aarch64-linux-gnu/5/…/…/…/aarch64-linux-gnu/libcuda.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/aarch64-linux-gnu/5/…/…/…/aarch64-linux-gnu/libcuda.so: undefined reference to fatBinaryCtl_Create' /usr/lib/gcc/aarch64-linux-gnu/5/../../../aarch64-linux-gnu/libcuda.so: undefined reference to elfLink_Finish’
/usr/lib/gcc/aarch64-linux-gnu/5/…/…/…/aarch64-linux-gnu/libcuda.so: undefined reference to elf64_symbol_name' /usr/lib/gcc/aarch64-linux-gnu/5/../../../aarch64-linux-gnu/libcuda.so: undefined reference to elf64_string_at_offset’
/usr/lib/gcc/aarch64-linux-gnu/5/…/…/…/aarch64-linux-gnu/libcuda.so: undefined reference to fatBinaryCtl_Delete' /usr/lib/gcc/aarch64-linux-gnu/5/../../../aarch64-linux-gnu/libcuda.so: undefined reference to elf_size’
/usr/lib/gcc/aarch64-linux-gnu/5/…/…/…/aarch64-linux-gnu/libcuda.so: undefined reference to elf64_section_contents' /usr/lib/gcc/aarch64-linux-gnu/5/../../../aarch64-linux-gnu/libcuda.so: undefined reference to elfLink_Load_Host_Object’

Best Regards,
Walker

Hi,
Are you able to upgrade to r28.3?

Hi DaneLLL,

Sorry, we can’t do that currently,

Because we have some modification in L4T282 BSP by other team member,
so we could no easily to change the modification to L4T283.

About this issue do you have any other advise/patch for workaround,
Maybe I could try use other sample code to capture frame?

Best Regards,
Walker

Hi DaneLLL,

We found some information about this issue,
when we only run the sample code with #12 test library,
we could pass the overnight test.

But when we also enable our ai recognition algorithm (implement with cuda) whit the appsink image data,
we could easily reproduce this issue.
Maybe this problem is fixed in libcuda 28.3 or you have other idea in this problem?
If the problem is relative libcude 28.2, could you help to provide the test lib in 28.2 libcuda?

Thanks you very much.

Best Regards,
Walker

Hi,
Please try the attachment. If the issue is still present, please share one more test code so that we can reproduce it.
R28_2_TEST_libcuda.so.1.1.zip (2.58 MB)

Hi DaneLLL,

Got it, thanks!!
I will test instantly.

Best Regards,
Walker

Hi DaneLLL,

With the test library #12 and #29, the problem was still occurred.
But the problem occurred after the test code had run nearly 20min~30min.
The result is more improve than before.

Btw, since our test code have some confidential data,
I will check the data is fine to pass.

Best Regards,
Walker