kc3-lang/libjpeg-turbo/simd

simd

Log

Author Commit Date CI Message
Jonathan Wright e4ec23d7 2021-02-10T16:45:50 Neon: Use byte-swap builtins instead of inline asm Define compiler-independent byte-swap macros and use them instead of executing 'rev' via inline assembly code with GCC-compatible compilers or a slow shift-store sequence with Visual C++. * This produces identical assembly code with: - 64-bit GCC 8.4.0 (Linux) - 64-bit GCC 9.3.0 (Linux) - 64-bit Clang 10.0.0 (Linux) - 64-bit Clang 10.0.0 (MinGW) - 64-bit Clang 12.0.0 (Xcode 12.2, macOS) - 64-bit Clang 12.0.0 (Xcode 12.2, iOS) * This produces different assembly code with: - 64-bit GCC 4.9.1 (Linux) - 32-bit GCC 4.8.2 (Linux) - 32-bit GCC 8.4.0 (Linux) - 32-bit GCC 9.3.0 (Linux) Since the intrinsics implementation of Huffman encoding is not used by default with these compilers, this is not a concern. - 32-bit Clang 10.0.0 (Linux) Verified performance neutrality Closes #507
DRC e795afc3 2021-03-25T22:36:15 SSE2: Fix prog Huff enc err if Sl%32==0 && Al!=0 (regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8) This implements the same fix for jsimd_encode_mcu_AC_refine_prepare_sse2() that a81a8c137b3f1c65082aa61f236aa88af61b3ad4 implemented for jsimd_encode_mcu_AC_first_prepare_sse2(). Based on: https://github.com/MegaByte/libjpeg-turbo/commit/1a59587397150c9ef9dffc5813cb3891db4bc0c8 https://github.com/MegaByte/libjpeg-turbo/commit/eb176a91d87a470bf8c987be786668aa944dd1dd Fixes #509 Closes #510
Adrian Bunk 2c01200c 2021-03-15T19:56:53 Build: Fix incorrect regexes w/ if(...MATCHES...) "arm*" as a regex means 'ar' followed by zero or more 'm' characters, which matches 'parisc' and 'sparc64' as well.
Richard Townsend 74e6ea45 2021-01-05T20:23:11 Neon: Fix Huffman enc. error w/Visual Studio+Clang The GNU builtin function __builtin_clzl() accepts an unsigned long argument, which is 8 bytes wide on LP64 systems (most Un*x systems, including Mac) but 4 bytes wide on LLP64 systems (Windows.) This caused the Neon intrinsics implementation of Huffman encoding to produce mathematically incorrect results when compiled using Visual Studio with Clang. This commit changes all invocations of __builtin_clzl() in the Neon SIMD extensions to __builtin_clzll(), which accepts an unsigned long long argument that is guaranteed to be 8 bytes wide on all systems. Fixes #480 Closes #490
Jonathan Wright eb14189c 2020-11-17T12:48:49 Fix Neon SIMD build issues with Visual Studio - Use the _M_ARM and _M_ARM64 macros provided by Visual Studio for compile-time detection of Arm builds, since __arm__ and __aarch64__ are only present in GNU-compatible compilers. - Neon/intrinsics: Use the _CountLeadingZeros() and _CountLeadingZeros64() intrinsics provided by Visual Studio, since __builtin_clz() and __builtin_clzl() are only present in GNU-compatible compilers. - Neon/intrinsics: Since Visual Studio does not support static vector initialization, replace static initialization of Neon vectors with the appropriate intrinsics. Compared to the static initialization approach, this produces identical assembly code with both GCC and Clang. - Neon/intrinsics: Since Visual Studio does not support inline assembly code, provide alternative code paths for Visual Studio whenever inline assembly is used. - Build: Set FLOATTEST appropriately for AArch64 Visual Studio builds (Visual Studio does not emit fused multiply-add [FMA] instructions by default for such builds.) - Neon/intrinsics: Move temporary buffer allocation outside of nested loops. Since Visual Studio configures Arm builds with a relatively small amount of stack memory, attempting to allocate those buffers within the inner loops caused a stack overflow. Closes #461 Closes #475
DRC 33859880 2020-11-13T12:12:47 Neon: Auto-detect compiler intrinsics completeness This allows the Neon intrinsics code to be built successfully (albeit likely with reduced run-time performance) with Xcode 5.0-6.2 (iOS/AArch64) and Android NDK < r19 (AArch32). Note that Xcode 5.0-6.2 will not build the Armv8 GAS code without gas-preprocessor.pl, and no version of Xcode will build the Armv7 GAS code without gas-preprocessor.pl, so we always use the full Neon intrinsics implementation by default with macOS and iOS builds. Auto-detecting the completeness of the compiler's set of Neon intrinsics also allows us to more intelligently set the default value of NEON_INTRINSICS, based on the values of HAVE_VLD1*. This is a reasonable, albeit imperfect, proxy for whether a compiler has a full and optimal set of Neon intrinsics. Specific notes: - 64-bit RGB-to-YCbCr color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer forward DCT uses vld1_s16_x3(), regresses with GCC - 64-bit Huffman encoding uses vld1q_u8_x4(), regresses with GCC - 64-bit YCbCr-to-RGB color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 64-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. - 32-bit RGB-to-YCbCr color conversion: uses vld1_u16_x2(), regresses with GCC - 32-bit accurate integer forward DCT uses vld1_s16_x3(), regression irrelevant because there was no previous implementation - 32-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 32-bit fast integer inverse DCT does not use any of the intrinsics in question, regresses with GCC - 32-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. Presumably when GCC includes a full and optimal set of Neon intrinsics, the HAVE_VLD1* tests will pass, and the full Neon intrinsics implementation will be enabled automatically.
DRC bbd80892 2020-11-10T17:54:14 Neon: Finalize intrinsics implementation - Remove gas-preprocessor.pl. None of the compilers that can build the new intrinsics implementation require gas-preprocessor.pl (tested with Xcode and with Clang 3.9+ for Linux.) - Document that Xcode 6.3.x or later is now required for iOS builds (older versions of Xcode do not have a full set of Neon intrinsics.) - Add a change log entry. - Do not enable the ASM CMake language unless NEON_INTRINSICS is false. - Add a Clang/Arm64 test to .travis.yml in order to test the new intrinsics implementation. Closes #455
Jonathan Wright d0004de5 2018-08-22T13:38:37 Neon: Intrinsics impl. of accurate int forward DCT The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. There was no previous AArch32 GAS implementation.
Jonathan Wright 3d84668d 2018-08-23T14:22:23 Neon: Intrinsics impl. of fast integer forward DCT The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 951d3677 2018-08-24T18:04:21 Neon: Intrinsics impl. of int sample conv./quant. The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 366168aa 2018-08-06T15:14:34 Neon: Intrinsics impl. of h2v1 & h2v2 downsampling The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.
Jonathan Wright f73b1dbc 2018-08-09T15:08:21 Neon: Intrinsics implementation of RGB->Grayscale There was no previous GAS implementation.
Martyn Jacques 141f26ff 2018-09-18T18:28:31 Neon: Intrinsics impl. of 2x2 and 4x4 scaled IDCTs The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementations provide the same or better performance.
Jonathan Wright 4574f01f 2018-06-28T16:17:36 Neon: Intrinsics impl. of h2v1 & h2v2 plain upsamp There was no previous GAS implementation. NOTE: This doesn't produce much of a speedup when using -O3, because -O3 already enables Neon autovectorization, which works well for the scalar C implementation of plain upsampling. However, the Neon SIMD implementation will benefit other optimization levels.
Jonathan Wright ba52a3de 2018-07-19T18:46:24 Neon: Intrinsics impl of h2v1 & h2v2 merged upsamp There was no previous GAS implementation. This commit also reverts 40557b23015d2f8b576420231b8dd1f39f2ceed8 and 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57. 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57 was only necessary because there was no Neon implementation of merged upsampling/color conversion, and 40557b23015d2f8b576420231b8dd1f39f2ceed8 was only necessary because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57.
Jonathan Wright 240ba417 2020-01-07T16:40:32 Neon: Intrinsics impl. of prog. Huffman encoding The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.
Jonathan Wright ed581cd9 2019-06-12T18:16:53 Neon: Intrinsics impl. of accurate int inverse DCT The previous AArch32 and AArch64 GAS implementations are retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable.
Jonathan Wright 2c6b68e2 2018-09-25T18:20:25 Neon: Intrinsics impl. of fast integer Inverse DCT The previous AArch32 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 2acfb93c 2019-05-08T15:43:26 Neon: Intrinsics impl. of h1v2 fancy upsamling There was no previous GAS implementation.
Jonathan Wright 97530777 2018-06-15T11:13:52 Neon: Intrinsics impl. of h2v1 & h2v2 fancy upsamp The previous AArch32 GAS implementation of h2v1 fancy upsampling has been removed, since the intrinsics implementation provides the same or better performance. There was no previous GAS implementation of h2v2 fancy upsampling, and there was no previous AArch64 GAS implementation of h2v1 fancy upsampling.
Jonathan Wright 5dbd3932 2018-08-01T16:52:31 Neon: Intrinsics implementation of YCbCr->RGB565 The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 0f35cd68 2018-07-16T10:25:14 Neon: Intrinsics implementation of YCbCr->RGB The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright f3c3f01d 2018-09-24T04:35:20 Neon: Intrinsics impl. of Huffman encoding The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 4f2216b4 2019-11-26T18:14:33 Neon: Intrinsics implementation of RGB->YCbCr The previous AArch32 and AArch64 GAS implementations are retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using a new NEON_INTRINSICS CMake variable.
DRC 7c1a1789 2020-11-05T16:04:55 Merge branch 'master' into dev
DRC 6e632af9 2020-11-04T10:13:06 Demote "fast" [I]DCT algorithms to legacy status - Refer to the "slow" [I]DCT algorithms as "accurate" instead, since they are not slow under libjpeg-turbo. - Adjust documentation claims to reflect the fact that the "slow" and "fast" algorithms produce about the same performance on AVX2-equipped CPUs (because of the dual-lane nature of AVX2, it was not possible to accelerate the "fast" algorithm beyond what was achievable with SSE2.) Also adjust the claims to reflect the fact that the "fast" algorithm tends to be ~5-15% faster than the "slow" algorithm on non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo SIMD extensions. - Indicate the legacy status of the "fast" and float algorithms in the documentation and cjpeg/djpeg usage info. - Remove obsolete paragraph in the djpeg man page that suggested that the float algorithm could be faster than the "fast" algorithm on some CPUs.
DRC cd342acf 2020-10-27T16:42:14 Merge branch 'master' into dev
DRC d27b935a 2020-10-27T15:04:39 Consistify formatting to simplify checkstyle The checkstyle script was hastily developed prior to libjpeg-turbo 2.0 beta1, so it has a lot of exceptions and is thus prone to false negatives. This commit eliminates some of those exceptions.
DRC 59352195 2020-10-19T21:17:46 Merge branch 'master' into dev
DRC 1ed312ea 2020-10-15T17:47:31 "ARM"="Arm", "NEON"="Neon" Refer to: https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark NOTE: These changes are only applied to change log entries for 2.0.x and later, since the change log is a historical record and Arm's new trademark policy did not go into effect until late 2017.
DRC ae08115d 2020-10-15T10:25:46 Merge branch 'master' into dev
DRC b5a14727 2020-10-15T10:22:51 Build: Fix permissions
DRC 6ab61fa1 2020-09-13T17:02:09 Merge branch 'master' into dev
DRC 6ee5d5f5 2020-07-28T18:06:20 ARMv8 NEON: Support Windows builds w/AArch64 MinGW Based on: https://github.com/mstorsjo/libjpeg-turbo/commit/c5ef6659285a7d5bc74c679aa87ad187186cf7e1 Closes #438
DRC 00d48d7e 2020-02-17T18:14:10 Merge branch 'master' into dev
DRC 035262a1 2020-02-17T18:03:10 MIPS DSPr2: Work around various 'make test' errors Referring to #408, this commit #ifdefs DSPr2 SIMD functions that only work on little endian processors, and it completely excludes jsimd_h2v1_downsample_dspr2() and jsimd_h2v2_downsample_dspr2(). The latter two functions fail with the TJBench tiling regression tests, most likely because the implementation of the functions predates those tests.
DRC ed7cab47 2020-02-17T16:35:00 MIPS DSPr2: Fix compiler warning with -mdspr2 If -mdspr2 is passed to the compiler, __mips_dsp will be defined, and __mips_dsp_rev will be >= 2, so parse_proc_cpuinfo() will not be used.
DRC 42d679b9 2020-02-17T15:19:32 MIPS SIMD: Always honor JSIMD_FORCE* env vars Previously, these environment variables were not honored unless a 74K CPU was detected, but this detection doesn't work properly with QEMU's user mode emulation. With all other CPU types, libjpeg-turbo honors JSIMD_FORCE* regardless of CPU detection.
DRC b34c85ea 2019-12-31T01:20:12 Merge branch 'master' into dev
DRC 166e3421 2019-12-31T01:10:30 simd/arm64/jsimd_neon.S: Fix checkstyle issue
DRC c4675d62 2019-12-31T00:42:53 Merge branch 'master' into dev
DRC b542e4c8 2019-12-20T13:18:23 ARMv8 SIMD: Support execute-only memory (XOM) Move constants out of the .text section in simd/arm64/jsimd_neon.S and into a .rodata section. This ensures that the ARMv8 NEON SIMD extensions are compatible with memory layouts that are marked execute-only (and thus unreadable.) Based on: https://github.com/ivanloz/libjpeg-turbo/commit/88f3ca7664fadfb5e106efecb7845753aaf330b7 Closes #318
DRC 81b8c0ee 2019-12-17T14:18:35 Loongson MMI: Merge with MIPS64/add auto-detection Modern Loongson processors are MIPS64-compatible, and MMI instructions are now supported in the mainline of GCC. Thus, this commit adds compile-time and run-time auto-detection of MMI instructions and moves the MMI SIMD extensions for libjpeg-turbo from simd/loongson/ to simd/mips64/. That will allow MMI and MSA instructions to co-exist in the same build once #377 has been integrated. Based on: https://github.com/FlyGoat/libjpeg-turbo/commit/82953ddd61549428f58066f7eff0d60ce7429865 Closes #383
mayeut e821464f 2018-04-03T12:47:54 ARM64 NEON SIMD impl. of prog. Huffman encoding This commit adds ARM64 NEON optimizations for the encode_mcu_AC_first() and encode_mcu_AC_refine() functions used in progressive Huffman encoding. Compression speedups for the typical set of five libjpeg-turbo test images (https://libjpeg-turbo.org/About/Performance): Cortex-A53: 23.8-39.2% (avg. 32.2%) Cortex-A72: 26.8-41.1% (avg. 33.5%) Apple A7: 29.7-45.9% (avg. 39.6%) Closes #229
DRC 9c6f79e9 2019-11-13T14:36:37 Fix formatting issues detected by checkstyle
DRC f60b6dd3 2019-11-12T17:42:39 Remove vestigial jpeg_nbits_table.inc Not needed since 087c29e07f7533ec82fd7eb1dafc84c29e7870ec
DRC 713c451f 2019-11-08T14:53:55 Enable SSE2 progressive Huffman encoder for x32 Referring to #289, I'm not sure where I arrived at the conclusion that the SSE2 progressive Huffman encoder doesn't provide any speedup for x32. Upon re-testing, I discovered it to be about 50% faster than the C encoder. This commit also re-purposes one of the CI tests (specifically, the jpeg-7 API/ABI test) so that it tests x32 as well.
DRC cbf0fcc8 2019-11-05T11:56:06 i386 SSE2 Huffman: Fix pointer arithmetic issue Splitting the pointer arithmetic in GET_SYM() into a separate add and sub instruction was an attempt to work around an error ("invalid operand type") that occurred when assembling the file with NASM. However, this created a link error on macOS ("ld: illegal text-relocation to '_jconst_huff_encode_one_block' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o from '_jsimd_huff_encode_one_block_sse2' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o for architecture i386") and also changed the alignment of the code in ways that might have affected the previous benchmark results (which took a great deal of time to obtain.) Ultimately, the path of least resistance is just to require NASM 2.13 or later.
DRC bbedb4b5 2019-11-05T15:43:21 Merge branch 'master' into dev
DRC cf54623b 2019-11-05T12:21:25 Mac: Support hiding SIMD fct symbols w/ NASM 2.14+ (NASM 2.14+ now supports the private_extern section directive, which was previously only available with YASM.)
DRC 087c29e0 2018-10-22T10:05:18 Optimize Huffman encoding This commit improves the C and SSE2 Huffman encoding implementations in the following ways: - Avoid using xmm8-xmm15 in the x86-64 SSE2 implementation. There is no actual need to use those registers, and avoiding them produces a cleaner WIN64 function entry/exit-- as well as shorter code, since REX prefixes can be avoided (this is helpful on certain CPUs, such as Intel Atom, for which instruction fetch and decoding can be a bottleneck.) - Optimize register usage so that fewer REX prefixes and register-register moves are needed. - Use the bit counter to store the number of free bits in the bit buffer rather than the number of bits in the bit buffer. This changes the method for inserting a code into the bit buffer to: (put_buffer |= code << (free_bits -= code_size)); As a result: * Only one bit counter needs to stay in a register (we just keep it in cl.) * The bit buffer contents are already properly aligned to be written out (after a byte swap.) * Adjusting the free bits counter and checking if the bit buffer is full can be combined into a single operation. * We can wait to flush the bit buffer until the buffer is actually full and not just in danger of becoming full. Thus, eight bytes can be flushed at a time. - Speed is quite sensitive to the alignment of branch target labels, so insert some padding and remove branches from the flush code. (Flushing this way isn't actually faster when compared to using branches, but the branchless code doesn't need extra alignment and is thus smaller.) - Speculatively write out the bit buffer as a single 8-byte write, falling back to a byte-by-byte write only if there are any 0xFF bytes in the bit buffer that need to be encoded as 0xFF 0x00. - Use MMX registers for the 32-bit implementation (so the bit buffer can be 64 bits wide.) - Slightly reduce overall function code size. - Eliminate or combine a few SSE instructions. - Make some minor improvements to instruction scheduling. - Adjust flush_bits() in jchuff.c to handle cases in which the bit buffer has less than 7 free bits (apparently that couldn't happen before.) Based on: https://github.com/1camper/libjpeg-turbo/commit/947a09defa2ec848322b1bae050d1b57b316a32a https://github.com/1camper/libjpeg-turbo/commit/262ebb6b816fd8a49ff4d7185f6c5153dddde02f https://github.com/1camper/libjpeg-turbo/commit/6e9a091221bb244c8ba232a942650e94254ffcf0 See change log for performance claims. Closes #292
DRC d92ae5df 2019-11-04T18:50:45 Merge branch 'master' into dev
DRC 6902cdb1 2019-10-28T14:28:29 Build: Don't require ASM_NASM if !REQUIRE_SIMD The build system is supposed to fall back to a non-SIMD build if WITH_SIMD==1 but REQUIRE_SIMD==0. Based on: https://github.com/emlix/libjpeg-turbo/commit/972df912d08b755db3ca60d93b058a42e97a79eb Closes #384
DRC 95f4d6ef 2019-10-24T02:13:23 Merge branch 'master' into dev
DRC 3a32d199 2019-10-17T19:59:01 x86 SIMD: Consistify capitalization of NASM types byte, word, dword, qword, oword, and yword are all assembler keywords, so it makes sense to use lowercase for these so as not to mistake them for macros or constants.
DRC 9a51a87a 2019-10-17T11:21:32 x86 SIMD: Remove obsolete [TAB8] comments With apologies to Richard Hendricks, our assembly code no longer uses tabs.
DRC 8ef53b10 2019-08-14T22:08:59 Merge branch 'master' into dev
DRC a81a8c13 2019-08-14T13:17:11 SSE2 SIMD: Fix prog Huffman enc. error if Sl%16==0 (regression introduced by 5b177b3cab5cfb661256c1e74df160158ec6c34e) The SSE2 implementation of progressive Huffman encoding performed extraneous iterations when the scan length was a multiple of 16. Based on: https://github.com/rouault/libjpeg-turbo/commit/bb7f1ef98305da915e581b59bd0ec2ef7bdb8468 Fixes #335 Closes #367
DRC 7fbfe29c 2019-07-18T15:18:27 Merge branch 'master' into dev
DRC f37b7c1f 2019-07-02T11:28:26 Build: Fix build/install with Xcode IDE Closes #355
DRC f36d5315 2019-04-23T14:54:23 Merge branch 'master' into dev
Chris Blume aa9db616 2019-04-15T17:55:47 x86 SIMD: Check for CPUID leaf 07H before using According to Intel's manual [1], "If a value entered for CPUID.EAX is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned." Right now, libjpeg-turbo doesn't first check that leaf 07H is supported before attempting to use it, so the ostensible AVX2 bit (Bit 05) of the CPUID result might actually be Bit 05 from a lower leaf. That bit might be set, even if the CPU doesn't support AVX2. This commit modifies the x86 and x86-64 SIMD feature detection code so that it first checks whether CPUID leaf 07H is supported before attempting to use it to check for AVX2 instruction support. DRC: This commit should fix https://bugzilla.mozilla.org/show_bug.cgi?id=1520760 However, I have not personally been able to reproduce that issue, despite using a Nehalem (pre-AVX2) CPU on which the maximum CPUID leaf has been limited via a BIOS setting. Closes #348 [1] "Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (2A, 2B, 2C & 2D): Instruction Set Reference, A-Z", https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf, page 3-192.
DRC afbe48c2 2019-02-27T13:05:58 MMI: Support 32-bit Loongson architectures
DRC 98ff5507 2019-02-27T13:17:35 MMI: Fix bug in jsimd_h2v1_merged_upsample_mmi() ... that occurred when ((image width) & 1) != 0.
DRC 3ca6dba9 2019-02-17T09:33:57 Merge branch 'master' into dev
Chris Blume b46af82c 2019-02-12T17:35:10 ARMv7 NEON: #ifdef unused funcs/vars w/ -mfpu=neon When simd/arm/jsimd.c is compiled with __ARM_NEON__ defined (which will be the case if -mfpu=neon is passed to the compiler), the parse_proc_cpuinfo() and check_feature() functions and the bufsize variable are unused and thus need to be #ifdef'ed out in order to avoid compiler warnings. Note that the bufsize variable was already #ifdef'ed out on Linux but not on Android due to lack of parentheses (&& takes precedence over ||.) Closes #331
DRC bdec9958 2019-02-01T01:16:13 MMI: Fix unaligned decomp. perf. for 32-bit PFs (Oversight from db84125fcb05bbc48430b53d45b89392a8f3609e)
DRC fa905fbf 2019-02-01T00:42:09 MMI: Use unaligned stores w/ merged upsampling ... when necessary. This was an oversight from 2f9e7c84d1a95c1bae8bb8d38fbc2adaeecf4d41
DRC 9aada25c 2019-02-01T01:01:38 Merge branch 'master' into dev
DRC e2442e07 2019-02-01T00:56:02 MMI: Fix unaligned comp. perf. for 32-bit PFs also (Oversight from 1c2d3cfaaf7324d9091ba3cc4e900f60a16fe1aa)
DRC 73fd6041 2019-02-01T00:24:09 MMI: Fix formatting issue detected by checkstyle
DRC 2f9e7c84 2019-01-31T21:24:13 Loongson MMI h2v1 and h2v2 merged upsampling Based on: https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
DRC 3c7199ff 2019-01-31T16:22:31 Loongson MMI h2v1 fancy upsampling Based on: https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
DRC 73b98acd 2019-01-31T13:54:46 Loongson MMI RGB-to-Grayscale conversion Based on: https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
DRC bb0d1702 2019-01-30T22:41:57 Improve readability of Loongson MMI code We have more than eight registers to work with, as well as three-operand intrinsics, so there's no need for the implementation to be such a literal port of the MMX code.
DRC db84125f 2019-01-30T14:12:06 MMI: Use aligned store instructions when possible This improves decompression performance by 2-5%.
DRC ae4221f9 2019-01-29T19:51:08 Loongson MMI fast forward/inverse DCT Based on: https://github.com/zhanglixia-hf/libjpeg-turbo/commit/32a9ca222d7e4c8e01bb75cd137f204a0587b383
DRC 674343ab 2019-01-31T15:30:25 Merge branch 'master' into dev
DRC 1c2d3cfa 2019-01-30T12:43:45 MMI: Fix comp. perf. issue w/ unaligned image rows Using ldc1 with a non-64-bit-aligned memory location causes as much as a 10x slow-down in overall compression performance.
DRC 01e30323 2019-01-23T14:58:24 Eliminate support for compilers w/o unsigned char libjpeg-turbo has never really supported such compilers, since (AFAIK) they are non-existent on any modern computing platform and thus impossible for us to test. (Also, the TurboJPEG API would break without unsigned chars.) Furthermore, the unified CMake-based build system introduced in 2.0 always defines HAVE_UNSIGNED_CHAR, so retaining other code paths is pointless. Eliminating support for compilers without unsigned char eliminates the need for the GETJSAMPLE() macro, which improves the readability of many parts of the code as well as improving the performance of writing Targa and Windows BMP files. Fixes #317
DRC 2cc4f93c 2018-11-12T14:40:19 Merge branch 'master' into dev
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
DRC 133e4af0 2018-09-04T16:56:22 Add x32 ABI support on Linux The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers. (Refer to https://sites.google.com/site/x32abi) Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/8da8fc5213d87336d6c7200aaeeca925603e12cf https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/1e33dfea8042230e266b453f53d69a6e37b7f0de https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/24ffea78da0f18d0d467d16e02dfb903e6c0181e https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/dedcf76753c8913ef5c3c6e4ea329d29494b6065 https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/d04228a7b58b9aed5bcbec383630ec1a14a3c9ca https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/b4ad38316ae1899c8a00b6568bb0325d82edcd7a Closes #274
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
kmx.io     mail     discord kmxgit v0.4.0