IPP and modern C++ techniques

[adi_shavit]

Hi,

I have asked this question at the Intel Premier site a few years ago (when IPP just came out), and I think it is time to ask it again. In my discussion I mainly refer to the image processing part of IPP though the general idea extends to other part as well.

Today more and more compilers are beginning to support advanced C++ template techniques (a.k.a. template meta-programming, a-la Alexandrescu). IPP is beautifully made, as if tailored, to be wrapped with such C++ wrappers.
The compile-time function dispatch and type constructions fit well with the no-overhead policy of IPP (as opposed to IPL, for example).
Even the IPP function names are semantically identical to template syntax (replace some underscores with commas and angle brackets).

Has anyone considered adding C++ wrappers to IPP[i/s]? This IppImage will be types at compile time and e.g. ippi_copy() will automatically call the correct optimized copy version.

I have seen a first attempt to do this in one of the last issues of C/C++ Users Journal. Though I think some of the details should be done differently, and a more general wrapper is needed, I believe that is the basic way to go.

I have in the past written an Ipl2Ipp wrapper that help interface IPP functions with IPL images without having to calculate all the offsets in-place every time. Especially when IPL images might have ROIs and may not.

However, a more general IppImage would be an even better option since the IPP function names would be grouped under one inline template function where the correct function flavor is chosen automatically by the compiler at compile-time.

This will help maintain the code, as the chance of calling the wrong flavor will be reduced. Calling an unsupported function will result in a compile-time error instead of a run-time error now, or worst, no run-time error.
A change to the image pixel depth at the instantiation point would require a recompile without having to go to all the code and manually change the IPP functions.

The difficulty in doing this external to the Intel library, is that this library will have to change and be extended for every new version of IPP. The many functions (over 1000) must be grouped and tested in the new header files.

Your comments, please,
Adi

[Ying_S_Intel]

Hi

Have you noticed that the latest version of Intel IPP 4.0 has provided a sample to demonstrate how to use the Intel IPP libraries in the C++ applications. Intel IPP functions can be overloaded in C++ interface, and on the base of these overloads special classes can be created to provide easy access to the huge variety of the signal and image processing as well as string manipulation functions. As the example we demonstrate how to create a C++ application that performs simple testing of the functionality of the infinite impulse response (IIR) filters created with the Intel IPP functions for signal processing. The Intel IPP library supports two basic types of the IIR filters - arbitrary order filters and biquad sections filters.

To get this sample, you can download it from Intel Premier Support.

Thanks,

Ying
Intel IPP Support

[Intel_C_Intel]

Hi Adi, I know what you mean and I would like to have some template wrappers to connect with the proper ipp functions also.

At the moment, I use Ipp with a bunch of derived classes for Ipp8uC1, Ipp32fC1, Ipp8uRGB,and so on. These are derived from a GenericImage class that handles for me all the strides, ROI's, common asserts, etc. It's really useful and similar to the examples provided by Intel.

I am not happy with that class-oriented solution because the code is mostly the same, but with different functions being called, what makes difficult to implement anything but the most simple functions on the base class. Many times I have to copy-and-paste and just change one argument or one function name...

I couldn't find the CUJ article you mentioned. I started with a TemplateImage class parametrized by the image data type and the number of channels. Specializations would then connect the genericfunction callersto the specific ipp implementation.Doing this specializations can be quite boring, because what actually changes is just a function name, so I used the preprocessor a lot, with string manipulation to assemble the function names and declare the specialization like that

#define ADD(ipptype, numchannels) -> some ugly defines here with many lines and lots of ## ...

and then:

ADD(8u,C1) //equivalent tospecialization that calls ippAdd_8u_C1()

ADD(8u,C3)

... lots of specializations ...

ADD(16s,C1)

and so on.

if an specific type does not have that function, we send the compiler to the generic implementation that calls an assertion to indicate that you are using operations not supported by your image type/channel

Just from the start I had the need to have partially specialized templateclasses, because the interface for three channel images would be slightly different from one channel. But partially specialization on classes is not supported by most compilers yet (i.e. VC2003).I am not completely proficient with templates classesyet, but it seems to me that once you start you end up being obliged to use the hardcore stuff to bypass these problems.

But I'll try to find the article you mentioned to get some ideas.

Regards, Juliano

Message Edited by juliano.camargo@haptica.com on 02-19-2004 08:18 AM

Message Edited by juliano.camargo@haptica.com on 02-19-2004 08:20 AM

[borix]

Adi, I believe special IPP sample dedicated to the use IPP in C++ will help you. The example (IPP sample) contains hpp headers files for several IPP domains, for example, Signal Processing domain, where you will find overloaded functions. They have the same name for all data types supported, for instance, ippsMove for Ipp8u ...Ipp64f. Also you will find there templates for IIR filters (as an example), and at last a simple application which uses the templates and overloaded functions, in a way like this

CIirAR Iir64f_32f( Order, dTaps );

// 64f taps and 32f data

Iir64f_32f.Filter( sInp, sOut_dTaps, BufLen )

Does it help?

Boris

[adi_shavit]

Hi Juliano,

Using the CPP (C pre-processor) was a good idea, I hadn't thought of that.
The CUJ site doesn't have the latest issue TOC online, for some reason. It was in one of the last issues, perhaps Dec. 2003. I'll look it up.

The way I see it, the process can be done in 2 stages.

First, make a template function for each IPP function family with the same arguments. These will still receive the same bare-pointer argunments, though the data-type would be know to the compiler at runtime. As you know, this is basically like replacing the function name with actual template parameters.
To perform this task, we can use your approach with the CPP to generate the function names and prototypes.

The second step would be to make a (single) template image class that uses template arguments for such things as depth and #channels. This would be the compile-time equivalent of the IPL struct IplImage. Say we call it IppImage.

To make using the functions of step 1 easier, we can make another set of wrappers that accept IppImages and automatically forward the correct pointers (of the correct data type), structs (e.g. sizes), and other data (stepWidths).

Naturally, all of the above is done using inlined functions that do not generate any overheads at runtime and still keep the same optimized performance.

Along the way we can add proper error handling (if required) and other goodies.

I'd love to see what you did, we may just get somewhere with this.

Regards,
Adi

[Intel_C_Intel]

Thanks to Borix, I've found that most stuff is already done inw_ipp-C++_p_4.0.005.zip file. That's certainly the same one YSong had in mind. It's a very comprehensive collection of overloaded function wrappers for ippi and ipps, it will help us alot. It'spossible to go straight to the template image class implementation.

thanks for the suggestions,

Juliano

[adi_shavit]

Yes! You're right. I missed that one too.
Thanks YSong and Boris.

I'll check it out. It look like just what we need.

Thanks,

Adi