simd


Log

Author Commit Date CI Message
DRC d5f281b7 2018-09-28T15:46:35 SIMD: Fix c000001d exception on Win 7 w/o SP1 Apparently Windows 7 without SP1 has O/S support for XSAVE but not for YMM registers, and this exposed a bug in our usage of xgetbv. The test instruction will set ZF only if none of the bits match between the two operarands, so in effect, we were enabling AVX2 instructions if the O/S supported XSAVE and the CPU supported AVX2 but the O/S only supported XMM registers. This bug was not exposed on, for instance, Windows XP or RHEL 5 because those O/S's do not support XSAVE. Fixes #288
Rosen Penev 4f943644 2018-09-04T19:17:58 Enable DSPr2 SIMD extensions if CPU type is mipsel The DSPr2 extensions have been verified to work with little endian MIPS. Whether or not CMAKE_SYSTEM_PROCESSOR is set to "mips" or "mipsel" in a little endian MIPS environment seems to be inconsistent, but our build system needs to handle both cases.
DRC 3bef88f6 2018-09-04T17:33:12 Fix MIPS DSPr2 build when using soft float ABI (for instance, when passing -msoft-float to the compiler) The instructions used by jsimd_quantize_float_dspr2() and jsimd_convsamp_float_dspr2() don't work with the soft float ABI, so disable those functions when soft float is enabled. Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/272/commits/129a739bfabe1568d078eb2719691a76db128185 Closes #272
luzpaz 43c58ff9 2018-07-31T21:59:16 Correct various typos in code comments Found via `codespell -q 3` Closes #263
DRC 6d8caa9f 2018-06-29T12:45:57 Build: Detect whether compiler supports DSPr2 This is basically the same test that was performed in acinclude.m4 in the old autotools-based build system. It was not ported to the CMake-based build system because I previously had no way of testing a non-DSPr2 build environment. Fixes #248
DRC bfc3ce31 2018-04-10T15:50:22 x86[-64] SIMD: Don't auto-generate jsimdcfg.inc The old Un*x (autotools-based) build system always auto-generated this file, but that behavior was more or less a relic of the days before the libjpeg-turbo colorspace extensions were implemented. The thinking was that, if a particular developer wanted to change RGB_RED, RGB_GREEN, RGB_BLUE, or RGB_PIXELSIZE in order to compress from/decompress to different RGB pixel layouts, then the SIMD extensions should automatically respond to those changes whenever they were made to jmorecfg.h. The modern reality is that changing RGB_* is no longer necessary because of the libjpeg-turbo colorspace extensions, and changing any of the other constants in jsimdcfg.inc can't be done without making deeper modifications to the SIMD extensions. In general, we treat RGB_* as a de facto, immutable part of the legacy libpjeg API. Realistically, since the values of those constants have been the same in every Un*x distribution released in the past 20-30 years, any software that uses a system-supplied build of libjpeg must assume that those constants will have default values. Furthermore, even if it made sense to auto-generate jsimdcfg.inc, it was never possible to do so on Windows, so it was always going to be necessary to manually generate the Windows version of the file whenever any of the constants changed. This commit introduces a new custom CMake target called "jsimdcfg" that can be used, on Un*x platforms, to generate jsimdcfg.inc on demand, although this should only be necessary when introducing new x86 SIMD instructions or making other deep modifications, such as SIMD acceleration for 12-bit JPEGs. For those who may be wondering why we don't do the same thing for win/jconfig.h.in, it's because performing all of the necessary CMake checks to populate that file is very slow on Windows.
mayeut 269e84c9 2018-04-10T00:02:57 jsimd_can_encode_mcu_AC_*(): Remove useless checks These were necessary for the first iteration of the feature (see #46), which provided a different C front end for the SIMD version of the function. The final version of the feature uses a common C front end for both SIMD and non-SIMD implementations, so these checks are no longer necessary. Closes #231
DRC b628d693 2018-04-08T12:49:05 Additional code formatting tweaks ... detected with an improved version of our checkstyle script
DRC 58cb10ee 2018-03-31T13:51:31 Eliminate compiler warnings w/ Solaris Studio
DRC 7b3c0f01 2018-03-31T13:25:44 PowerPC: Fix comp. warning when built w/ -maltivec
mayeut 5b177b3c 2018-03-22T11:36:43 C/SSE2 optimization of encode_mcu_AC_first() This commit adds C and SSE2 optimizations for the encode_mcu_AC_first() function used in progressive Huffman encoding. The image used for testing can be retrieved from this page: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz` clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)` gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0` gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0` Here are the results in comparison to libjpeg-turbo@293263c using `time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg` C clang x86_64: +19% gcc-5 x86_64: +80% gcc-7 x86_64: +57% clang i386: +5% gcc-5 i386: +59% gcc-7 i386: +51% SSE2 clang x86_64: +79% gcc-5 x86_64: +158% gcc-7 x86_64: +122% clang i386: +71% gcc-5 i386: +134% gcc-7 i386: +135% Discussion in libjpeg-turbo/libjpeg-turbo#46
mayeut 16bd9845 2018-03-02T22:33:19 C/SSE2 optimization of encode_mcu_AC_refine() This commit adds C and SSE2 optimizations for the encode_mcu_AC_refine() function used in progressive Huffman encoding. The image used for testing can be retrieved from this page: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz` clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)` gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0` gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0` Here are the results in comparison to libjpeg-turbo@3c54642 using `time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg` C clang x86_64: +7% gcc-5 x86_64: +30% gcc-7 x86_64: +33% clang i386: +0% gcc-5 i386: +24% gcc-7 i386: +23% SSE2 clang x86_64: +42% gcc-5 x86_64: +53% gcc-7 x86_64: +64% clang i386: +35% gcc-5 i386: +46% gcc-7 i386: +49% Discussion in libjpeg-turbo/libjpeg-turbo#46
DRC 81baa1b5 2018-03-21T13:03:30 simd/i386/jchuff-sse2.asm: Minor formatting tweak
DRC 293263c3 2018-03-17T15:14:35 Format preprocessor macros more consistently Within the libjpeg API code, it seems to be more the convention than not to separate the macro name and value by two or more spaces, which improves general readability. Making this consistent across all of libjpeg-turbo is less about my individual preferences and more about making it easy to automatically detect variations from our chosen formatting convention. I intend to release the script I'm using to validate this stuff, once it matures and stabilizes a bit.
DRC 84fbd4f1 2018-03-17T00:27:49 Merge branch 'master' into dev
DRC bd96b30b 2018-03-17T00:06:10 Make all get/putenv() calls compile-time optional * Modify the SIMD dispatchers so they guard their usage of getenv() with the existing NO_GETENV preprocessor definition. * Introduce a new NO_PUTENV preprocessor definition to guard the usage of putenv() in the TurboJPEG API library. This at least puts Windows Store compatibility within the realm of possibility, although further steps are required.
DRC 19c791cd 2018-03-08T10:55:20 Improve code formatting consistency With rare exceptions ... - Always separate line continuation characters by one space from preceding code. - Always use two-space indentation. Never use tabs. - Always use K&R-style conditional blocks. - Always surround operators with spaces, except in raw assembly code. - Always put a space after, but not before, a comma. - Never put a space between type casts and variables/function calls. - Never put a space between the function name and the argument list in function declarations and prototypes. - Always surround braces ('{' and '}') with spaces. - Always surround statements (if, for, else, catch, while, do, switch) with spaces. - Always attach pointer symbols ('*' and '**') to the variable or function name. - Always precede pointer symbols ('*' and '**') by a space in type casts. - Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG API libraries (using min() from tjutil.h is still necessary for TJBench.) - Where it makes sense (particularly in the TurboJPEG code), put a blank line after variable declaration blocks. - Always separate statements in one-liners by two spaces. The purpose of this was to ease maintenance on my part and also to make it easier for contributors to figure out how to format patch submissions. This was admittedly confusing (even to me sometimes) when we had 3 or 4 different style conventions in the same source tree. The new convention is more consistent with the formatting of other OSS code bases. This commit corrects deviations from the chosen formatting style in the libjpeg API code and reformats the TurboJPEG API code such that it conforms to the same standard. NOTES: - Although it is no longer necessary for the function name in function declarations to begin in Column 1 (this was historically necessary because of the ansi2knr utility, which allowed libjpeg to be built with non-ANSI compilers), we retain that formatting for the libjpeg code because it improves readability when using libjpeg's function attribute macros (GLOBAL(), etc.) - This reformatting project was accomplished with the help of AStyle and Uncrustify, although neither was completely up to the task, and thus a great deal of manual tweaking was required. Note to developers of code formatting utilities: the libjpeg-turbo code base is an excellent test bed, because AFAICT, it breaks every single one of the utilities that are currently available. - The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been formatted to match the SSE2 code (refer to ff5685d5344273df321eb63a005eaae19d2496e3.) I hadn't intended to bother with this, but the Loongson MMI implementation demonstrated that there is still academic value to the MMX implementation, as an algorithmic model for other 64-bit vector implementations. Thus, it is desirable to improve its readability in the same manner as that of the SSE2 implementation.
DRC 33ce0b5e 2018-03-01T10:38:17 Loongson MMI SIMD extensions Based on: https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8 Closes #158
DRC 35ed3c97 2018-02-28T16:24:03 SIMD: Formatting tweaks + remove unnecessary code + "JSIMD_ARM_NEON" = "JSIMD_NEON" + "JSIMD_MIPS_DSPR2" = "JSIMD_DSPR2" + "*_mips_dspr2" = "*_dspr2" It's obvious that "NEON" refers to Arm and "DSPr2" refers to MIPS, and this naming convention is consistent with the other SIMD extensions.
DRC 3c54642c 2018-02-27T11:36:43 Fix iOS/ARM[-64] build w/ newer versions of CMake Newer versions of CMake (known to be the case with 3.7.x and 3.10.x) fail to add a space between CMAKE_C_FLAGS and CMAKE_ASM_FLAGS, which causes the build to fail when using the official build procedure. Closes #216
DRC 367a8386 2018-02-26T19:41:59 Make SIMD syms private for x86[-64]/Mach-O builds ... if building with YASM. NASM doesn't currently support the necessary directives. Closes #212
DRC 7c2bfdb0 2018-02-26T18:43:40 Merge branch 'master' into dev Closes #214
mayeut 0dd9a2c1 2018-02-24T14:50:56 Fix Win64 ABI conformance when using xmm8-xmm11 Referring to https://docs.microsoft.com/en-US/cpp/build/stack-usage: "All memory beyond the current address of RSP is considered volatile: The OS, or a debugger, may overwrite this memory during a user debug session, or an interrupt handler. Thus, RSP must always be set before attempting to read or write values to a stack frame." Basically, if-- under extremely rare circumstances-- a context swap were to occur between saving the values of xmm8-xmm11 and setting the new value of rsp, the O/S might not preserve that area of the stack. In general, libjpeg-turbo should not be using xmm8-xmm11 before or after the call to jsimd_huff_encode_one_block_sse2(), so this is probably a non-issue, but it's still a good idea to fix it. Based on https://github.com/mayeut/libjpeg-turbo/commit/ff7d2030dd26c7b8c37ff540c594490198843f15
mayeut 4c4dc614 2018-02-24T12:07:34 Fix Win64 ABI conformance issue in AVX2 ISLOW IDCT xmm8-xmm11 must be saved and restored, since the function uses ymm8-ymm11. Closes #211
mayeut feaec37d 2018-02-24T14:20:59 Fix build with YASM vinserti128 requires all operands to be specified
mayeut b6909ab3 2018-02-24T00:02:27 Make SIMD symbols private for MIPS ELF builds Closes #210
mayeut 9bef5df7 2018-02-23T23:31:02 Make SIMD symbols private for iOS ARM/ARM64 builds
mayeut 88421563 2018-02-23T21:56:32 Make SIMD symbols private for x86[-64] ELF builds
DRC 9cdec16c 2018-02-23T13:58:24 32-bit AVX2 implementation of slow int inverse DCT
DRC 845fe8bf 2018-02-23T12:24:10 32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX
DRC de9e9db6 2018-02-23T11:50:11 64-bit AVX2 implementation of slow int inverse DCT
DRC 715b7c38 2018-02-17T22:15:58 32-bit AVX2 implementation of int sample conv.
DRC ca387e7f 2018-02-17T20:31:30 32-bit AVX2 implementation of slow int forward DCT
DRC 39e9e65c 2018-02-17T19:39:53 64-bit AVX2 implementation of int sample conv.
DRC 264dd42a 2018-02-17T17:32:25 64-bit AVX2 implementation of slow int forward DCT
DRC ff392d81 2018-02-17T17:29:38 AVX2: Introduce YMMBLOCK macro for readability
DRC bf6c7743 2017-12-07T19:29:42 Fix whitespace errors
DRC 51cc89fa 2017-09-01T09:02:55 Merge branch 'master' into dev
DRC 1d935416 2017-09-01T13:52:21 Build: Use -maltivec when testing AltiVec support Doesn't seem to be necessary with recent Linux/GCC configurations, but it is definitely necessary with OS X.
DRC c0f3512d 2017-08-31T20:57:19 Merge branch 'master' into dev
DRC e5c1613c 2017-07-07T15:15:19 x86: Fix "short jump is out of range" w/ NASM<2.04
DRC 2ac4e9d9 2017-06-26T21:58:32 Merge branch 'master' into dev
DRC 9d64f3c6 2017-04-24T14:42:58 Attribute ARM runtime detection code to Nokia This code was submitted in the initial ARM NEON patches (https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he was still a Nokia employee.
DRC 8a9b042b 2016-12-10T09:35:30 Merge branch 'master' into dev
DRC 2b29bca2 2016-12-07T18:11:38 Build: Fix Debug/RelWithDebInfo build with YASM YASM requires a debug format to be specified with -g. Currently the only combination that I can make work at all is DWARF-2/ELF (YASM doesn't support Mach-O debugging at all, and its support for CV8/MSVC and MinGW/DWARF-2 appears to be broken), so debugging is only enabled automatically for ELF at the moment. For other formats, we don't specify -g at all, which is how the old build system behaved. Fixes #125, Closes #126
DRC 786b6493 2016-12-05T12:39:49 Reorg AltiVec detection code + advertise that full AltiVec SIMD acceleration is now available on OpenBSD. The relevant compilers probably all support C99 or GNU's variation of C90 that allows variables to be declared anywhere, but our policy is to conform to the C90 standard, if for no other reason than that it improves code readability.
Donovan Watteau f4ba09b3 2016-12-03T15:46:49 Detect AltiVec support on OpenBSD
DRC 952191da 2016-12-03T14:21:11 Build: Fix issues when building as a Git submodule - Replace CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR - Replace CMAKE_BINARY_DIR with CMAKE_CURRENT_BINARY_DIR - Don't use "libjpeg-turbo" in any of the package system filenames (because CMAKE_PROJECT_NAME will not be the same if building LJT as a submodule.) Closes #122
DRC 059c9a5f 2016-12-03T21:17:09 Build: Fix regression in AltiVec SIMD detection Only the SIMD source files should be built with -maltivec. Otherwise the detection code will not be compiled in.
DRC 94686e3c 2016-11-25T18:50:11 Build: Use wrapper script for gas-preprocessor.pl The previous hack (adding ${CMAKE_ASM_COMPILER} to CMAKE_ASM_FLAGS) didn't work in all cases, because more recent versions of CMake place the includes ahead of the flags (which meant that the real assembler wasn't the first argument to gas-preprocessor.pl.)
DRC 6abd3916 2016-11-15T08:47:43 Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
DRC 9fdb8f85 2016-11-22T09:33:19 Merge branch 'master' into dev
Chris Young 4ad94b29 2016-11-18T19:03:28 Detect AltiVec support on AmigaOS 4
DRC 108b1cd9 2016-10-20T01:37:40 Merge branch 'master' into dev
DRC 13e6b151 2016-10-11T11:58:20 Win: Use YASM if it is in the PATH and NASM isn't Previously, simd/CMakeLists.txt was hard-coded to use NASM, and it was necessary to override the NASM variable in order to use YASM. This commit changes the behavior such that NASM is still preferred, but YASM will be used if it is in the PATH and NASM isn't available. This brings the actual behavior in line with the behavior described in BUILDING.md. Based on https://github.com/xpol/libjpeg-turbo/commit/b0799a1598782799d4876538eddca7ad8438d8a6 Closes #107
DRC ed21f4bd 2016-10-05T14:41:14 Merge branch 'master' into dev
DRC f34f2f5b 2016-10-05T13:36:35 Fix 'make dist'
DRC 7bfb22af 2016-09-26T17:59:14 Fix broken MIPS build Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152 Fixes #104
DRC 6c365686 2016-09-20T18:09:15 Merge branch 'master' into dev
mayeut cb88e5da 2016-09-20T21:06:24 ARM64 NEON: Fix another ABI conformance issue Based on https://github.com/mayeut/libjpeg-turbo/commit/98a5a9dc899aa9265858a3cbe0a96289a31a1322 with wordsmithing by DRC. In the AArch64 ABI, as in many others, it's forbidden to read/store data below the stack pointer. Some SIMD functions were doing just that (stack pointer misuse) when trying to preserve callee-saved registers, and this resulted in those registers being restored with incorrect contents under certain circumstances. This patch fixes that behavior, and callee-saved registers are now stored above the stack pointer throughout the function call. The patch also removes register saving in places where it is unnecessary for this ABI, or it makes use of unused scratch regiters instead of callee-saved registers. Fixes #97. Closes #101. Refer also to https://bugzilla.redhat.com/show_bug.cgi?id=1368569
DRC 3924ebce 2016-07-13T16:03:36 AVX2: Perform additional checks for O/S support cpuid tells us whether the O/S uses extended state management via XSAVE/XRSTOR, but we have to call xgetbv to verify that it is using XSAVE/XRSTOR to manage the state of XMM/YMM registers.
DRC 1120ff29 2016-07-13T12:15:02 Fix AArch64 ABI conformance issue in SIMD code In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's register is undefined, so it was incorrect to use 64-bit instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD functions. The code worked thus far only because the existing compiler optimizers weren't smart enough to do anything else with the register in question, so the upper 32 bits happened to be all zeroes. The latest builds of Clang/LLVM have a smarter optimizer, and under certain circumstances, it will attempt to load-combine adjacent 32-bit integers from one of the libjpeg structures into a single 64-bit integer and pass that 64-bit integer as a 32-bit argument to one of the SIMD functions (which is allowed by the ABI, since the upper 32 bits of the 32-bit argument's register are undefined.) This caused the libjpeg-turbo regression tests to crash. This patch tries to use the Wn registers whenever possible. Otherwise, it uses a zero-extend instruction to avoid using the upper 32 bits of the 64-bit registers, which are not guaranteed to be valid for 32-bit arguments. Based on https://github.com/sebpop/libjpeg-turbo/commit/1fbae13021eb98f6fffdfaf8678fcdb00b0b04d9 Closes #91. Refer also to android-ndk/ndk#110 and https://llvm.org/bugs/show_bug.cgi?id=28393
DRC 3dcb85ee 2016-07-11T20:21:46 AVX2: Verify O/S support for AVX2 before enabling This fixes crashes that would occur when attempting to use libjpeg-turbo's AVX2 extensions on older O/S's (such as Windows XP or RHEL 5.) Even if the CPU supports AVX2, the O/S has to also support saving/restoring YMM registers when switching contexts.
DRC 1be87b62 2016-07-11T19:42:37 Reformat jsimdcpu[-64].asm to improve readability
DRC b331385e 2016-07-11T13:11:25 Merge branch 'master' into dev
DRC b2921f1b 2016-07-08T21:28:48 32-bit AVX2 implementation of integer quantization
DRC eaae2cdb 2016-07-08T13:56:30 64-bit AVX2 implementation of integer quantization
DRC a7c2f979 2016-07-08T20:10:24 AVX2: Avoid expensive AVX-SSE transitions Refer to https://software.intel.com/sites/default/files/m/d/4/1/d/8/11MC12_Avoiding_2BAVX-SSE_2BTransition_2BPenalties_2Brh_2Bfinal.pdf for more information. This eliminates all AVX-SSE transitions detected with the Intel SDE tool.
DRC e06ccbe3 2016-07-08T13:00:13 64-bit AVX2: Fix bug in IS_ALIGNED_AVX() macro 32 = 1 << 5, not 1 << 8
DRC 67de29b5 2016-07-07T22:04:25 32-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
DRC c22e42e9 2016-07-07T20:36:15 Optimize 64-bit AVX2 h2v2 fancy upsampler Reduce register usage and eliminate unnecessary mov instructions
DRC 6d765524 2016-07-07T20:34:08 32-bit AVX2 impl. of h2v2 & h2v1 upsampling (Fancy & Plain)
DRC 421d34fd 2016-07-05T17:20:20 32-bit AVX2 impl. of YCC->RGB color conversion
DRC c6300ffe 2016-07-05T15:50:50 32-bit AVX2 impl. of h2v2 & h2v1 downsampling
DRC 6448a5e5 2016-07-05T16:21:10 32-bit AVX2 impl. of RGB->YCC/RGB->Gray color conv
DRC 6e9d43e0 2016-07-06T16:58:28 Linux/PPC: Only enable AltiVec if CPU supports it This eliminates "illegal instruction" errors when running libjpeg-turbo under Linux on PowerPC chips that lack AltiVec support (e.g. the old 7XX/G3 models but also the newer e5500 series.)
DRC 9055fb40 2016-07-07T13:10:30 ARM/MIPS: Change the behavior of JSIMD_FORCE* The JSIMD_FORCE* environment variables previously meant "force the use of this instruction set if it is available but others are available as well", but that did nothing on ARM platforms, since there is only ever one instruction set available. Since the ARM and MIPS CPU feature detection code is less than bulletproof, and since there is only one SIMD instruction set (currently) supported on those platforms, it makes sense for the JSIMD_FORCE* environment variables on those platforms to actually force the use of the SIMD instruction set, thus bypassing the CPU feature detection code. This addresses a concern raised in #88 whereby parsing /proc/cpuinfo didn't work within a QEMU environment. This at least provides a workaround, allowing users to force-enable or force-disable SIMD instructions for ARM and MIPS builds of libjpeg-turbo.
DRC 7ee3ce9a 2016-07-05T16:19:26 Lay the groundwork for 32-bit AVX2 SIMD support
DRC b5426c52 2016-06-10T16:03:49 64-bit AVX2 SIMD: Restore instructive comments This commit adds back instructive comments in the image-space algorithms, similar to those in the SSE2 code. These comments make it easier to follow the flow of data through the algorithms.
DRC 621b29f5 2016-05-31T15:19:53 64-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
DRC f1cbc328 2016-05-29T08:09:27 64-bit AVX2 impl. of h2v2 & h2v1 upsampling (Fancy & Plain)
DRC 72c837da 2016-05-29T06:54:56 64-bit AVX2 impl. of YCC->RGB color conversion
DRC 1c8a475c 2016-05-28T19:53:44 64-bit AVX2 impl. of h2v2 & h2v1 downsampling
DRC 8880e087 2016-05-28T19:15:18 64-bit AVX2 impl. of RGB->Gray color conversion
DRC 426d787c 2016-05-28T16:42:44 64-bit AVX2 impl. of RGB->YCC color conversion
DRC 2cf199cb 2016-05-20T10:45:32 Lay the groundwork for 64-bit AVX2 SIMD support
DRC 16b12189 2016-05-29T10:51:16 x86-64 SIMD: Optimize argument collection Expand collect_args/uncollect_args macros so that the number of arguments can be specified. This prevents unnecessary push and mov instructions. NOTE: On Windows, the push/pop of xmm6 and xmm7 had to be moved to the other end of the macro to ensure that rsp is aligned on a 16-byte boundary.
DRC ff5685d5 2016-05-27T16:58:23 Reformat SSE/SSE2 SIMD code to improve readability
DRC 123f7258 2016-05-24T10:23:56 Format copyright headers more consistently The IJG convention is to format copyright notices as: Copyright (C) YYYY, Owner. We try to maintain this convention for any code that is part of the libjpeg API library (with the exception of preserving the copyright notices from Cendio's code verbatim, since those predate libjpeg-turbo.) Note that the phrase "All Rights Reserved" is no longer necessary, since all Buenos Aires Convention signatories signed onto the Berne Convention in 2000. However, our convention is to retain this phrase for any files that have a self-contained copyright header but to leave it off of any files that refer to another file for conditions of distribution and use. For instance, all of the non-SIMD files in the libjpeg API library refer to README.ijg, and the copyright message in that file contains "All Rights Reserved", so it is unnecessary to add it to the individual files. The TurboJPEG code retains my preferred formatting convention for copyright notices, which is based on that of VirtualGL (where the TurboJPEG API originated.)
mattsarett 2e480fa2 2016-05-03T10:33:43 ARMv7 SIMD: Fix clang compatibility (Part 2) GCC does support UAL syntax (strbeq) if the ".syntax unified" directive is supplied. This directive is supported by all versions of GCC and clang going back to 2003, so it should not create any backward compatibility issues. Based on https://github.com/mattsarett/libjpeg-turbo/commit/1264349e2fa6f098178c37abfa7b059ad8b405a2 Closes #76
mattsarett 5e576386 2016-05-02T12:31:51 ARMv7 SIMD: Fix clang compatibility By design, clang only supports Unified Assembler Language (and not pre-UAL syntax): https://llvm.org/bugs/show_bug.cgi?id=23507 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html Thus, clang only supports the strbeq instruction and not streqb, but unfortunately some versions of GCC only support streqb. Go, go Gadget #ifdef... Based on https://github.com/mattsarett/libjpeg-turbo/commit/a82e63aac63f8fa3 95fa4caad4de6859623ee2e2 Closes #75
DRC 056536f6 2016-02-29T17:21:02 Win/x64: Fix improper callee save of xmm8-xmm11 The x86-64 SIMD accelerations for Huffman encoding used incorrect stack math to save xmm8-xmm11 on Windows. This caused TJBench to always report 1 Mpixel/sec for the compression performance, and it likely would have caused other application issues as well.
DRC bd49803f 2016-02-19T08:53:33 Use consistent/modern code formatting for pointers The convention used by libjpeg: type * variable; is not very common anymore, because it looks too much like multiplication. Some (particularly C++ programmers) prefer to tuck the pointer symbol against the type: type* variable; to emphasize that a pointer to a type is effectively a new type. However, this can also be confusing, since defining multiple variables on the same line would not work properly: type* variable1, variable2; /* Only variable1 is actually a pointer. */ This commit reformats the entirety of the libjpeg-turbo code base so that it uses the same code formatting convention for pointers that the TurboJPEG API code uses: type *variable1, *variable2; This seems to be the most common convention among C programmers, and it is the convention used by other codec libraries, such as libpng and libtiff.
DRC 8632f1b2 2016-02-09T00:38:58 ARM64: Avoid tbl instruction on Cortex-A53/A57 Full-color compression speedups relative to previous commits: Cortex-A53 (Nexus 5X), Android, 64-bit: 0.91-3.0% (avg. 1.8%) Cortex-A57 (Nexus 5X), Android, 64-bit: -0.35-1.5% (avg. 0.65%)
DRC 28f00bf2 2016-02-08T15:15:11 Fix iOS/ARMv8 build Broken by 46ecffa324be43aab80f6160dc57d98b0a54a704. gas-preprocessor.pl and/or the clang assembler apparently don't like default values in macro arguments, and we need to use a separate const section for each function (because of our use of adr, also necessitated by the broken clang assembler.)
DRC 53c635b8 2016-02-08T14:03:13 Fix 'make dist'; Include LICENSE.md in packages
DRC 46ecffa3 2016-02-07T22:05:56 ARM64: Avoid LD3/ST3 at run time, not compile time ... and only if ThunderX is detected. This can be easily expanded later on to include other CPUs that are known to suffer from slow LD3/ST3, but it doesn't make sense to disable LD3/ST3 for all non-Android Linux platforms just because ThunderX is slow.
DRC 219470d6 2016-02-07T20:36:02 ARM64 NEON SIMD implementation of Huffman encoding Full-color compression speedups relative to previous commits: Cortex-A53 (Nexus 5X), Android, 64-bit: 1.1-13% (avg. 6.0%) Cortex-A57 (Nexus 5X), Android, 64-bit: 0.0-22% (avg. 6.3%) Refer to #47 and #50 for discussion Closes #50 Note that this commit introduces a similar /proc/cpuinfo parser to that of the ARM32 implementation. It is used to specifically check whether the code is running on Cavium ThunderX and, if so, disable the ARM64 SIMD Huffman routines (which slow performance by an average of 8% on that CPU.) Based on: https://github.com/mayeut/libjpeg-turbo/commit/a8c282e5e5ac10a715d6d6a9ab22121982b485f6
DRC 15aaa7f7 2016-02-07T17:39:33 ARM SIMD: Comment tweaks
DRC cf888486 2016-02-02T23:17:06 Use consistent formatting in ARM NEON SIMD code There aren't really any best practices to follow here. I tried as best as I could to adopt a standard that would ease any future maintenance burdens. The basic tenets of that standard are: * Assembly instructions always start on Column 5, and operands always start on Column 21, except: - The instruction and operand can be indented (usually by 2 spaces) to indicate a separate instruction stream. - If the instruction is within an enclosing .if block in a macro, it should always be indented relative to the .if block. * Comments are placed with an eye toward readability. There are always at least 2 spaces between the end of a line of code and the associated in-line comment. Where it made sense, I tried to line up the comments in blocks, and some were shifted right to avoid overlap with neighboring instruction lines. Not an exact science. * Assembler directives and macros use 2-space indenting rules. .if blocks are indented relative to the macro, and code within the .if blocks is indented relative to the .if directive. * No extraneous spaces between operands. Lining up the operands vertically did not really improve readability-- personally, I think it made it worse, since my eye would tend to lose its place in the uniform columns of characters. Also, code with a lot of vertical alignment is really hard to maintain, since changing one line could necessitate changing a bunch of other lines to avoid spoiling the alignment. * No extraneous spaces in #defines or other directives. In general, the only extraneous spaces (other than indenting spaces) are between: - Instructions and operands - Operands and in-line comments This standard should be more or less in keeping with other formatting standards used within the project.