Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6711 Discussions

A problem with a FFI call to ippiAdd_8u which worked in version 5.0, but fails in 6

Blakel_H_
Beginner
387 Views

I have been using the Linux IPP image primitives for dealing with images, and have recently upgraded my Intel library to version 6. I use Steel Bank Common Lisp (SBCL) to call the Intel functions, which has worked perfectly in the past. With the new IPP library, however, the ippiAdd_8u functions when used in a C library causes a memory corruption error upon the C routine *returns* to SBCL. This may be a Lisp problem, however, the Intel version 5 function of the same name does not generate the error, nor do the ippiCopy commands or various other Intel functions when called. Has there been some change in the implementation of the ippiAdd_8u function between the two versions? The test program that is called by SBCL is completely self-contained and lisp does nothing more than call the C routine. The C test program that is called from lisp is as follows:

int iplibtest_check4()
{
IppiSize size = {320, 240};
// Allocation and initialization
int stride;
int stride2;
Ipp8u* pSrc = ippiMalloc_8u_C3(size.width, size.height, &stride);
Ipp8u* pSrc2 = ippiMalloc_8u_C3(size.width, size.height, &stride2);
ippiImageJaehne_8u_C3R(pSrc, stride, size);

int dstStride;
Ipp8u* pDst = ippiMalloc_8u_C3(size.width, size.height,
&dstStride);

ippiAdd_8u_C3RSfs( pSrc, stride, pSrc2,stride2,pDst, dstStride, size,0);

ippiFree(pDst);
ippiFree(pSrc);
ippiFree(pSrc2);
return 0;
}

The problem also shows up with ippiAdd_8u_C1, and with the in-place functions of Add. It does *not* show up with the functions like ippiCopy. The identical code as above runs without a problem when linked to the Intel 5.0 code.

Thanks for any help that you can give me on this.

Blake

cabjhurt -at embarqmail dot- com

0 Kudos
4 Replies
Gennady_F_Intel
Moderator
387 Views

Blake,

What was the return value for theippiAdd_8u_C1(....) function?

What is the exact version of IPP ( see <>/doc/ippsupport - Package ID: ???)

How do you link the ipp's libraries?

is it 32 or 64 bit's version of IPP?

--Gennady

0 Kudos
Blakel_H_
Beginner
387 Views

thanks for your response.

The result from the C function on its return was always, "no error", which I had printed in other test functions just before it would return to Lisp. In fact, it generally wouldn't fail in lisp until I would run a garbage collection.

I tried several versions of the library: originally it was on a 64 bit machine, with l_ipp_em64t_p_6.1.2.051, and then on a 32 bit machine with l_ipp_ia32_p_6.1.2.051 and also with l_ipp_ia32_p_6.1.1.042. The version that worked was with l_ipp_ia32_p_5.0.043 on the 32 bit machine. All the 6.* libraries give a memory error when the lisp garbage collector ran, or, sometimes, upon the immediate return of the call from the C program.

Here is the excerpt from my Make file for compiling and linking the library, iplib.so. I have used it as written with both the 6.1 libraries and the 5.0 by just reassigning the /opt/intel/ipp directory with a soft link from the 6.1 directory to the 5.0 and back. The little program given in my previous post which runs as a check is in the ipplisp.c code, but none of the rest the library is called, although the other code requires various additional libraries.

As for my procedure, I fire up lisp, load the iplib.so library, and then do a foreign function call on the C routine without parameters. The C program returns, and, when there is a print statement in the C code, it reports 'no errors'; it generally comes back to lisp as expected. It is only when I then issue a lisp instruction to garbage-collect that the memory failure occurs when using the IPP Add function. Other Intel functions, including copy, work as expected in version 6, but not the Add. They all work in version 5 on 32 bits.

From the my Make file:


OPT= -fPIC -Wall -g -std=gnu99
MKLIB= -shared -fPIC -Wall# used to make library

INC= -I/usr/local/include/opencv -I/opt/intel/ipp/include -I/opt/meschach -I/usr/local/include
# libraries related to image processing
##--------- 32 bit libraries
IMAGLIB=-lcxcore -lcv -lhighgui -lstdc++ -lippi -lippsc -lippsr -lipps -lippcv -lippcc -lippcore -lguide -lpthread -lgsl -lgslcblas -lm

LIB= -L/lib -L/usr/local/lib -L/usr/lib -L/opt/intel/ipp/sharedlib -L/opt/meschach # libs path
#------------------------------
main: opencvlisp.o ipplisp.o ipplisp-color.o debugging.o ocv_contours.o #wavelet_filter_bank.o m_wavelet.o
@echo ---------------------- Make iplib.so !---------------------
$(CC) $(OPT) $(MKLIB) $(INC) $(IMAGLIB) $(LIB) debugging.o opencvlisp.o ipplisp.o ipplisp-color.o -o iplib.so
@echo ---------------------- Make iplib.so !---------------------

As a further note, I would be happy if I could just get a copy of the 64bit library for the IPP 5.0 version; I have it for 32 bits, but it seems unavailable for 64 bits at this time.

thanks for your help. I realize this may not be an Intel problem; the subroutine when compiled as a standalone C program seems to operate without a problem. It does seem however that there is some issue with the Add function writing over some memory that Lisp expects to have. Nevertheless, I need it to operate with my lisp code.

thanks

Blake

0 Kudos
Gennady_F_Intel
Moderator
387 Views

Blake, I checked ( in the form of standalone program ) how it works on our side with the latest versions ( IPP 6.1 Update 3 and 4) and all work fine.

one comment - you linked libguide, but we strongly recommend to link with the latest libiomp5md with versions later >= 6.0( although I am almost sure that this does not help)

--Gennady

0 Kudos
shizhi_l_
Beginner
387 Views

are you speeking china?

0 Kudos
Reply