>
> 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
