kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 11426a87 2016-12-10T09:10:57 Packaging system: "PACKAGE_NAME" = "PKGNAME" Using PACKAGE_NAME as a variable name made more sense with autotools, but now it's more of an inconvenience variable than a convenience variable.
DRC 67ad5350 2016-12-10T09:00:39 Build: Don't require sudo for `make tarball` The whole point of `make tarball` is to make it easy for users to create a binary distribution of libjpeg-turbo on platforms that aren't supported by our official build system, so requiring root permissions somewhat defeated that purpose. Intead, the script now attempts to detect whether the system has GNU tar or a recent version of BSD tar that supports setting the ownership of the files in the tarball.
DRC 6c6696e5 2016-12-09T17:12:12 Mac pkg: Use PKGNAME for documentation directory Although there is little chance that we will ever have a package conflict on OS X, the convention from our Linux packages is to use the package name, not the project name, for the name of the documentation directory.
DRC 6530203f 2016-12-09T10:21:29 Build: More GNUInstallDirs improvements These improvements enable build systems to use GNUInstallDirs to define custom directory variables. - The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(), in keeping with the module's established macro naming convention. - Rather than detecting whether the prefix has changed, the new GNUInstallDirs_set_install_dir() macro instead examines whether the default for the variable in question has changed. This allows for more flexibility, since build systems may decide to change the defaults based on factors other than the prefix. It also enables the macro to work properly outside of the module. - The module now performs directory variable substitution within the body of GNUInstallDirs_get_absolute_install_dir(). - The JAVADIR variable is no longer included in GNUInstallDirs. That directory is not part of the GNU spec, and it turns out that various operating systems use different conventions for the location of Java classes. Instead, the variable is now implemented in our build system as a demonstration of the aforementioned GNUInstallDirs enhancements.
DRC c8358fcb 2016-12-08T14:43:59 Build: Various improvements to install/pkg system - GNUInstallDirs: any directory variable can now reference any other directory variable by including its name in angle brackets (<>). - Changed the documentation of the directory variables in BUILDING.md accordingly. This commit also includes some formatting tweaks to that section (using boldface for directory names, as is our convention.) - Changed the package scripts such that they use CMAKE_INSTALL_DATAROOTDIR rather than CMAKE_INSTALL_DATADIR. - We no longer override the install dir. defaults on Windows unless performing an official build. It may be useful, for instance, to use the GNU defaults when installing into an MSYS environment.
DRC b0fcd0cc 2016-12-07T19:14:20 Build: Minor tweaks to GNUInstallDirs defaults It isn't actually necessary to specify `CMAKE_INSTALL_DEFAULT_MANDIR` for our official build. Because `CMAKE_INSTALL_DEFAULT_DATAROOTDIR` is blank for the official build, the default of "<DATAROOTDIR>/man" will resolve to "man". For the same reason, this commit changes the specification of `CMAKE_INSTALL_DEFAULT_DOCDIR` and `CMAKE_INSTALL_DEFAULT_JAVADIR` in the official build to be dependent on the data root directory (mainly to make it obvious what we're doing.) This commit also tweaks the example CMake command line in the directory variable documentation so that it shows the correct location of the CMake argument.
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 d681fa76 2016-12-07T10:54:54 Build: Set install dirs in a more GNU-friendly way This builds upon the existing GNUInstallDirs module in CMake but adds the following features to that module: - The ability to override the defaults for each install directory through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`). Before operating system vendors began shipping libjpeg-turbo, it was meant to be a run-time drop-in replacement for the system's distribution of libjpeg, so it has traditionally installed itself under /opt/libjpeg-turbo on Un*x systems by default. On Windows, it has traditionally installed itself under %SystemDrive%\libjpeg-turbo*, which is not uncommon behavior for open source libraries (open source SDKs tend to install outside of the Program Files directory so as to avoid spaces in the directory name.) At least in the case of Un*x, the install directory behavior is based somewhat on the Solaris standard, which requires all non-O/S packages to install their files under /opt/{package_name}. I adopted that standard for VirtualGL and TurboVNC while working at Sun, because it allowed those packages to be located under the same directory on all platforms. I adopted it for libjpeg-turbo because it ensured that our files would never conflict with the system's version of libjpeg. Even though many Un*x distributions ship libjpeg-turbo these days, not all of them ship the TurboJPEG API library or the Java classes or even the latest version of the libjpeg API library, so there are still many cases in which it is desirable to install a separate version of libjpeg-turbo than the one installed by the system. Furthermore, installing the files under /opt mimics the directory structure of our official binary packages, and it makes it very easy to uninstall libjpeg-turbo. For these reasons, our build system needs to be able to use non-GNU-compliant defaults for each install directory if `CMAKE_INSTALL_PREFIX` is set to the default value. - For each directory variable, the module now detects changes to `CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly, if the variable has not been changed by the user. This makes it easy to switch between our "official" directory structure and the GNU-compliant directory structure "on the fly" simply by changing `CMAKE_INSTALL_PREFIX`. Also, this new mechanism eliminated the need for the crufty mechanism that previously did the same thing just for the library directory variable. How it should work: - If a dir variable is unset, then the module will set an internal property indicating that the dir variable was initialized to its default value. - If the dir variable ever diverges from its default value, then the internal property is cleared, and it cannot be set again without unsetting the dir variable. - If the install prefix changes, and if the internal property indicates that the dir variable is still set to its default value, and if the dir variable's value is not being manually changed at the same time that the install prefix is being changed, then the dir variable's value is automatically changed to the new default value for that variable (as determined by the new install prefix.) - The directory variables are now always cached, regardless of whether they were set on the command line or not. This ensures that they can easily be examined and modified after being set, regardless of how they were set. This was made possible by the introduction of the aforementioned `CMAKE_INSTALL_DEFAULT_*DIR` variables. - Improved directory variable documentation (based on descriptions at https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) - The module now allows "<DATAROOTDIR>" to be used as a placeholder in relative directory variables. It is replaced "on the fly" with the actual path of `CMAKE_INSTALL_DATAROOTDIR`. This should more closely mimic the behavior of the old autotools build system while retaining our customizations to it, and it should retain the behavior of the old CMake build system. Closes #124
DRC ff05b6e0 2016-12-07T14:09:41 Build: Fix Win "installer" target Java dependency The correct target name is now "turbojpeg-java".
DRC e6426d24 2016-12-07T10:40:28 Build: Formatting tweak (It is our convention to use lowercase for CMake macro/function names)
DRC 2af2fe42 2016-12-05T16:52:54 Build: Clean up inline keyword detection Strict C89-conformant compilers don't support the "inline" keyword, but most of them support "__inline__", and that keyword can be used with the always_inline atribute as well. This commit also removes duplicate code by using a foreach() loop to test the various keywords.
DRC 261db770 2016-12-03T15:51:58 Packaging: Use correct name for SRPM spec file Per convention, the file should be named {package name}.spec.
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 d642da75 2016-12-03T13:38:21 Build: Fix buglet in output of `make tjtest`
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 97205269 2016-11-23T18:44:33 Travis: Fix OS X build + migrate to new xcode7.3 image, since xcode7.2 is going away soon.
DRC 27d4c5ea 2016-11-23T17:12:57 Build: Fix RPATH handling CMAKE_INSTALL_RPATH has to be set before the targets are defined (oops.) This also explicitly turns on MACOSX_RPATH for the shared libraries (which is the default with newer versions of CMake but not with 2.8.x.) The old autotools/libtool build system hard-coded the install name directory of the OS X shared libraries to libdir, which meant that any executable that linked against those libraries would also be hard-coded to look for the libjpeg-turbo libraries in that directory. @rpath makes the OS X version of libjpeg-turbo behave like the Linux version, in the sense that the executables under /opt/libjpeg-turbo/bin will automatically pick up the libraries under /opt/libjpeg-turbo/lib* by default, but other executables won't unless they are linked with -rpath.
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 9df7ac2e 2016-11-18T08:31:49 BUILDING.md: NASM 2.10+/YASM 1.2.0+ always needed ... for all x86[-64] builds, because we now have both 64-bit and 32-bit AVX2 SIMD extensions.
DRC 0ff7da71 2016-11-16T15:55:12 Advertise the new AVX2 SIMD extensions (our story so far ...)
DRC 9fdb8f85 2016-11-22T09:33:19 Merge branch 'master' into dev
DRC d6d7b539 2016-11-21T22:58:18 AppVeyor: Use built-in MSYS2 MinGW compilers AppVeyor already has MinGW32 and MinGW64 flavors of GCC 5.3.0 installed under MSYS2, so there is no need to install our own builds of MinGW. MinGW-builds is no longer an active project, and we were getting occasional timeouts while wgetting those files from SourceForge. Furthermore, GCC 5.3.0 should produce faster code than GCC 4.8.1.
DRC f9f0c75b 2016-11-20T20:59:55 BUILDING.md: Clarifications and wordsmithing Updated out-of-date information, wordsmithed and clarified many sections, and generally cleaned up the build recipes (including a complete overhaul of the iOS recipes.)
DRC 3da94de2 2016-11-20T19:10:54 Windows build: Add an "uninstall" target
DRC ab664e35 2016-11-18T09:09:41 BUILDING.md/README.md: Increment libjpeg SO age Documentation buglet. This should have been changed in 6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of libjpeg API functions in libjpeg-turbo 1.5.
DRC ce26e83f 2016-11-18T09:08:52 README.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
DRC 74e4c793 2016-11-16T15:08:16 TJBench: Fix regression/-nowrite always enabled Introduced by eb59b6e72d8098a1f7b8c7e0c710b32eb6f5dc45
DRC a280fa63 2016-11-15T09:52:49 BUILDING.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
DRC 6aae0077 2016-11-15T08:37:04 CMake build system: Fix the "testclean" target Regression caused by f9134384b728d8943f252b27464d83c4b7b2d159 This commit also makes the "testclean" target clean up the 4:1:1 test images. This was implemented in the autotools build system in 1f3635c4969f2319a01c9fe561958815b733227f but was left out of the CMake build system due to an oversight.
Chris Young 4ad94b29 2016-11-18T19:03:28 Detect AltiVec support on AmigaOS 4
DRC a949da48 2016-10-20T19:17:30 Merge branch 'master' into dev
DRC 2d4b2f14 2016-10-20T17:55:55 Travis: Deploy to S3 rather than SourceForge This has the following advantages: -- It doesn't require checking a private SSH key into the repository. (With SourceForge, an SSH key is the "keys to the kingdom".) -- If the S3 key is compromised, it is very easy to revoke it and generate a new one. -- The S3 bucket is isolated, so even if it becomes compromised, then the damage that one could do is limited. -- It's much easier to manage files through S3's web interface than through SourceForge. -- The files are served via HTTPS. -- Travis fully supports S3 as a deployment target, so this simplifies .travis.yml somewhat.
DRC 108b1cd9 2016-10-20T01:37:40 Merge branch 'master' into dev
DRC 9366cf0b 2016-10-20T01:01:27 Travis: GPG sign Linux binaries/source tarballs Since we're still deploying our Linux/macOS CI artifacts to a web server (specifically SourceForge Project Web Services) that doesn't support HTTPS, it's a good idea to sign them. But since the private key has to be checked into the repository, we use a different key for signing the pre-releases (per project policy, the private signing keys for our release binaries are never made available on any public server.)
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 1a8c68ac 2016-10-07T12:55:18 Merge branch 'master' into dev
DRC 1ee329d6 2016-10-07T12:54:55 Travis: Fix deployment issue (2nd attempt)
DRC fa3bdfb7 2016-10-07T05:47:35 Merge branch 'master' into dev
DRC b47c5e73 2016-10-07T05:34:11 Travis: Fix deployment issue "Skipping a deployment with the script provider because this branch is not permitted"
DRC ce262eb5 2016-10-07T05:07:22 Fix AppVeyor build on non-master branches buildljt will clone the Git repository into the temp. directory, even if the repository is really a local sandbox, so we need to specify the branch.
DRC 27f817cd 2016-10-07T05:07:11 Travis: Use existing sandbox for official builds This eliminates the need to specify the remote repository and branch, and it prevents the code from being checked out twice.
DRC 7884e245 2016-10-07T04:51:29 Merge branch 'master' into dev
DRC 0df2e218 2016-10-07T04:28:02 Add AppVeyor config for Windows pre-release builds
DRC be908ac0 2016-10-05T14:42:35 Travis CI: Fixes to support AVX2 code -- Use trusty for SIMD builds. Ubuntu 12.04 is still using NASM 2.09.x, which isn't new enough to support AVX2. -- Add a special test for the SSE2 code path, since it is no longer the default.
DRC ed21f4bd 2016-10-05T14:41:14 Merge branch 'master' into dev
DRC 6d22430a 2016-10-05T14:36:46 Travis: use correct repo/branch for off. builds Pass the actual repository and branch that Travis is using into the builtljt script, so the official builds it generates will come from the same code base as the other tested builds.
DRC f34f2f5b 2016-10-05T13:36:35 Fix 'make dist'
DRC e9e3a2ed 2016-10-05T12:38:59 Travis CI: Use correct key for this repository
DRC 211c69f3 2016-10-02T09:13:23 Add Travis CI config for Un*x pre-release builds
DRC 1625253d 2016-10-04T13:41:48 Fix 32-bit non-SIMD FP regression tests - Introduce a new FLOATTEST value ("387") on Un*x systems that will compare the floating point DCT/IDCT algorithms against the expected results from the C algorithms when built using 32-bit code and -mfpmath=387. - Extend the Windows regression tests so that they work properly when building libjpeg-turbo with 32-bit code and without SIMD, using either Visual C++ (tested with 2008, 2010, 2015) or MinGW.
DRC a0047bde 2016-10-04T13:25:34 Fix broken build w/ Visual C++ < 2010 Regression introduced by dfefba77520ded5c5fd4864e76352a5f3eb23e74 (Windows doesn't always have stdint.h.)
DRC 7bfb22af 2016-09-26T17:59:14 Fix broken MIPS build Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152 Fixes #104
DRC ac4a8995 2016-09-22T14:38:51 Fix UBSan warning in arithmetic decoder Very similar to the ones that were fixed in the Huffman decoders in 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a. These are innocuous. Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1304567.
DRC dfefba77 2016-09-22T14:19:29 Fix broken build with NDK platforms < android-21 Regression introduced by a09ba29a55b9a43d346421210d94370065eeaf53 Fixes #103
DRC 4cf67f23 2016-09-22T14:14:05 Bump version to 1.5.2 to prepare for new commits
Roberto Civille Rodrigues 9407cf7f 2016-09-22T00:42:25 README.md: Fix typo Introduced in 17de51835735e319ada5ca139a64227423946a8a Closes #102
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 e9d9c31f 2016-09-19T22:47:18 Build: Remove ARMv6 support from 'make iosdmg' The last iDevice to require ARMv6 was the iPhone 3G, which required iOS 4.2.1 or older. Our binaries have always required iOS 4.3 or newer, so I'm not sure if the ARMv6 fork of our binaries was ever useful to begin with. In any case, if it ever was useful, it no longer is. Fat binaries can still be generated with ARMv6 support by invoking {build_directory}/pkgscripts/makemacpkg manually.
DRC 077e5bb4 2016-09-08T21:49:02 Fix out-of-bounds write in partial decomp. feature Reported by Clang UBSan (refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.) This appears to be a legitimate bug introduced by 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e. Any component array, such as first_MCU_col and last_MCU_col, should always be able to accommodate MAX_COMPONENTS values. The aforementioned test image had 8 components, which was not enough to make the out-of-bounds write bust out of the jpeg_decomp_master struct (and fortunately the memory after last_MCU_col is an integer used as a boolean, so stomping on it will do nothing other than change the decoder state.) I crafted another special image that has 10 components (the maximum allowable), but that was apparently not enough to bust out of the allocated memory, either. Thus, it is posited that the security threat posed by this bug is either extremely minimal or non-existent.
DRC a1dd3568 2016-09-08T21:29:58 Silence additional UBSan warnings NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced by 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a, but apparently I need to be REALLY clear that I'm trying to do pointer arithmetic rather than dereference an array. Grrr... Refer to: https://bugzilla.mozilla.org/show_bug.cgi?id=1301250 https://bugzilla.mozilla.org/show_bug.cgi?id=1301256
DRC a09ba29a 2016-09-07T16:40:10 Fix unsigned int overflow in libjpeg memory mgr. When attempting to decode a malformed JPEG image (refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1295044) with dimensions 61472 x 32800, the maximum_space variable within the realize_virt_arrays() function will exceed the maximum value of a 32-bit integer and will wrap around. The memory manager subsequently fails with an "Insufficient memory" error (case 4, in alloc_large()), so this commit simply causes that error to be triggered earlier, before UBSan has a chance to complain. Note that this issue did not ever represent an exploitable security threat, because the POSIX-based memory manager that we use doesn't ever do anything meaningful with the value of maximum_space. jpeg_mem_available() simply sets avail_mem = maximum_space, so the subsequent behavior of the memory manager is the same regardless of whether maximum_space is correct or not. This commit simply removes a UBSan warning in order to make it easier to detect actual security issues.
DRC 8ce2c911 2016-08-01T11:22:24 TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical luminance,chrominance sampling factors of 1x2,1x1. However, it is technically legal to create 4:2:2 JPEGs with sampling factors of 2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and 2x2 + 2x1 + 2x1) are still <= 10. The libjpeg API correctly decodes such images, so the TurboJPEG API should as well. Fixes #92
DRC db044351 2016-07-14T13:36:47 Silence pedantic GCC6 code formatting warnings Apparently it's "misleading" to put two self-contained if statements on a single line. Who knew?
DRC 7723d7f7 2016-07-13T20:39:11 Use plain upsampling if merged isn't accelerated Currently, this only affects ARM, since it is the only platform that accelerates YCbCr-to-RGB conversion but not merged upsampling. Even if "plain" upsampling isn't accelerated, the combination of accelerated color conversion + unaccelerated plain upsampling is still faster than the unaccelerated merged upsampling algorithms. Closes #81
Kornel Lesiński 628c168c 2016-07-10T19:01:51 Implement h1v2 fancy upsampling This allows fancy upsampling to be used when decompressing 4:2:2 images that have been losslessly rotated or transposed. (docs and comments added by DRC) Based on https://github.com/pornel/libjpeg-turbo/commit/f63aca945debde07e7c6476a1f667b71728c3d44 Closes #89
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 1945ad96 2016-07-12T22:21:20 Don't install libturbojpeg.pc if TJPEG disabled
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 9e6c6a14 2016-07-06T16:22:27 Bump version to 1.5.1 to prepare for new commits
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 6cb27c31 2016-05-09T20:28:17 Bump version to 1.6 alpha1 (to prepare for new features)
DRC ff5685d5 2016-05-27T16:58:23 Reformat SSE/SSE2 SIMD code to improve readability
DRC 3ff13e65 2016-05-31T22:53:17 1.5.0
DRC 1d50a8cd 2016-05-31T22:48:52 BUILDING.md: More NASM/YASM clarifications 28d1a1300c6be7fc8614ed827eb56cd97cf84e76 introduced the line "nasm.exe should be in your PATH". This commit corrects an oversight in 8f1c0a681cd34e8e80ba7b06f356d6080a7172c9 / e5091f2cf3b6ba747907012146df93df0d01ec85 whereby this line should have been extended to include yasm.exe.
kmx.io     mail     discord kmxgit v0.4.0