Hi, To put this back into context, I was at the Microsoft RemoteFX Plug-Fest this week, and I've suggested to the others present at the event the idea of supporting optimization libraries, either commercial or open source, as part of FreeRDP. There are potentially huge performance gains to be made.
I have strongly suggested adding support for the Intel Integrated Performance Primitives (IPP). I've been looking at the manuals documenting the API offered by the set of libraries, and there is a LOT that can be directly applied to optimized and non-optimized portions of FreeRDP: http://software.intel.com/en-us/intel-ipp Writing SSE code by hand is good, but it is time consuming and hard to get right. Also, we are currently using SSE2, and not taking advantage of SSE3 or SSE4. The intel performance primitives offer general purpose functions that will take full advantage of any intel CPU feature available. Support for IPP would be made optional, but it is definitely a small investment for a high return for those who want to use it. The API has it all, there's everything needed for color conversion, RemoteFX, NSCodec, compression, you name it. All we need to do is ensure proper memory alignment and add optional build support for methods that would call the Intel IPP API instead of an equivalent unoptimized function. It's no big deal to simply call that API and we still gain a lot. I've looked at other libraries available. For AMD, there's the framewave project. I think OpenMAX would also be worth looking at. 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. Cheers, - Marc-Andre On Fri, Sep 14, 2012 at 6:18 PM, Daryl Poe <daryl....@hp.com> wrote: > [My apologies if anyone gets this twice...the original one looks to me > to have fallen into the bit-bucket.] > > Hi, > > Taking off from something Marc-André mentioned recently, I'd like to > propose a new set of utilities that the whole freerdp codebase can make > use of to accelerate basic operations over arrays of data, whether it is > copies, shifts, adds, initialization, etc. > > At this point I'm just thinking of defining the interface level and > implementing the basics in C. As time goes on, all of the operations > can be optimized, using such strategies as pulling in SSE or NEON > optimized code; threads; external optimized libraries such as Intel > Integrated Performance Primitives, liborc, parallel patterns library, > OpenMax DL; or even GPU-optimizations via OpenCL. But those details > should be invisible to the general freerdp programmer who just wants to > say, "do this operation as fast as possible" and not worry about the > details. > > To keep the namespace simple, the calls would all take the form: > > > dataop_<operation>_<dest_data_type>[_<op_data_type1>][_<op_data_type2>]...[_<details>] > > where the data types are standard freerdp data types such as sint16 and > uint32, puint8 for a pointer to an array of uint8 values, or something > else relevant. > > Thus, as examples... > > * dataop_copy_ptr_ptr(dst, src, count) does the same thing as memcpy. > * dataop_set_puint8(dst, val, count) does the same thing as memset > * dataop_set_puint32(dst, val, count) sets a block of data to a uint32 > value > * dataop_blend_puint32_puint32_bgra(dst, src, count) does alpha > blending of the source into the destination. > * dataop_shift_psint16(dst, shifts, count) does a shift of the "count" > signed 16-bit values in dst, left if positive, right if negative. > * dataop_add_psint8_psint8(dst, src, count) adds one array of sint8 > values to another. > * dataop_rectcopy_puint32_puint32(dst, src, dstrect, srcpt, dstwidth, > srcwidth) copies a block of 32-bit pixels from one buffer to > another, or from one spot in a single buffer to another > * etc. > > All of the functions should be written to be thread-safe. I'm open to a > different prefix than "dataop_". > > I thought of passing a dataop_context parameter around that could > (privately) contain state data about the operations, e.g. function > pointers and such, but it's hard to get at a single data field from all > parts of the code, so I think it's better just to have the dataop > functions keep any state they need as a static internal variable > available only to the dataop functions. > > * dataop_init() would be a new call, exercised early in freerdp > startup, that would let the dataop code do whatever initialization > it deemed necessary. This might be nothing at first, but eventually > it might do things like test levels of SSE support and dynamically > pick which optimized routine to hook up to calls, test for GPU > support, initialize external library calls etc. It might even > dynamically benchmark a couple operations to pick between methods. > * dataop_cleanup() would let the dataop functions clean up any memory > they had allocated or shut things down cleanly. > > At this point, the goal isn't to come up with the fastest possible > implementation of the functions, but rather to make them available so > they can start to be used in new and rewritten code. The actual > optimization of the functions can happen in parallel and independently. > > I'd also like to add a unit test function that you could run on any > system and get speed measurements for all of the functions. > > Comments? > > Daryl > > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Freerdp-devel mailing list > Freerdp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freerdp-devel > ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
