kc3-lang/libjpeg-turbo/simd/powerpc
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
e69dd40c | 2024-01-23 13:26:41 | Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226 | |
|
78a36f6d | 2022-11-15 17:01:17 | Fix buffer overrun in 12-bit prog Huffman encoder Regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8 and 5b177b3cab5cfb661256c1e74df160158ec6c34e The pre-computed absolute values used in encode_mcu_AC_first() and encode_mcu_AC_refine() were stored in a JCOEF (signed short) array. When attempting to losslessly transform a specially-crafted malformed 12-bit JPEG image with a coefficient value of -32768 into a progressive 12-bit JPEG image, the progressive Huffman encoder attempted to store the absolute value of -32768 in the JCOEF array, thus overflowing the 16-bit signed data type. Therefore, at this point in the code: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L889 the absolute value was read as -32768, which caused the test at https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L896 to fail, falling through to https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L908 with an overly large value of r (46) that, when shifted left four places, incremented, and passed to emit_symbol(), exceeded the maximum index (255) for the derived code tables. Fortunately, the buffer overrun was fully contained within phuff_entropy_encoder, so the issue did not generate a segfault or other user-visible errant behavior, but it did cause a UBSan failure that was detected by OSS-Fuzz. This commit introduces an unsigned JCOEF (UJCOEF) data type and uses it to store the absolute values of DCT coefficients computed by the AC_first_prepare() and AC_refine_prepare() methods. Note that the changes to the Arm Neon progressive Huffman encoder extensions cause signed 16-bit instructions to be replaced with equivalent unsigned 16-bit instructions, so the changes should be performance-neutral. Based on: https://github.com/mayeut/libjpeg-turbo/commit/bbf61c0382c4f8bd1f1cfc666467581496c2fb7c Closes #628 | |
|
f579cc11 | 2022-10-03 19:46:09 | Make SIMD capability variables thread-local ... ... on platforms that support TLS, which should include all currently-supported platforms (https://libjpeg-turbo.org/Documentation/OfficialBinaries) Addresses a concern raised in #87 Although it is still my opinion that the data race in init_simd() was innocuous, we can now fix it for free thanks to ae87a958613b69628b92088b313ded0d4f59a716, so why not? | |
 |
59337a67 | 2022-07-06 12:11:50 | PowerPC: Detect AltiVec support on OS X libjpeg-turbo's AltiVec SIMD extensions previously assumed that AltiVec instructions were available on all Power Macs that supported OS X 10.4 "Tiger" (the earliest version of OS X that libjpeg-turbo has ever supported), but Tiger can actually run on PowerPC G3 processors, which lack AltiVec instructions. This commit enables run-time detection of AltiVec instructions on OS X/PowerPC systems if AltiVec instructions are not force-enabled at compile time (using -maltivec). This allows the same build of libjpeg-turbo to support G3, G4, and G5 Power Macs. Closes #609 | |
|
9abeff46 | 2022-03-09 11:48:30 | Remove extraneous #include directives jinclude.h already includes stdio.h, stdlib.h, and string.h. | |
 |
d401d625 | 2021-10-27 03:39:09 | PowerPC: Detect AltiVec support on FreeBSD Recent FreeBSD/PowerPC compilers, such as Clang 11.0.x on FreeBSD 13, do the equivalent of passing -maltivec to the compiler by default, so run-time AltiVec detection is unnecessary. However, it becomes necessary when using other compilers or when passing -mno-altivec to the compiler. Closes #552 | |
|
7c1a1789 | 2020-11-05 16:04:55 | Merge branch 'master' into dev | |
|
6e632af9 | 2020-11-04 10:13:06 | Demote "fast" [I]DCT algorithms to legacy status - Refer to the "slow" [I]DCT algorithms as "accurate" instead, since they are not slow under libjpeg-turbo. - Adjust documentation claims to reflect the fact that the "slow" and "fast" algorithms produce about the same performance on AVX2-equipped CPUs (because of the dual-lane nature of AVX2, it was not possible to accelerate the "fast" algorithm beyond what was achievable with SSE2.) Also adjust the claims to reflect the fact that the "fast" algorithm tends to be ~5-15% faster than the "slow" algorithm on non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo SIMD extensions. - Indicate the legacy status of the "fast" and float algorithms in the documentation and cjpeg/djpeg usage info. - Remove obsolete paragraph in the djpeg man page that suggested that the float algorithm could be faster than the "fast" algorithm on some CPUs. | |
|
01e30323 | 2019-01-23 14:58:24 | Eliminate support for compilers w/o unsigned char libjpeg-turbo has never really supported such compilers, since (AFAIK) they are non-existent on any modern computing platform and thus impossible for us to test. (Also, the TurboJPEG API would break without unsigned chars.) Furthermore, the unified CMake-based build system introduced in 2.0 always defines HAVE_UNSIGNED_CHAR, so retaining other code paths is pointless. Eliminating support for compilers without unsigned char eliminates the need for the GETJSAMPLE() macro, which improves the readability of many parts of the code as well as improving the performance of writing Targa and Windows BMP files. Fixes #317 | |
|
7b3c0f01 | 2018-03-31 13:25:44 | PowerPC: Fix comp. warning when built w/ -maltivec |