We started to get the following error in libavif's GitHub CI workflows:
CMake Error at CMakeLists.txt:8 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Change-Id: If2490208cc3e7da22ff67557c5cdd4bd9f2499ad
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6416369
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Fix errors in ARGBAttenuateRow_LASX and ARGBAttenuateRow_LSX functions
caused by changes in calculation methods.
In addition, add the option to automatically add "-mlsx" and "-mlasx" to
enable SIMD optimization when compiling with cmake on LoongArch
platform.
Bug: libyuv:913
Change-Id: I7215f5198d3fb94f981d60969dc21a483006023e
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5802829
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Ben Weiss <bweiss@google.com>
Including associated changes for adding a new scale_sme.cc file.
There is no benefit from an SVE version of this kernel for devices with
an SVE vector length of 128-bits, so skip directly to SME instead. We
do not use the ZA tile here, so this is a purely streaming-SVE (SSVE)
implementation.
Change-Id: I47d149613fbabd8c203605a809811f1a668e8fb7
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5913883
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Justin Green <greenjustin@google.com>
Including addition of a new row_sme.cc file and associated
infrastructure.
The actual implementation in this case is a pure streaming-SVE (SSVE)
implementation based on the existing SVE2 implementation, we do not use
the ZA tile.
Change-Id: Ibc132c55de8d41a107e563b95f842323fef94444
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5913881
Reviewed-by: Justin Green <greenjustin@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
The original code
INSTALL ( PROGRAMS ${CMAKE_BINARY_DIR}/yuvconvert ...)
fails on Windows because it is missing the .exe file extension. Change
it to install( TARGETS yuvconvert ...) based on CMake documentation:
[The PROGRAMS form] is intended to install programs that are not
targets, such as shell scripts. Use the TARGETS form to install
targets built within the project.
Note that this change was first made in the cmake-mingw.patch file in
the mingw-w64-libyuv package:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libyuv
Change-Id: Ia571aa61e136cef477f05e051fef2cfb1db4b77d
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5840469
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
This fixes builds with top-of-tree Clang for Windows; SME functions
require backing up/restoring things that Clang can't express in
Windows unwind information - see
https://github.com/llvm/llvm-project/issues/80009 for more
context (primarily about SVE).
Similar checks would also be needed for SVE and dotprod functions,
if building with older toolchains.
Change-Id: Iab3eeb0a125c3fac9814648288261a056bffc900
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5729969
Reviewed-by: Justin Green <greenjustin@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Extend both the CMake and BUILD.gn configurations to support building a
library with the Arm Scalable Matrix Extension (SME). Add an initial
(empty) rotate_sme.cc source file to populate the library for now.
Change-Id: Icd4bd6a8ce72ba132299b00c99478a18a85d869a
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5588664
Reviewed-by: Justin Green <greenjustin@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
This makes the use of this location work the same even if building
in a separate build directory; the "if (EXISTS ${GTEST_SRC_DIR}/..."
check would otherwise fail when building in a different directory.
Change-Id: I56496852972b479b9a4c3cb183c14205b0d1270c
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5444429
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Previously, we first set GTEST_SRC_DIR as a CACHE variable, which
allows the user to set it to a different value if they prefer.
Then later, if we're cross compiling, we'd override it to a
different value. But when overriding it, we'd lose the value that
the user set.
Instead set up the default value in a different CMake variable,
and set that as default value when setting up the CACHE variable.
This way, we have varying defaults, while still respecting the
user specified value, if any.
Change-Id: I7e571b6251a4d08da02c119a0aad2b1c14585e26
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5444428
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
CMAKE_SYSTEM_PROCESSOR doesn't strictly have the values "arm" or
"aarch64", it can have more varied spellings. When cross compiling,
the value is specified by the user, but when doing native compilation,
the variable gets its value from CMAKE_HOST_SYSTEM_PROCESSOR. This
variable is defined to have the value of $(uname -m) on many Unixes.
This can give values like "armv7l" on some hosts, and "arm64" on
macOS.
Thus, when checking for aarch64, also check for the spelling "arm64".
And when checking for arm, check for any string that starts with
"arm", except for "arm64".
Change-Id: I99695ee2f3439098c897ae1408605781cd0db9fd
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5444427
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Don't define HAS_*_NEON_DOTPROD for 32-bit Arm platforms, since they are
only defined in *_neon64.cc for now.
Also define -DLIBYUV_NEON=1 and pass -mfpu=neon to *_neon.cc for 32-bit
Arm platforms, since otherwise __ARM_NEON__ is not defined.
Also fix a typo: ly_lib_static should be ly_lib_name in the name of the
common object files. The existing code happens to work since they are
defined to the same thing.
Change-Id: Ibdc9e5d0391f7ff8db1ca83384e5bd45ac9950a2
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5439562
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
The existing CMakeLists.txt does not have any logic for adding
-march=... flags to enable particular architecture features for selected
files.
This commit adds support for enabling Neon dot-product and i8mm support
for the existing *_neon64.cc files, plus enabling SVE2 for the new
row_sve.cc kernels.
This commit makes no attempt to ensure that the compiler being used
actually supports these architecture flags. That is left for a later
commit.
Bug: libyuv:973
Change-Id: Ic8a39e841ef3ca43b4c209cec57740ecf342e672
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/5439554
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
1. Fix compile warning in row_rvv.cc
2. Avoid compile row_rvv.cc/scale_rvv.cc when using GCC
There is no RVV segment load & store on GCC.
Hence, avoid compiling rvv code on GCC temporarily.
3. Add several compile options to cmake build flow
-Wno-sign-compare
-Wno-unused-function
-Wunused-variable
-Wuninitialized
Bug: libyuv:956
Change-Id: I9577f98190fc9b28fb6fde65d82d0c67ce54f9ee
Signed-off-by: Bruce Lai <bruce.lai@sifive.com>
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/4615441
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
1. Fix compile error when build riscv without using vector
2. Fix run_qemu.sh misused v=true for USE_RVV=OFF case
3. [cmake] Fix warning by rename TEST to UNIT_TEST
Warning log:
CMake Warning (dev) at CMakeLists.txt:57 (if): [54/1931]
Policy CMP0064 is not set: Support new TEST if() operator. Run "cmake
--help-policy CMP0064" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
TEST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
This warning is for project developers. Use -Wno-dev to suppress it.
4. [cmake] Simplify logic for cross-build
Bug: libyuv:956
Change-Id: I120402fc7d6d86403e7d974180b81f4f9c663e36
Signed-off-by: Bruce Lai <bruce.lai@sifive.com>
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/4486239
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Signed-off-by: Bruce Lai <bruce.lai@sifive.com>
Change-Id: Ibdc742040940ee6c6402de103759f979f9429419
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/4401739
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
When `libyuv` is built with `jpeg` support it does not directly link
`libjpeg` in any form. As a result dynamic loading of the library
fails as:
>>> import pillow_avif._avif
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /usr/lib/libyuv.so: undefined symbol: jpeg_resync_to_restart
We can reproduce the same problem at build time if we build `libyuv` with
`LDFLAGS=-Wl,--no-undefined`:
[ 99%] Linking CXX executable yuvconstants
ld: CMakeFiles/yuv_shared.dir/source/mjpeg_decoder.cc.o: in function `libyuv::MJpegDecoder::MJpegDecoder()':
mjpeg_decoder.cc:(.text+0xfc): undefined reference to `jpeg_resync_to_restart'
ld: mjpeg_decoder.cc:(.text+0x136): undefined reference to `jpeg_std_error'
ld: mjpeg_decoder.cc:(.text+0x194): undefined reference to `jpeg_CreateDecompress'
The change links `libgpeg` against `libyuv` itself to make it a
self-contained library. This fixes both loading if the library
itself and fixes linking of the library against other binaries
without explicit need for passing `-ljpeg`.
Change-Id: I044acb3799920e1536bdb3388442a40d4839348b
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/4050883
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Suppress the following MSVC compiler warnings:
src\source\cpu_id.cc(140): warning C4996: 'fopen': This function or
variable may be unsafe. Consider using fopen_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
src\source\cpu_id.cc(169): warning C4996: 'fopen': This function or
variable may be unsafe. Consider using fopen_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
Note that build/config/win/BUILD.gn defines _CRT_SECURE_NO_DEPRECATE
instead. _CRT_SECURE_NO_WARNINGS is the new name of the macro. See
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=msvc-140
Bug: libyuv:939
Change-Id: I0d1715b31e672126c35e29b99f5cbf08e4338f40
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/3807104
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
These changes were landed in the android's snapshot of libyuv.
Pushing those to upstream so that they can be kept in sync.
Android changes:
http://aosp/1949358http://ag/17942984
Bug: b/241008246
Change-Id: Id0bcff13e2e6ad5a132141a50ccdfd72f551113d
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/3803131
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Mirko Bonadei <mbonadei@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@chromium.org>
Fix the follwing Ninja warning:
ninja: warning: multiple rules generate yuv.lib. builds involving this
target will not be correct; continuing anyway [-w dupbuild=warn]
Without this change, both the static library and the DLL's import
library are named "yuv.lib". With this change, the DLL's import library
is named "libyuv.lib", corresponding to the DLL name "libyuv.dll".
Bug: libyuv:939
Change-Id: I879e51b54070e5ab8cb128adb5dde765f881dbec
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/3806073
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
When detected, add the necessary defines to actually use it.
Change-Id: I540c3e11e480be8aaab154ad91ee08cdc52319de
Reviewed-on: https://chromium-review.googlesource.com/988432
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
As per the preparation patch added in Chromium sources at,
2150943003: Add MIPS SIMD Arch (MSA) build flags for GYP/GN builds
This patch adds first MSA optimized function in libYUV project.
BUG=libyuv:634
R=fbarchard@google.com
Review URL: https://codereview.chromium.org/2285683002 .
A hang in color conversion on arm occurs somewhere in yuv to rgb.
Breaking the color test into its own category of test will help
run selective tests to narrow down the issue.
R=harryjin@google.com
BUG=libyuv:506
Review URL: https://codereview.chromium.org/1405543003 .
previously the neon source code was broken into a separate
library built with -mfpu=neon for the neon assembly, while
the C code was built without neon.
In this change, the neon code is added to the main library
and all code built with neon.
TBR=harryjin@google.com
BUG=libyuv:371
Review URL: https://codereview.chromium.org/1392043003 .
