mirror of
https://github.com/FreeRDP/FreeRDP.git
synced 2024-11-27 11:54:44 +08:00
.. | ||
test | ||
CMakeLists.txt | ||
prim_add_opt.c | ||
prim_add.c | ||
prim_add.h | ||
prim_alphaComp_opt.c | ||
prim_alphaComp.c | ||
prim_alphaComp.h | ||
prim_andor_opt.c | ||
prim_andor.c | ||
prim_andor.h | ||
prim_colors_opt.c | ||
prim_colors.c | ||
prim_colors.h | ||
prim_copy.c | ||
prim_internal.h | ||
prim_set_opt.c | ||
prim_set.c | ||
prim_set.h | ||
prim_shift_opt.c | ||
prim_shift.c | ||
prim_shift.h | ||
prim_sign_opt.c | ||
prim_sign.c | ||
prim_sign.h | ||
prim_templates.h | ||
primitives.c | ||
README.txt |
The Primitives Library Introduction ------------ The purpose of the primitives library is to give the freerdp code easy access to *run-time* optimization via SIMD operations. When the library is initialized, dynamic checks of processor features are run (such as the support of SSE3 or Neon), and entrypoints are linked to through function pointers to provide the fastest possible operations. All routines offer generic C alternatives as fallbacks. Run-time optimization has the advantage of allowing a single executable to run fast on multiple platforms with different SIMD capabilities. Use In Code ----------- A singleton pointing to a structure containing the function pointers is accessed through primitives_get(). The function pointers can then be used from that structure, e.g. primitives_t *prims = primitives_get(); prims->shiftC_16s(buffer, shifts, buffer, 256); Of course, there is some overhead in calling through the function pointer and setting up the SIMD operations, so it would be counterproductive to call the primitives library for very small operation, e.g. initializing an array of eight values to a constant. The primitives library is intended for larger-scale operations, e.g. arrays of size 64 and larger. Initialization and Cleanup -------------------------- Library initialization is done the first time primitives_init() is called or the first time primitives_get() is used. Cleanup (if any) is done by primitives_deinit(). Intel Integrated Performance Primitives (IPP) --------------------------------------------- If freerdp is compiled with IPP support (-DWITH_IPP=ON), the IPP function calls will be used (where available) to fill the function pointers. Where possible, function names and parameter lists match IPP format so that the IPP functions can be plugged into the function pointers without a wrapper layer. Use of IPP is completely optional, and in many cases the SSE operations in the primitives library itself are faster or similar in performance. Coverage -------- The primitives library is not meant to be comprehensive, offering entrypoints for every operation and operand type. Instead, the coverage is focused on operations known to be performance bottlenecks in the code. For instance, 16-bit signed operations are used widely in the RemoteFX software, so you'll find 16s versions of several operations, but there is no attempt to provide (unused) copies of the same code for 8u, 16u, 32s, etc. New Optimizations ----------------- As the need arises, new optimizations can be added to the library, including NEON, AVX, and perhaps OpenCL or other SIMD implementations. The CPU feature detection is done in winpr/sysinfo. Adding Entrypoints ------------------ As the need for new operations or operands arises, new entrypoints can be added. 1) Function prototypes and pointers are added to include/freerdp/primitives.h 2) New module initialization and cleanup function prototypes are added to prim_internal.h and called in primitives.c (primitives_init() and primitives_deinit()). 3) Operation names and parameter lists should be compatible with the IPP. IPP manuals are available online at software.intel.com. 4) A generic C entrypoint must be available as a fallback. 5) prim_templates.h contains macro-based templates for simple operations, such as applying a single SSE operation to arrays of data. The template functions can frequently be used to extend the operations without writing a lot of new code. Cache Management ---------------- I haven't found a lot of speed improvement by attempting prefetch, and in fact it seems to have a negative impact in some cases. Done correctly perhaps the routines could be further accelerated by proper use of prefetch, fences, etc. Testing ------- In the test subdirectory is an executable (prim_test) that tests both functionality and speed of primitives library operations. Any new modules should be added to that test, following the conventions already established in that directory. The program can be executed on various target hardware to compare generic C, optimized, and IPP performance with various array sizes.