Hi Marc-André, > 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).
First I wanted to thank you for all the great work on freerdp/xrdp. I think freerdp/xrdp will become the standard for linux desktop remoting in the near future once x11rdp is finalized and integrated into standard distrib. Currently I'm using mainly x2go for linux remoting at work, and tinker with xrdp and tigervnc to look toward the future. TigerVNC is a spinoff from the VirtualGL project (RemoteFX on VNC for linux), and the main developper DRC was historically using the Intel IPP library, but for licencing reason has redevelopped it with great result. I'm wondering if this library could be of some help inside the freerdp/xrdp project? http://libjpeg-turbo.virtualgl.org/ Cheers and keep on the good work! Denis > 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 > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
