kc3-lang/libjpeg-turbo/simd

simd

Log

Author Commit Date CI Message
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 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 f73b1dbc 2018-08-09T15:08:21 Neon: Intrinsics implementation of RGB->Grayscale There was no previous 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 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 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 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
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
kmx.io     mail     discord kmxgit v0.4.0