|
e2442e07
|
2019-02-01T00:56:02
|
|
MMI: Fix unaligned comp. perf. for 32-bit PFs also
(Oversight from 1c2d3cfaaf7324d9091ba3cc4e900f60a16fe1aa)
|
|
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.
|
|
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
|
|
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.
|
|
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
|
|
43c58ff9
|
2018-07-31T21:59:16
|
|
Correct various typos in code comments
Found via `codespell -q 3`
Closes #263
|
|
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.
|
|
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
|
|
b628d693
|
2018-04-08T12:49:05
|
|
Additional code formatting tweaks
... detected with an improved version of our checkstyle script
|
|
58cb10ee
|
2018-03-31T13:51:31
|
|
Eliminate compiler warnings w/ Solaris Studio
|
|
7b3c0f01
|
2018-03-31T13:25:44
|
|
PowerPC: Fix comp. warning when built w/ -maltivec
|
|
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
|
|
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
|
|
81baa1b5
|
2018-03-21T13:03:30
|
|
simd/i386/jchuff-sse2.asm: Minor formatting tweak
|
|
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.
|
|
84fbd4f1
|
2018-03-17T00:27:49
|
|
Merge branch 'master' into dev
|
|
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.
|
|
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.
|
|
33ce0b5e
|
2018-03-01T10:38:17
|
|
Loongson MMI SIMD extensions
Based on:
https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8
Closes #158
|
|
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.
|
|
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
|
|
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
|
|
7c2bfdb0
|
2018-02-26T18:43:40
|
|
Merge branch 'master' into dev
Closes #214
|
|
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
|
|
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
|
|
feaec37d
|
2018-02-24T14:20:59
|
|
Fix build with YASM
vinserti128 requires all operands to be specified
|
|
b6909ab3
|
2018-02-24T00:02:27
|
|
Make SIMD symbols private for MIPS ELF builds
Closes #210
|
|
9bef5df7
|
2018-02-23T23:31:02
|
|
Make SIMD symbols private for iOS ARM/ARM64 builds
|
|
88421563
|
2018-02-23T21:56:32
|
|
Make SIMD symbols private for x86[-64] ELF builds
|
|
9cdec16c
|
2018-02-23T13:58:24
|
|
32-bit AVX2 implementation of slow int inverse DCT
|
|
845fe8bf
|
2018-02-23T12:24:10
|
|
32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX
|
|
de9e9db6
|
2018-02-23T11:50:11
|
|
64-bit AVX2 implementation of slow int inverse DCT
|
|
715b7c38
|
2018-02-17T22:15:58
|
|
32-bit AVX2 implementation of int sample conv.
|
|
ca387e7f
|
2018-02-17T20:31:30
|
|
32-bit AVX2 implementation of slow int forward DCT
|
|
39e9e65c
|
2018-02-17T19:39:53
|
|
64-bit AVX2 implementation of int sample conv.
|
|
264dd42a
|
2018-02-17T17:32:25
|
|
64-bit AVX2 implementation of slow int forward DCT
|
|
ff392d81
|
2018-02-17T17:29:38
|
|
AVX2: Introduce YMMBLOCK macro for readability
|
|
bf6c7743
|
2017-12-07T19:29:42
|
|
Fix whitespace errors
|
|
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
|
|
e5c1613c
|
2017-07-07T15:15:19
|
|
x86: Fix "short jump is out of range" w/ NASM<2.04
|
|
2ac4e9d9
|
2017-06-26T21:58:32
|
|
Merge branch 'master' into dev
|
|
9d64f3c6
|
2017-04-24T14:42:58
|
|
Attribute ARM runtime detection code to Nokia
This code was submitted in the initial ARM NEON patches
(https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he
was still a Nokia employee.
|
|
8a9b042b
|
2016-12-10T09:35:30
|
|
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
|
|
786b6493
|
2016-12-05T12:39:49
|
|
Reorg AltiVec detection code
+ advertise that full AltiVec SIMD acceleration is now available on
OpenBSD.
The relevant compilers probably all support C99 or GNU's variation of
C90 that allows variables to be declared anywhere, but our policy is to
conform to the C90 standard, if for no other reason than that it
improves code readability.
|
|
f4ba09b3
|
2016-12-03T15:46:49
|
|
Detect AltiVec support on OpenBSD
|
|
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/
|
|
9fdb8f85
|
2016-11-22T09:33:19
|
|
Merge branch 'master' into dev
|
|
4ad94b29
|
2016-11-18T19:03:28
|
|
Detect AltiVec support on AmigaOS 4
|
|
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
|
|
ed21f4bd
|
2016-10-05T14:41:14
|
|
Merge branch 'master' into dev
|
|
f34f2f5b
|
2016-10-05T13:36:35
|
|
Fix 'make dist'
|
|
7bfb22af
|
2016-09-26T17:59:14
|
|
Fix broken MIPS build
Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152
Fixes #104
|
|
6c365686
|
2016-09-20T18:09:15
|
|
Merge branch 'master' into dev
|
|
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
|
|
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.
|
|
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
|
|
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.
|
|
1be87b62
|
2016-07-11T19:42:37
|
|
Reformat jsimdcpu[-64].asm to improve readability
|
|
b331385e
|
2016-07-11T13:11:25
|
|
Merge branch 'master' into dev
|
|
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
|
|
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.
|
|
e06ccbe3
|
2016-07-08T13:00:13
|
|
64-bit AVX2: Fix bug in IS_ALIGNED_AVX() macro
32 = 1 << 5, not 1 << 8
|
|
67de29b5
|
2016-07-07T22:04:25
|
|
32-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
|
|
c22e42e9
|
2016-07-07T20:36:15
|
|
Optimize 64-bit AVX2 h2v2 fancy upsampler
Reduce register usage and eliminate unnecessary mov instructions
|
|
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
|
|
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.)
|
|
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.
|
|
7ee3ce9a
|
2016-07-05T16:19:26
|
|
Lay the groundwork for 32-bit AVX2 SIMD support
|
|
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.
|
|
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
|
|
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.
|
|
ff5685d5
|
2016-05-27T16:58:23
|
|
Reformat SSE/SSE2 SIMD code to improve readability
|
|
123f7258
|
2016-05-24T10:23:56
|
|
Format copyright headers more consistently
The IJG convention is to format copyright notices as:
Copyright (C) YYYY, Owner.
We try to maintain this convention for any code that is part of the
libjpeg API library (with the exception of preserving the copyright
notices from Cendio's code verbatim, since those predate
libjpeg-turbo.)
Note that the phrase "All Rights Reserved" is no longer necessary, since
all Buenos Aires Convention signatories signed onto the Berne Convention
in 2000. However, our convention is to retain this phrase for any files
that have a self-contained copyright header but to leave it off of any
files that refer to another file for conditions of distribution and use.
For instance, all of the non-SIMD files in the libjpeg API library refer
to README.ijg, and the copyright message in that file contains "All
Rights Reserved", so it is unnecessary to add it to the individual
files.
The TurboJPEG code retains my preferred formatting convention for
copyright notices, which is based on that of VirtualGL (where the
TurboJPEG API originated.)
|
|
2e480fa2
|
2016-05-03T10:33:43
|
|
ARMv7 SIMD: Fix clang compatibility (Part 2)
GCC does support UAL syntax (strbeq) if the ".syntax unified" directive
is supplied. This directive is supported by all versions of GCC and
clang going back to 2003, so it should not create any backward
compatibility issues.
Based on https://github.com/mattsarett/libjpeg-turbo/commit/1264349e2fa6f098178c37abfa7b059ad8b405a2
Closes #76
|
|
5e576386
|
2016-05-02T12:31:51
|
|
ARMv7 SIMD: Fix clang compatibility
By design, clang only supports Unified Assembler Language (and not
pre-UAL syntax):
https://llvm.org/bugs/show_bug.cgi?id=23507
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html
Thus, clang only supports the strbeq instruction and not streqb, but
unfortunately some versions of GCC only support streqb. Go, go
Gadget #ifdef...
Based on https://github.com/mattsarett/libjpeg-turbo/commit/a82e63aac63f8fa3
95fa4caad4de6859623ee2e2
Closes #75
|
|
056536f6
|
2016-02-29T17:21:02
|
|
Win/x64: Fix improper callee save of xmm8-xmm11
The x86-64 SIMD accelerations for Huffman encoding used incorrect
stack math to save xmm8-xmm11 on Windows. This caused TJBench to
always report 1 Mpixel/sec for the compression performance, and it
likely would have caused other application issues as well.
|
|
bd49803f
|
2016-02-19T08:53:33
|
|
Use consistent/modern code formatting for pointers
The convention used by libjpeg:
type * variable;
is not very common anymore, because it looks too much like
multiplication. Some (particularly C++ programmers) prefer to tuck the
pointer symbol against the type:
type* variable;
to emphasize that a pointer to a type is effectively a new type.
However, this can also be confusing, since defining multiple variables
on the same line would not work properly:
type* variable1, variable2; /* Only variable1 is actually a
pointer. */
This commit reformats the entirety of the libjpeg-turbo code base so
that it uses the same code formatting convention for pointers that the
TurboJPEG API code uses:
type *variable1, *variable2;
This seems to be the most common convention among C programmers, and
it is the convention used by other codec libraries, such as libpng and
libtiff.
|
|
8632f1b2
|
2016-02-09T00:38:58
|
|
ARM64: Avoid tbl instruction on Cortex-A53/A57
Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 0.91-3.0% (avg. 1.8%)
Cortex-A57 (Nexus 5X), Android, 64-bit: -0.35-1.5% (avg. 0.65%)
|
|
28f00bf2
|
2016-02-08T15:15:11
|
|
Fix iOS/ARMv8 build
Broken by 46ecffa324be43aab80f6160dc57d98b0a54a704.
gas-preprocessor.pl and/or the clang assembler apparently don't like
default values in macro arguments, and we need to use a separate const
section for each function (because of our use of adr, also necessitated
by the broken clang assembler.)
|
|
53c635b8
|
2016-02-08T14:03:13
|
|
Fix 'make dist'; Include LICENSE.md in packages
|
|
46ecffa3
|
2016-02-07T22:05:56
|
|
ARM64: Avoid LD3/ST3 at run time, not compile time
... and only if ThunderX is detected. This can be easily expanded later
on to include other CPUs that are known to suffer from slow LD3/ST3, but
it doesn't make sense to disable LD3/ST3 for all non-Android Linux
platforms just because ThunderX is slow.
|
|
219470d6
|
2016-02-07T20:36:02
|
|
ARM64 NEON SIMD implementation of Huffman encoding
Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 1.1-13% (avg. 6.0%)
Cortex-A57 (Nexus 5X), Android, 64-bit: 0.0-22% (avg. 6.3%)
Refer to #47 and #50 for discussion
Closes #50
Note that this commit introduces a similar /proc/cpuinfo parser to that
of the ARM32 implementation. It is used to specifically check whether
the code is running on Cavium ThunderX and, if so, disable the ARM64
SIMD Huffman routines (which slow performance by an average of 8% on
that CPU.)
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/a8c282e5e5ac10a715d6d6a9ab22121982b485f6
|