I wasn't thinking of making the code ugly with tons of #ifdefs everywhere. I was thinking of a technique very similar to what is currently used in libfreerdp-codec for RemoteFX optimizations.
Here's the general idea: A data structure containing an array of callbacks to the functions to be optimized is made. The functions to be registered in those callbacks are implemented in separate files. At compile time, headers for the specific optimized functions are included in the part of code dealing with the registration of callbacks. Runtime detection can be performed, but basically the code ends up choosing with set of callbacks to register. https://github.com/FreeRDP/FreeRDP/tree/master/libfreerdp/codec You can find examples of such a technique with rfx.c, rfx_sse2.c and rfx_neon.c. We could add a new file called rfx_ipp.c to add support for intel ipp. If the number of optimization specific files ends up making the file structure ugly we can find a better way of organizing it all, maybe with subdirectories to contain the optimizations. On Fri, Sep 14, 2012 at 8:06 PM, Daryl Poe <daryl....@hp.com> wrote: > > >> However, I would advise against adding an abstraction layer on top of >> Intel IPP, Framewave, OpenMAX and anything in the like. Those libraries are >> already an abstraction layer, and we want to use them in places where >> performance is crucial. I think we are much better off writing >> library-specific versions of different portions of FreeRDP instead of >> attempting to abstract on top of these libraries. Abstraction layers in >> general are mutually exclusive with code that is highly-sensitive to >> performance. >> > > On the other hand, I think we want to prevent the code from turning into > something like this (and I'm just making up the library entry points here > for illustration): > > do stuff > #ifdef WITH_INTEL_IPP > ipp_shift_signed_16(**quantization_value, dwt_coefficients, 1640); > #elif WITH_OPENCL > opencl_signed_shift_16(opencl_**context, dwt_coefficients, 1640, > quantization_value); > #elif WITH_ARM_OPTIMIZED > arm_optimized_shift_16_signed(**dwt_coefficients, quantization_value, > 1640, true); > #else > { int i; sint16 *ptr=dwt_coefficients; for (i=0; i<1640; ++i) > *ptr++ <<= quantization_value; } > #endif > do more stuff > > Or... having multiple high-level versions of various routines with direct > calls, as that's a maintenance and code-reading nightmare. > > It's unlikely that various solutions would share common parameter > ordering, so a function pointer won't work without a shim layer. > > It might be possible to handle it all through a macro: > > #ifdef WITH_INTEL_IPP > # define dataop_shift_sint16(dest, shift, count) > ipp_shift_signed_16(shift, dest, count) > #elif WITH_OPENCL > # define dataop_shift_sint16(dest, shift, count) > opencl_signed_shift_16(opencl_**context, dest, count, shift) > etc > > That would confine the ugliness to the header file and leave the source > code with a clean "dataop_shift_sint16()" call. The macro solution is > inflexible though, as you have to make all the decisions at compile-time > rather than adjusting at execution (e.g. testing what kind of GPU support > you have before plugging in OpenCL entrypoints). > > I guess I don't see a big problem with an abstraction layer because most > of the operations I'm thinking of are large-scale SIMD operations over a > big data block, where the overhead of an additional function is a very > small percentage of the amount of work to be done, rather than a tiny, > quick function in the center of a tight loop, where the overhead would be a > killer. > > > Daryl > > > ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
