|
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.
|
|
|
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
|
|
4ad94b29
|
2016-11-18T19:03:28
|
|
Detect AltiVec support on AmigaOS 4
|
|
|
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
|
|
|
7bfb22af
|
2016-09-26T17:59:14
|
|
Fix broken MIPS build
Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152
Fixes #104
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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
|
|
|
15aaa7f7
|
2016-02-07T17:39:33
|
|
ARM SIMD: Comment tweaks
|
|
|
cf888486
|
2016-02-02T23:17:06
|
|
Use consistent formatting in ARM NEON SIMD code
There aren't really any best practices to follow here. I tried as best
as I could to adopt a standard that would ease any future maintenance
burdens. The basic tenets of that standard are:
* Assembly instructions always start on Column 5, and operands always
start on Column 21, except:
- The instruction and operand can be indented (usually by 2 spaces)
to indicate a separate instruction stream.
- If the instruction is within an enclosing .if block in a macro,
it should always be indented relative to the .if block.
* Comments are placed with an eye toward readability. There are always
at least 2 spaces between the end of a line of code and the associated
in-line comment. Where it made sense, I tried to line up the comments
in blocks, and some were shifted right to avoid overlap with
neighboring instruction lines. Not an exact science.
* Assembler directives and macros use 2-space indenting rules. .if
blocks are indented relative to the macro, and code within the .if
blocks is indented relative to the .if directive.
* No extraneous spaces between operands. Lining up the operands
vertically did not really improve readability-- personally, I think it
made it worse, since my eye would tend to lose its place in the
uniform columns of characters. Also, code with a lot of vertical
alignment is really hard to maintain, since changing one line could
necessitate changing a bunch of other lines to avoid spoiling the
alignment.
* No extraneous spaces in #defines or other directives. In general, the
only extraneous spaces (other than indenting spaces) are between:
- Instructions and operands
- Operands and in-line comments
This standard should be more or less in keeping with other formatting
standards used within the project.
|
|
|
cb49bb00
|
2016-02-02T23:10:27
|
|
Opt. ARM64 SIMD decompr. for in-order pipelines
Decompression speedup relative to libjpeg-turbo 1.4.2 (ISLOW IDCT):
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 60-113% (avg. 86%)
Cortex-A53 (Nexus 5X), Android, 64-bit: 6.8-27% (avg. 14%)
Cortex-A57 (Nexus 5X), Android, 64-bit: 2.0-14% (avg. 6.8%)
Decompression speedup relative to libjpeg-turbo 1.4.2 (IFAST IDCT):
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 51-98% (avg. 75%)
Minimal speedup (1-5%) observed on iPhone 5S (Cortex-A7)
NOTE: This commit avoids the st3 instruction for non-Android and
non-Apple builds, which may cause a performance regression against
libjpeg-turbo 1.4.x on ARM64 systems that are running plain Linux.
Since ThunderX is the only platform known to suffer from slow ld3 and
st3 instructions, it is probably better to check for the CPU type
at run time and disable ld3/st3 only if ThunderX is detected.
This commit also enables the use of ld3 on Android platforms, which
should be a safe bet, at least for now. This speeds up compression on
the afore-mentioned Nexus Cortex-A53 by 5.5-19% (avg. 12%) and on the
Nexus Cortex-A57 by 1.2-14% (avg. 6.3%), relative to the previous
commits.
This commit also removes unnecessary macros.
Refer to #52 for discussion.
Closes #52.
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/6bad905034e6e73b33ebf07a74a6b72f58319f62
https://github.com/mayeut/libjpeg-turbo/commit/488dd7bf1726e2f6af6e9294ccf77b729fec1f20
https://github.com/mayeut/libjpeg-turbo/commit/4f4d057c1fb31d643536e6effb46a5946e15c465
https://github.com/mayeut/libjpeg-turbo/commit/d3198afc43450989a4fc63d2dcbe3272c8a0a3c1
|
|
|
d38b4f21
|
2016-01-16T01:53:32
|
|
Optimize ARM64 SIMD code for Cavium ThunderX
Per @ssvb:
ThunderX is an ARM64 chip that dedicates most of its transistor real
estate to providing 48 cores, so each core is not as fast as a result.
Each core is dual-issue & in-order for scalar instructions and has only
a single-issue half-width NEON unit, so the peak throughput is one
128-bit instruction per 2 cycles. So careful instruction scheduling is
important. Furthermore, ThunderX has an extremely slow implementation
of ld2 and ld3, so this commit implements the equivalent of those
instructions using ld1.
Compression speedup relative to libjpeg-turbo 1.4.2:
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 58-85% (avg. 74%)
relative to jpeg-6b: 1.75-2.14x (avg. 1.95x)
Refer to #49 and #51 for discussion.
Closes #51.
This commit also wordsmiths the ChangeLog entry (the ARMv8 SIMD
implementation is "complete" only for compression-- it still lacks some
decompression algorithms, as does the ARMv7 implementation.)
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/9405b5fd031558113bdfeae193a2b14baa589a75
which is based on:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/f561944ff70adef65bb36212913bd28e6a2926d6
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/962c8ab21feb3d7fc2a7a1ec8d26f6b985bbb86f
|
|
|
e8aa5fa9
|
2016-01-15T13:15:54
|
|
Add JSIMD_NOHUFFENC environment variable for ARM
Useful in regression/performance testing
|
|
|
ec6941f7
|
2016-01-15T09:29:11
|
|
Complete the ARM64 NEON SIMD implementation
This adds 64-bit NEON coverage for all of the algorithms that are
covered by the 32-bit NEON implementation, except for h2v1 (4:2:2) fancy
upsampling (used when decompressing 4:2:2 JPEG images.) It also adds
64-bit NEON SIMD coverage for:
* slow integer forward DCT (compressor)
* h2v2 (4:2:0) downsampling (compressor)
* h2v1 (4:2:2) downsampling (compressor)
which are not covered in the 32-bit implementation.
Compression speedups relative to libjpeg-turbo 1.4.2:
Apple A7 (iPhone 5S), iOS, 64-bit: 113-150% (reported)
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 2.1-33% (avg. 15%)
Refer to #44 and #49 for discussion
This commit also removes the unnecessary
if (simd_support & JSIMD_ARM_NEON)
statements from the jsimd* algorithm functions. Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available.
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/dcd9d84f10fae192c0e3935818dc289bca9c3e29
https://github.com/mayeut/libjpeg-turbo/commit/b0d87b811f37bd560083deea8c6e7d704e5cd944
https://github.com/mayeut/libjpeg-turbo/commit/70cd5c8a493a67f4d54dd2067ae6dedb65d95389
https://github.com/mayeut/libjpeg-turbo/commit/3e58d9a064648503c57ec2650ee79880f749a52b
https://github.com/mayeut/libjpeg-turbo/commit/837b19542f53fa81af83e6ba002d559877aaf597
https://github.com/mayeut/libjpeg-turbo/commit/73dc43ccc870c2e10ba893e9764b8e48d6836585
https://github.com/mayeut/libjpeg-turbo/commit/a82b71a261b4c0213f558baf4bc745f1c27356d8
https://github.com/mayeut/libjpeg-turbo/commit/c1b1188c2106d6ea7b76644b6023b57edeb602e1
https://github.com/mayeut/libjpeg-turbo/commit/305c89284e1bb222b34fbc7261f697a0cc452a41
https://github.com/mayeut/libjpeg-turbo/commit/7f443f99950b4d7d442b9b879648eca5273209bd
https://github.com/mayeut/libjpeg-turbo/commit/4c2b53b77da5a20e30e2aadaeddb0efbfe24e06d
Unified version with fixes:
https://github.com/mayeut/libjpeg-turbo/commit/1004a3cd05870612a194b410efeaa1b4da76d246
|
|
|
499c470b
|
2016-01-13T03:13:20
|
|
ARM32 NEON SIMD implementation of Huffman encoding
Full-color compression speedups relative to libjpeg-turbo 1.4.2:
800 MHz ARM Cortex-A9, iOS, 32-bit: 26-44% (avg. 32%)
Refer to #42 and #47 for discussion.
This commit also removes the unnecessary
if (simd_support & JSIMD_ARM_NEON)
statements from the jsimd* algorithm functions. Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available. Removing those
if statements improved performance across the board by a couple of
percent.
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/fc023c880ce1d6c908fb78ccc25f5d5fd910ccc5
|
|
|
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
|
|
|
368cd52d
|
2016-01-11T22:03:16
|
|
Allow JSIMD_FORCENONE=1 env to disable x86-64 SIMD
Traditionally, the x86-64 code did not call init_simd() because it had
no need to (only SSE2 was supported.) However, having the ability to
disable SIMD at run time is a useful testing tool, and all of the other
SIMD implementations have this ability.
|
|
|
fbe5007f
|
2015-12-19T14:29:46
|
|
Merge branch '1.4.x'
|
|
|
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
|
|
|
d70a5c12
|
2015-12-14T16:59:43
|
|
Remove unnecessary .arch directive in ARM64 code
This directive was preventing the code from assembling using the
integrated assembler in clang.
Fixes #33
|
|
|
1e32fe31
|
2015-10-14T17:32:39
|
|
Replace INT32 with a new internal datatype (JLONG)
These days, INT32 is a commonly-defined datatype in system headers. We
cannot eliminate the definition of that datatype from jmorecfg.h, since
the INT32 typedef has technically been part of the libjpeg API since
version 5 (1994.) However, using INT32 internally is risky, because the
inclusion of a particular header (Xmd.h, for instance) could change the
definition of INT32 from long to int on 64-bit platforms and thus change
the internal behavior of libjpeg-turbo in unexpected ways (for instance,
failing to correctly set __INT32_IS_ACTUALLY_LONG to match the INT32
typedef-- perhaps as a result of including the wrong version of
jpeglib.h-- could cause libjpeg-turbo to produce incorrect results.)
The library has always been built in environments in which INT32 is
effectively long (on Windows, long is always 32-bit, so effectively it's
the same as int), so it makes sense to turn INT32 into an explicitly
long datatype. This ensures that libjpeg-turbo will always behave
consistently, regardless of the headers included at compile time.
Addresses a concern expressed in #26.
|
|
|
7e3acc0e
|
2015-10-10T10:25:46
|
|
Rename README, LICENSE, BUILDING text files
The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.
|
|
|
b961f0bf
|
2015-09-16T23:16:38
|
|
Merge branch '1.4.x'
|
|
54792ba3
|
2015-09-16T23:05:46
|
|
Fix MIPS DSPr2 4:2:0 upsample bug w/ small images
The DSPr2 code was errantly comparing the residual (t9, width & 0xF)
with the end pointer (t4, out + width) instead of the width directly
(a1). This would give the wrong results with any image whose output
width was less than 16. The other small changes (ulw to lw and removal
of the nop) are just some easy optimizations around this code.
This issue caused a buffer overrun and subsequent segfault on images
whose scaled output height was 1 pixel and whose scaled output width was
< 16 pixels. Note that the "plain" (non-fancy and non-merged) upsample
routine, which was affected by this bug, is normally not used except
when decompressing a non-YCbCr JPEG image, but it is also used when
decompressing a single-row image (because the other upsampling
algorithms require at least two rows.)
Closes #16.
|
|
498d9bc9
|
2015-09-15T11:57:03
|
|
Fix x86-64 ABI conformance issue in SIMD code
(descriptions cribbed by DRC from discussion in #20)
In the x86-64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use a 64-bit mov
instruction to transfer a JDIMENSION argument in the 64-bit SSE2 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-- for the past
6 years, on every x86-64 compiler previously known to mankind.
The bleeding-edge Clang/LLVM compiler has 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.
Also enhance the documentation of JDIMENSION to explain that its size
is significant to the implementation of the SIMD code.
Closes #20. Refer also to http://crbug.com/532214.
|
|
|
f62dbccf
|
2015-08-15T13:30:14
|
|
Fix build error when compiling MIPS SIMD w/ -mfpxx
When compiled with -mfpxx (which is now the default on Debian), there are
some restrictions on the use of odd-numbered FP registers. More details
about FPXX can be found here:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
This commit simply changes all uses of FP registers to an even-numbered
equivalent like this:
f0 -> f0
f1 -> f2
f2 -> f4
...
f8 -> f16
This commit should have no observable effect except that the MIPS assembly
will now compile with -mfpxx.
Closes #11
|
|
691cd933
|
2015-06-20T16:36:32
|
|
Fix 'make dist'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1574 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
89b5e06d
|
2015-06-20T16:20:53
|
|
Studies show that GCC v5.1.0 performs as well as or better than v4.2, but v4.7.x-v4.9.x do not perform as well as v4.2.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1571 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eea64245
|
2015-06-20T15:51:34
|
|
Typo
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1570 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f15ef337
|
2015-06-08T17:41:34
|
|
Fix a segfault that occured in the MIPS DSPr2 fancy upsampling routine when downsampled_width==3. Because the DSPr2 code unrolls the loop for the middle columns (refer to jdsample.c), it has the effect of performing two column iterations, and that only works properly if the number of columns (minus the first and last) is >= 2. For the specific case of downsampled_width==3, this patch skips to the second iteration of the unrolled column loop.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1562 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3b7015d5
|
2015-02-23T19:03:29
|
|
Enable silent build rules for the NASM objects, if the source is configured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.")
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1534 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
771ab194
|
2015-02-20T19:57:21
|
|
Extend the AltiVec VMX SIMD routines to support little endian PowerPC platforms.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1529 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3f760834
|
2015-01-28T00:25:43
|
|
Come on, Cohaagen, you got what you want. Give these people air!
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1527 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8b5a0093
|
2015-01-21T17:42:28
|
|
Oops. The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1523 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
246b01bb
|
2015-01-16T03:13:16
|
|
Revert r1506 (we actually are generating columns with the IDCT, so the naming makes sense in retrospect); further de-confusification in the forward DCT
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1507 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c4e3c361
|
2015-01-15T08:51:31
|
|
De-confusify the variable names a bit -- "out" represents the output of the IDCT kernel, so use "final" to represent the packed data that will be stored to memory.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1506 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c641cddb
|
2015-01-14T15:41:11
|
|
AltiVec SIMD implementation of H2V1 and H2V2 plain upsampling (used only when decompressing YCCK images with fast upsampling enabled.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1504 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
86af36ae
|
2015-01-14T13:27:32
|
|
AltiVec SIMD implementation of H2V1 and H2V2 merged upsampling
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1503 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
11c4010c
|
2015-01-14T13:07:06
|
|
Fix an overread detected by valgrind
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1502 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2517ef72
|
2015-01-14T10:45:31
|
|
Fix bugs in the AltiVec fancy upsampling routines uncovered during additional testing with small image sizes. Since the input width is half the output width, the upsampler should only write a second 16-byte chuck if there are more than 8 input columns left. Additionally, if the width is < 16, then we need to insert a dummy sample (the SSE2 code does this as well, but I neglected to port that portion of the code for some reason.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1501 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cbcb5361
|
2015-01-14T08:31:54
|
|
Fix a bug in the AltiVec downsampling routines uncovered during additional testing with small image sizes. Since the output width is half the input width, the downsampler should only read a second 16-byte chunk if there are more than 8 output columns left.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1499 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ada430bb
|
2015-01-13T11:49:15
|
|
Make the formatting and naming of variables and constants more consistent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1498 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
406bb01c
|
2015-01-13T11:47:20
|
|
Make the formatting and naming of variables and constants more consistent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1497 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a6a24c27
|
2015-01-13T10:00:12
|
|
Make the formatting and naming of variables and constants more consistent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1496 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
52a4ec6c
|
2015-01-13T09:02:29
|
|
AltiVec SIMD implementation of H2V1 and H2V2 fancy upsampling
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1495 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
51eba060
|
2015-01-11T07:38:35
|
|
Minor code readability tweak
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1492 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d71a6e0c
|
2015-01-11T06:34:47
|
|
Use intrinsics for loading aligned data in the IDCT functions. This has no effect on performance, but it makes it more obvious what that code is doing.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1491 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ac4daa77
|
2015-01-10T22:56:26
|
|
AltiVec SIMD implementation of YCC-to-RGB color conversion
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1489 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
af69295d
|
2015-01-10T12:25:42
|
|
Fix minor issue in code comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1488 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6aed1129
|
2015-01-10T12:10:08
|
|
Fix minor issue in code comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1487 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a5005751
|
2015-01-10T12:09:11
|
|
Simplify the code somewhat. It actually wasn't necessary to have a "fast path" and a "medium path"-- they perform the same.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1486 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
25347882
|
2015-01-10T11:32:36
|
|
Overhaul the AltiVec vector loading code in the compression-side colorspace conversion routines. The existing code was sometimes overreading the source buffer (at least according to valgrind), and it was necessary to increase the complexity of the code in order to prevent this without significantly compromising performance.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1485 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8de75d0f
|
2015-01-08T10:42:54
|
|
Fix minor issue in code comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1484 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
22048207
|
2015-01-08T06:18:33
|
|
AltiVec SIMD implementation of 2x1 and 2x2 downsampling
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1483 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
577ecd93
|
2014-12-23T04:14:54
|
|
AltiVec SIMD implementation of sample conversion and integer quantization
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1474 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ff30c639
|
2014-12-23T02:42:59
|
|
Document the fact that the AltiVec implementation uses the same modified algorithms as the SSE2 implementation
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1473 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
45453085
|
2014-12-22T16:04:17
|
|
Use intrinsics for loading/storing data in the DCT/IDCT functions. This has no effect on the performance of the aligned loads/stores, but it makes it more obvious what that code is doing. Using intrinsics for the unaligned stores in the inverse DCT functions increases overall decompression performance by 1-2%.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1472 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b1fec4ff
|
2014-12-22T14:10:33
|
|
AltiVec SIMD implementation of RGB-to-Grayscale color conversion
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1471 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5976e425
|
2014-12-22T13:57:30
|
|
Remove unneeded code; Make sure jccolor-altivec.o will be rebuilt if jccolext-altivec.c changes.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1470 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
62bae204
|
2014-12-22T13:42:26
|
|
AltiVec SIMD implementation of RGB-to-YCC color conversion
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1469 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
13af1396
|
2014-12-22T01:38:01
|
|
Make comments more consistent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1466 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bf8a5feb
|
2014-12-22T01:10:11
|
|
Cosmetic tweaks to the PowerPC SIMD stubs
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1464 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
535674b1
|
2014-12-22T01:00:42
|
|
Split AltiVec algorithms into separate files for ease of maintenance; Rename constants using lowercase so they are not confused with macros
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1463 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c9da7852
|
2014-12-20T03:32:59
|
|
Optimizations to the AltiVec DCT algorithms (pre-compute constants and combine multiply/add operations)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1462 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0691162a
|
2014-12-20T01:17:39
|
|
AltiVec SIMD implementation of slow integer inverse DCT
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1461 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
9cb418d2
|
2014-12-20T01:16:26
|
|
Use macros to allocate constants statically, rather than reading them from a table using vec_splat*(). This improves code readability and probably improves performance a bit as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1460 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
935d1d63
|
2014-12-20T01:14:38
|
|
Swap the order of the IFAST and ISLOW FDCT functions so that it matches the order of the prototypes in jsimd.h and the stubs in jsimd_powerpc.c.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1459 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
86ae5913
|
2014-12-19T18:28:00
|
|
Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1458 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
62999d77
|
2014-12-19T15:36:39
|
|
Modify the ARM64 assembly file so that it uses only syntax that the clang assembler in XCode 5.x can understand. These changes should all be cosmetic in nature-- they do not change the meaning or readability of the code nor the ability to build it for Linux. Actually, the code is now more in compliance with the ARM64 programming manual. In addition to these changes, there were a couple of instructions that clang simply doesn't support, so gas-preprocessor.pl was modified so that it now converts those into equivalent instructions that clang can handle.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1450 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6cb7f40a
|
2014-12-18T10:12:29
|
|
AltiVec SIMD implementation of fast integer inverse DCT
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1445 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
040435af
|
2014-12-18T09:49:39
|
|
Further cleanup of the AltiVec forward DCT code:
-- Use macros to represent the fast FDCT constants, to facilitate comparing the AltiVec implementation of the algorithm with the SSE2 implementation.
-- Rename slow FDCT constants for consistency.
-- Use vec_sra() in all cases in the slow FDCT code. The SSE2 implementation uses psraw, which is an arithmetic shift, so we need to do likewise with AltiVec. Using vec_sr() hasn't caused any problems yet, but it is conceivable that it might cause different behavior in certain corner cases.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1444 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fb0c3940
|
2014-12-17T08:04:39
|
|
AltiVec SIMD implementation of slow integer forward DCT; Clean up fast integer forward DCT code so that it is easier to see how it derives from the SSE2 code and to make it play more nicely with the slow FDCT code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1443 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e1ac4010
|
2014-12-17T08:00:29
|
|
Fix cosmetic issues in AltiVec comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1442 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
7affbfc2
|
2014-09-05T07:23:12
|
|
The AltiVec code actually works on 32-bit PowerPC platforms as well, so change the "powerpc64" token to "powerpc". Also clean up the shift code, which wasn't building properly on OS X.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1406 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cd2d8e1c
|
2014-09-05T06:33:42
|
|
AltiVec SIMD implementation of fast forward DCT
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1405 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0a9a2526
|
2014-08-29T01:53:17
|
|
Rename the ARM64 assembly file to match the C file
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1390 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
de26249a
|
2014-08-29T01:49:59
|
|
Fix several mathematical issues discovered in the ARM64 NEON code while running the extended regression tests introduced in r1267. Specific comments can be found in the original patches:
https://sourceforge.net/p/libjpeg-turbo/patches/64/
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1389 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a6efae14
|
2014-08-25T15:26:09
|
|
Reformat code per Siarhei's original patch (to clearly indicate that the offset instructions are completely independent) and add Siarhei as an individual author (he no longer works for Nokia.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1388 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bdc7650b
|
2014-08-23T15:57:38
|
|
ARM64 NEON SIMD support for YCC-to-RGB565 conversion
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1386 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d729f4da
|
2014-08-23T15:47:51
|
|
ARM NEON SIMD support for YCC-to-RGB565 conversion, and optimizations to the existing YCC-to-RGB conversion code:
-----
https://github.com/ssvb/libjpeg-turbo/commit/aee36252be20054afce371a92406fc66ba6627b5.patch
From aee36252be20054afce371a92406fc66ba6627b5 Mon Sep 17 00:00:00 2001
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date: Wed, 13 Aug 2014 03:50:22 +0300
Subject: [PATCH] ARM: Faster NEON yuv->rgb conversion for Krait and Cortex-A15
The older code was developed and tested only on ARM Cortex-A8 and ARM Cortex-A9.
Tuning it for newer ARM processors can introduce some speed-up (up to 20%).
The performance of the inner loop (conversion of 8 pixels) improves from
~27 cycles down to ~22 cycles on Qualcomm Krait 300, and from ~20 cycles
down to ~18 cycles on ARM Cortex-A15.
The performance remains exactly the same on ARM Cortex-A7 (~58 cycles),
ARM Cortex-A8 (~25 cycles) and ARM Cortex-A9 (~30 cycles) processors.
Also use larger indentation in the source code for separating two independent
instruction streams.
-----
https://github.com/ssvb/libjpeg-turbo/commit/a5efdbf22ce9c1acd4b14a353cec863c2c57557e.patch
From a5efdbf22ce9c1acd4b14a353cec863c2c57557e Mon Sep 17 00:00:00 2001
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date: Wed, 13 Aug 2014 07:23:09 +0300
Subject: [PATCH] ARM: NEON optimized yuv->rgb565 conversion
The performance of the inner loop (conversion of 8 pixels):
* ARM Cortex-A7: ~55 cycles
* ARM Cortex-A8: ~28 cycles
* ARM Cortex-A9: ~32 cycles
* ARM Cortex-A15: ~20 cycles
* Qualcomm Krait: ~24 cycles
Based on the Linaro rgb565 patch from
https://sourceforge.net/p/libjpeg-turbo/patches/24/
but implements better instructions scheduling.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1385 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
55e328ec
|
2014-08-22T18:30:44
|
|
Revert r1335 and r1336. It was a valiant effort, but on Windows, xmm8-xmm15 are non-volatile, and the overhead of pushing them onto the stack at the beginning of each function and popping them at the end was causing worse performance (in the neighborhood of 3-5%) than just using the work areas and limiting the register usage to xmm0-xmm7. Best to leave the SSE2 code alone. We can optimize the register usage for AVX2, once that port takes place.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1382 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2e2ce5a1
|
2014-08-22T11:31:46
|
|
.func/.endfunc are only necessary when generating STABS debug info, which basically went out of style with parachute pants and Rick Astley. At any rate, none of the platforms for which we're building the ARM code use it (DWARF is the common format these days), and the .func/.endfunc directives cause the clang integrated assembler to fail (http://llvm.org/bugs/show_bug.cgi?id=20424).
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1375 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8a74848a
|
2014-08-09T22:58:18
|
|
Oops. The Windows version of collect_args/uncollect_args uses rsp, so we still need the rsp prologue/epilogue, despite the fact that we aren't using the stack as a work area. This fixes a segfault on Windows caused by r1335.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1336 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a8ab3424
|
2014-08-09T14:30:28
|
|
Attempt to improve performance by refactoring the compression-side color conversion and DCT algorithms so that they take full advantage of the additional registers available with 64-bit SSE2. This produces a somewhat yawn-worthy speedup of 2-3%, but at least the code is a lot more readable now.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1335 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3728aa01
|
2014-07-23T14:14:14
|
|
Fix performance and other issues uncovered in testing with actual ARM64 hardware; formatting tweaks; remove NEON platform check (NEON is always available with ARMv8)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1333 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
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
|
|
|
495e4342
|
2014-05-19T19:13:22
|
|
Allow for building the MIPS DSPr2 extensions if the host is mips-* as well as mipsel-*. The DSPr2 extensions are little endian, so we still have to check that the compiler defines __MIPSEL__ before enabling them. This paves the way for supporting big-endian MIPS, and in the near term, it allows the SIMD extensions to be built with Sourcery CodeBench.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1316 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5ef46305
|
2014-05-18T20:04:47
|
|
SIMD-accelerated int upsample routine for MIPS DSPr2
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1315 632fc199-4ca6-4c93-a231-07263d6284db
|