|
42d2a243
|
2025-09-10T13:06:51
|
|
Build: Fix Loongson MMI detection with -Werror
If compiler warnings are treated as errors, then the apostrophe in
"Loongson MMI can't work with MIPS Release 6+" triggers a compiler
warning that causes the HAVE_MMI test to fail. Surrounding the error
message with quotes fixes the issue.
|
|
|
ea4ee229
|
2024-12-11T16:51:39
|
|
Neon: Disable some strict compiler warnings
We use a standard set of strict compiler warnings with Clang and GCC to
continuously test and maintain C89 conformance in the libjpeg API code.
However, SIMD extensions need not comply with that. The Neon code
specifically uses some C99isms, so disable
-Wdeclaration-after-statement, -Wc99-extensions, and -Wpedantic in the
scope of that code. Also modify the Neon feature tests so that they
will succeed if any of the aforementioned compiler warnings are enabled.
|
|
|
e287a357
|
2024-07-04T10:03:50
|
|
Build: Put gastest.o in ${CMAKE_BINARY_DIR}/simd
Closes #776
|
|
|
3202feb0
|
2024-02-29T16:10:20
|
|
x86-64 SIMD: Support CET if C compiler enables it
- Detect at configure time, via the __CET__ C preprocessor macro,
whether the C compiler will include either indirect branch tracking
(IBT) or shadow stack support, and define a NASM macro (__CET__) if
so.
- Modify the x86-64 SIMD code so that it includes appropriate endbr64
instructions (to support IBT) and an appropriate .note.gnu.property
section (to support both IBT and shadow stack) when __CET__ is
defined.
Closes #350
|
|
fac83814
|
2022-05-14T14:34:43
|
|
Build: Don't enable Loongson MMI with MIPS R6+
MIPS R6 removed some instructions, so Loongson MMI cannot be built with
MIPS R6+ toolchains.
Closes #598
|
|
|
6d2d6d3b
|
2022-02-11T09:34:01
|
|
"YASM" = "Yasm"
The assembler name was initially spelled "YASM", but it has been "Yasm"
for the entirety of libjpeg-turbo's existence.
|
|
|
e1588a2a
|
2022-02-10T22:23:26
|
|
Build: Fix Neon capability detection w/ MSVC
(broken by 57ba02a408a9a55ccff25aae8b164632a3a4f177)
Refer to #547
|
|
|
a01857cf
|
2021-12-01T17:08:29
|
|
Build: Disallow NEON_INTRINSICS=0 if GAS is broken
If NEON_INTRINSICS=0, then run the GAS sanity check from libjpeg-turbo
2.0.x and force-enable NEON_INTRINSICS if the test fails. This fixes
the AArch32 build when using Clang 6.0 on Linux or the Clang toolchain
in the Android NDK r15*-r16*. It also prevents users from manually
disabling NEON_INTRINSICS if doing so would break the build (such as
with Xcode 5.)
|
|
|
57ba02a4
|
2021-10-01T16:28:54
|
|
Build: Improve Neon capability detection
- Use check_c_source_compiles() rather than check_symbol_exists() to
detect the presence of vld1_s16_x3(), vld1_u16_x2(), and
vld1q_u8_x4(). check_symbol_exists() is unreliable for detecting
intrinsics, and in practice, it did not detect the presence of the
aforementioned intrinsics in versions of GCC that support them.
- Set DEFAULT_NEON_INTRINSICS=0 for GCC < 12, even if the aforementioned
intrinsics are available. The AArch64 back end in GCC 10 and 11
supports the necessary intrinsics, but the GAS implementation is still
faster when using those compilers.
Fixes #547
|
|
|
a9c41fbc
|
2021-10-03T12:43:15
|
|
Build: Don't enable Neon SIMD exts with Armv6-
When building for 32-bit Arm platforms, test whether basic Neon
intrinsics will compile with the specified compiler and C flags. This
prevents the build system from enabling the Neon SIMD extensions when
targetting Armv6 and other legacy architectures that do not support Neon
instructions.
Regression introduced by bbd8089297862efb6c39a22b5623f04567ff6443.
(Checking whether gas-preprocessor.pl was needed for 32-bit Arm builds
had the effect of checking whether Neon instructions were supported.)
Fixes #553
|
|
|
0081c2de
|
2021-07-07T10:12:46
|
|
Neon/AArch32: Fix build if 'soft' float ABI used
Arm compilers have three floating point ABI options:
'soft' compiles floating point operations as function calls into a
software floating point library, which emulates floating point
operations using integer operations. Floating point function arguments
are passed using integer registers.
'softfp' also compiles floating point operations as function calls into
a floating point library and passes floating point function arguments
using integer registers, but the floating point library functions can
use FPU instructions if the CPU supports them.
'hard' compiles floating point operations into inline FPU instructions,
similarly to x86 and other architectures, and passes floating point
function arguments using FPU registers.
Not all AArch32 CPUs have FPUs or support Neon instructions, so on Linux
and Android platforms, the AArch32 SIMD dispatcher in libjpeg-turbo only
enables the Neon SIMD extensions at run time if /proc/cpuinfo indicates
that the CPU supports Neon instructions or if Neon instructions are
explicitly enabled (e.g. by passing -mfpu=neon to the compiler.) In
order to support all AArch32 CPUs using the same code base, i.e. to
support run-time FPU and Neon auto-detection, it is necessary to compile
the scalar C source code using -mfloat-abi=soft. However, the 'soft'
floating point ABI cannot be used when compiling Neon intrinsics, so the
intrinsics implementation of the Neon SIMD extensions must be compiled
using -mfloat-abi=softfp if the scalar C source code is compiled using
-mfloat-abi=soft.
This commit modifies the build system so that it detects whether
-mfloat-abi=softfp must be explicitly added to the compiler flags when
building the intrinsics implementation of the Neon SIMD extensions.
This will be necessary if the build is using the 'soft' floating
point ABI along with run-time auto-detection of Neon instructions.
Fixes #523
|
|
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.
|
|
|
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.
|
|
|
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
|
|
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.
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
f73b1dbc
|
2018-08-09T15:08:21
|
|
Neon: Intrinsics implementation of RGB->Grayscale
There was no previous GAS implementation.
|
|
|
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.
|
|
|
59352195
|
2020-10-19T21:17:46
|
|
Merge branch 'master' into dev
|
|
|
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.
|
|
|
ae08115d
|
2020-10-15T10:25:46
|
|
Merge branch 'master' into dev
|
|
b5a14727
|
2020-10-15T10:22:51
|
|
Build: Fix permissions
|
|
|
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
|
|
|
d92ae5df
|
2019-11-04T18:50:45
|
|
Merge branch 'master' into dev
|
|
|
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
|
|
|
7fbfe29c
|
2019-07-18T15:18:27
|
|
Merge branch 'master' into dev
|
|
|
f37b7c1f
|
2019-07-02T11:28:26
|
|
Build: Fix build/install with Xcode IDE
Closes #355
|
|
|
2f9e7c84
|
2019-01-31T21:24:13
|
|
Loongson MMI h2v1 and h2v2 merged upsampling
Based on:
https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
|
|
|
73b98acd
|
2019-01-31T13:54:46
|
|
Loongson MMI RGB-to-Grayscale conversion
Based on:
https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
|
|
|
ae4221f9
|
2019-01-29T19:51:08
|
|
Loongson MMI fast forward/inverse DCT
Based on:
https://github.com/zhanglixia-hf/libjpeg-turbo/commit/32a9ca222d7e4c8e01bb75cd137f204a0587b383
|
|
|
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
|
|
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.
|
|
|
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
|
|
|
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.
|
|
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
|
|
|
33ce0b5e
|
2018-03-01T10:38:17
|
|
Loongson MMI SIMD extensions
Based on:
https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8
Closes #158
|
|
|
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
|
|
|
9cdec16c
|
2018-02-23T13:58:24
|
|
32-bit AVX2 implementation of slow int inverse DCT
|
|
|
de9e9db6
|
2018-02-23T11:50:11
|
|
64-bit AVX2 implementation of slow int inverse DCT
|
|
|
ca387e7f
|
2018-02-17T20:31:30
|
|
32-bit AVX2 implementation of slow int forward DCT
|
|
|
264dd42a
|
2018-02-17T17:32:25
|
|
64-bit AVX2 implementation of slow int forward DCT
|
|
|
51cc89fa
|
2017-09-01T09:02:55
|
|
Merge branch 'master' into dev
|
|
|
1d935416
|
2017-09-01T13:52:21
|
|
Build: Use -maltivec when testing AltiVec support
Doesn't seem to be necessary with recent Linux/GCC configurations, but
it is definitely necessary with OS X.
|
|
|
c0f3512d
|
2017-08-31T20:57:19
|
|
Merge branch 'master' into dev
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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.)
|
|
|
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/
|
|
|
108b1cd9
|
2016-10-20T01:37:40
|
|
Merge branch 'master' into dev
|
|
|
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
|
|
|
b2921f1b
|
2016-07-08T21:28:48
|
|
32-bit AVX2 implementation of integer quantization
|
|
|
eaae2cdb
|
2016-07-08T13:56:30
|
|
64-bit AVX2 implementation of integer quantization
|
|
|
67de29b5
|
2016-07-07T22:04:25
|
|
32-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
|
|
|
6d765524
|
2016-07-07T20:34:08
|
|
32-bit AVX2 impl. of h2v2 & h2v1 upsampling
(Fancy & Plain)
|
|
|
421d34fd
|
2016-07-05T17:20:20
|
|
32-bit AVX2 impl. of YCC->RGB color conversion
|
|
|
c6300ffe
|
2016-07-05T15:50:50
|
|
32-bit AVX2 impl. of h2v2 & h2v1 downsampling
|
|
|
6448a5e5
|
2016-07-05T16:21:10
|
|
32-bit AVX2 impl. of RGB->YCC/RGB->Gray color conv
|
|
|
621b29f5
|
2016-05-31T15:19:53
|
|
64-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
|
|
|
f1cbc328
|
2016-05-29T08:09:27
|
|
64-bit AVX2 impl. of h2v2 & h2v1 upsampling
(Fancy & Plain)
|
|
|
72c837da
|
2016-05-29T06:54:56
|
|
64-bit AVX2 impl. of YCC->RGB color conversion
|
|
|
1c8a475c
|
2016-05-28T19:53:44
|
|
64-bit AVX2 impl. of h2v2 & h2v1 downsampling
|
|
|
8880e087
|
2016-05-28T19:15:18
|
|
64-bit AVX2 impl. of RGB->Gray color conversion
|
|
|
426d787c
|
2016-05-28T16:42:44
|
|
64-bit AVX2 impl. of RGB->YCC color conversion
|
|
|
2cf199cb
|
2016-05-20T10:45:32
|
|
Lay the groundwork for 64-bit AVX2 SIMD support
|
|
|
f3a8684c
|
2016-01-07T00:19:43
|
|
SSE2 SIMD implementation of Huffman encoding
Full-color compression speedups relative to libjpeg-turbo 1.4.2:
2.8 GHz Intel Xeon W3530, Linux, 64-bit: 2.2-18% (avg. 9.5%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit: 10-25% (avg. 17%)
2.3 GHz AMD A10-4600M APU, Linux, 64-bit: 4.9-17% (avg. 11%)
2.3 GHz AMD A10-4600M APU, Linux, 32-bit: 8.8-19% (avg. 15%)
3.0 GHz Intel Core i7, OS X, 64-bit: 3.5-16% (avg. 10%)
3.0 GHz Intel Core i7, OS X, 32-bit: 4.8-14% (avg. 11%)
2.6 GHz AMD Athlon 64 X2 5050e:
Performance-neutral (give or take a few percent)
Full-color compression speedups relative to IPP:
2.8 GHz Intel Xeon W3530, Linux, 64-bit: 4.8-34% (avg. 19%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit: -19%-7.0% (avg. -7.0%)
Refer to #42 for discussion. Numerous other approaches were attempted,
but this one proved to be the most performant across all platforms.
This commit also fixes #3 (works around, really-- the clang-compiled version
of jchuff.c still performs 20% worse than its GCC-compiled counterpart, but
that code is now bypassed by the new SSE2 Huffman algorithm.)
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/2cb4d41330e1edc4469f6b97ba73b73abfbeb02f
https://github.com/mayeut/libjpeg-turbo/commit/36c94e050d117912adbff9fbcc6fe307df240168
|
|
|
71e971fb
|
2015-12-19T14:18:21
|
|
Build: Use FILEPATH type for NASM CMake variable
This causes cmake-gui to to display the proper file chooser dialog
(as opposed to the directory chooser.)
Fixes #40
|
|
2472bc71
|
2014-06-22T21:14:39
|
|
Add proper support for Borland compilers (Borland needs section names to be prefixed with an underscore, and it needs OMF object files.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1328 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e47364ac
|
2014-05-10T10:10:03
|
|
Modify Windows build system to take into account new assembly file names
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1283 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
29d8f253
|
2012-08-07T21:59:59
|
|
Fix build issues that occurred whenever the source directory contained the letters "col", "mer", or "gra".
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@860 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8015a303
|
2012-03-17T14:32:38
|
|
Visual Studio 2010 doesn't like the wildcard at compile time, so let CMake expand it instead.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@813 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
105f9a94
|
2011-11-29T09:02:10
|
|
Expose NASM variable in ccmake
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@726 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0f905d35
|
2011-11-29T09:01:23
|
|
Expose NASM variable in ccmake
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@725 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
dc6f6a9c
|
2011-04-07T05:27:29
|
|
Don't need MSVC definition in assembler code anymore
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@575 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
577ae78c
|
2011-04-07T05:26:52
|
|
Don't need MSVC definition in assembler code anymore
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@574 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
926e01ff
|
2011-04-06T06:35:38
|
|
Attempt to make build work with Visual Studio 2010 (still doesn't work if SIMD or Java are enabled-- see bug tracker)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@573 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b05ebcbc
|
2011-04-04T21:00:53
|
|
Attempt to make build work with Visual Studio 2010 (still doesn't work if SIMD or Java are enabled-- see bug tracker)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@570 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
58b6ec45
|
2011-04-02T02:14:13
|
|
Ensure that *gra*.asm is rebuilt whenever *gry*.asm changes.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@558 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
da5220ac
|
2011-03-02T02:17:30
|
|
Fix Windows build; Add grayscale tests to Windows build; Add proper implementation of snprintf on Windows and use snprintf() in TurboJPEG library and tests instead of sprintf()
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@486 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d830d360
|
2010-10-15T20:07:41
|
|
Fix dependencies for the color conversion routines, which build other .asm files indirectly
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@265 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c869c2c8
|
2010-10-15T08:43:32
|
|
Unix LF
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@263 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cd5f2ee2
|
2010-10-15T08:39:44
|
|
Allow nasm path to be overridden
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@262 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
84697036
|
2010-10-15T03:43:24
|
|
First pass at a CMake build system
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@257 632fc199-4ca6-4c93-a231-07263d6284db
|