Just a few comments on the intel development tools: Those who were at the dinner we had to discuss FreeRDP development have probably noticed my excitement for the intel development tools. There is definitely something to be extremely excited about, it does everything, from finely grained profiling of your code with minimal footprint to pointing out where your race conditions are.
The full development suite is quite expensive but definitely worth it: http://software.intel.com/en-us/intel-parallel-studio-xe The Intel IPP libraries are available as stand-alone for $200: http://software.intel.com/en-us/intel-integrated-performance-primitives-purchase/ No matter what, I'm getting a license, and when we eventually set up automated build infrastructure we will have the option of providing high-quality FreeRDP builds that make use of intel IPP. The libraries are usable on Windows, Linux and Mac OS X. We can also provide other such special builds that can make use of all sorts of libraries with an obvious advantage. On Fri, Sep 14, 2012 at 6:47 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > 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
