- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We are developing a multithreaded application, which decodes video files, converts each frame to RGB pixel format and does some other processing. Earlier we used ffmpeg for both decoding and conversion and then tried to use IPP library in order to accelerate the conversion stage on Intel processors. It started to crash on some machines (OS AlmaLinux 8 x86_x64), where IPP used k0 versions of .so (shared object) files. Although it worked fine on the docker image on that machine where k0 .so-files were removed, but such docker image refused to start on other machines, because ippInit returned status ippStsWaterfall (43). So, we need to somehow fix k0 version or get it working, even if l9 version of IPP runs on CPUs with AVX-512 support.
IPP library is linked there dynamically via dlopen(), dlsym() C++ functions. For now, we only need a single function from IPP: ippiYCbCr420ToRGB_8u_P3C3R() (not taking into account ippInit, etc.).
The segmentation fault happens not on the first call, but usually after tens or hundreds of successful calls, which complicates debugging. But it is inevitable from run to run.
Firstly, we tried to exclude issues caused by wrong allocation or alignment, so we used ippsMalloc_8u/ippsFree calls to allocate/free memory for the source and the destination buffers of ippiYCbCr420ToRGB_8u_P3C3R(). The app still crashed.
We couldn’t fix anything with k0 version, so we tried to switch to l9 after the call to ippInit(). So, we tried to do that using ippSetCpuFeatures(L9_FM) or ippSetCpuFeatures(ippGetEnabledCpuFeatures() & 0x000FFFFF). It returned ippStsNoErr (0) and ippccGetLibVersion()->Name became equal to “ippCC AVX2 (l9)”. However, strangely enough we got the k0 version of function k0_ippiYCbCr420ToRGB_8u_P3C3R (or sometimes, k0_ownscDftFwd_Prime14_32fc) in the stack trace of SIGSEGV.
We tried to call ippSetCpuFeatures again just before each call to ippiYCbCr420ToRGB_8u_P3C3R and it returned ippStsNoErr (0). Also, in this case ippccGetLibVersion() returned “ippCC AVX-512F/CD/BW/DQ/VL (k0)” instead of l9 at the initialization. It didn't fixed the segfault.
We tried to use a mutex to exclude influence of multithreading. No effect.
Best regards!
We are developing a multithreaded application, which decodes video files, converts each frame to RGB pixel format and does some other processing. Earlier we used ffmpeg for both decoding and conversion and then tried to use IPP library in order to accelerate the conversion stage on Intel processors. It started to crash on some machines (OS AlmaLinux 8 x86_x64), where IPP used k0 versions of .so (shared object) files. Although it worked fine on the docker image on that machine where k0 .so-files were removed, but such docker image refused to start on other machines, because ippInit returned status ippStsWaterfall (43). So, we need to somehow fix k0 version or get it working, even if l9 version of IPP runs on CPUs with AVX-512 support.
IPP library is linked there dynamically via dlopen(), dlsym() C++ functions. For now, we only need a single function from IPP: ippiYCbCr420ToRGB_8u_P3C3R() (not taking into account ippInit, etc.).
The segmentation fault happens not on the first call, but usually after tens or hundreds of successful calls, which complicates debugging. But it is inevitable from run to run.
Firstly, we tried to exclude issues caused by wrong allocation or alignment, so we used ippsMalloc_8u/ippsFree calls to allocate/free memory for the source and the destination buffers of ippiYCbCr420ToRGB_8u_P3C3R(). The app still crashed.
We couldn’t fix anything with k0 version, so we tried to switch to l9 after the call to ippInit(). So, we tried to do that using ippSetCpuFeatures(L9_FM) or ippSetCpuFeatures(ippGetEnabledCpuFeatures() & 0x000FFFFF). It returned ippStsNoErr (0) and ippccGetLibVersion()->Name became equal to “ippCC AVX2 (l9)”. However, strangely enough we got the k0 version of function k0_ippiYCbCr420ToRGB_8u_P3C3R (or sometimes, k0_ownscDftFwd_Prime14_32fc) in the stack trace of SIGSEGV.
We tried to call ippSetCpuFeatures again just before each call to ippiYCbCr420ToRGB_8u_P3C3R and it returned ippStsNoErr (0). Also, in this case ippccGetLibVersion() returned “ippCC AVX-512F/CD/BW/DQ/VL (k0)” instead of l9 at the initialization. It didn't fixed the segfault.
We tried to use a mutex to exclude influence of multithreading. No effect.
Best regards!
Link Copied
0 Replies
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page