Modify the SIMD loop in color_hsv. #22520

hanliutong · 2022-09-15T13:13:47Z

This patch is a follow-up to my GSoC, modiying the SIMD loop by using new universal intrinsic.

RVV backend of universal intrinsic will enabled in RGBtoHSV and HSVtoRGB loops with this patch.

I also found that the original loop used bitwise logic on the v_float32 type. This doesn't match the documentation (e.g. Bitwise OR. Only for integer types.), but all other Universal Intrinsic backends actually implement bitwise logic for float point types. So I modified the documentation and supported bitwise logic for FP in the RVV backend and compatibility layer.

This patch is tested on QEMU. In particular, clang version 15.0.0-rc3 (or higher) is requested for compilation, lower versions of clang may cause errors.

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

I agree to contribute to the project under Apache 2 License.
To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
The PR is proposed to the proper branch
There is a reference to the original bug report and related work
There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
The feature is well documented and sample code can be built with the project CMake

force_builders=Custom
build_image:Custom=simd-emulator
buildworker:Custom=linux-1,linux-f1

alalek · 2022-09-16T15:28:25Z

modules/core/include/opencv2/core/hal/intrin_cpp.hpp


-Only for integer types. */
+For all types.. */
 template<typename _Tp, int n> CV_INLINE v_reg<_Tp, n> operator&(const v_reg<_Tp, n>& a, const v_reg<_Tp, n>& b);


masks should be used instead of trying to modify bits of floating point types.

I'm not sure why the mask should be used for float point.

I modified the comments here because:

The Bitwise logic operators for floating-point are implemented in each backend, such as Neon, AVX and newly LoongArch

The bitwise logic operator of floating-pointis used in the OpenCV source code, like in this color_hsv

Then I also add the bitwise logic supporting of floating-pointis in RVV backend. And then I modified the comments, since it is supporting all SIMD types in all backend.

Should I restore the comment modifying?

Problem is still here.
We don't really want to declare bitwise operations for floating-point numbers in universal API.
You assumed here 0 and 0xffff...ff values only, but it is not assumed in the API itself (and has no correct interpretation/definition for other values like 2.0f).

The bitwise logic operator of floating-pointis used in the OpenCV source code, like in this color_hsv

It is not used until this patch.
Regular CI build passes: http://pullrequest.opencv.org/buildbot/builders/master_etc-simd-emulator-lin64
Build with changed modules/imgproc/src/color_hsv.simd.hpp from this patch fails (cmake ... -DOPENCV_EXTRA_FLAGS="-DCV_FORCE_SIMD128_CPP=1" -DCPU_BASELINE=SSE4_2 -DCPU_DISPATCH=):

/home/alalek/projects/opencv/dev/modules/imgproc/src/color_hsv.simd.hpp: In member function ‘void cv::hal::cpu_baseline::{anonymous}::RGB2HSV_f::process(const cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, const cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, const cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, cv::hal_EMULATOR_CPP::simd128_cpp::v_float32&, float) const’: /home/alalek/projects/opencv/dev/modules/imgproc/src/color_hsv.simd.hpp:298:53: error: no matching function for call to ‘v_and(cv::hal_EMULATOR_CPP::simd128_cpp::v_float32, cv::hal_EMULATOR_CPP::simd128_cpp::v_float32)’ 298 | v_float32 v_res = v_select(v_r_eq_max, v_and(v_lt(v_g, v_b), vx_setall_f32(360.0f)), | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin.hpp:757:19: note: candidate: ‘cv::hal_EMULATOR_CPP::simd128_cpp::v_uint8 cv::hal_EMULATOR_CPP::simd128_cpp::v_and(const v_uint8&, const v_uint8&)’ 757 | inline _Tpvec v_and(const _Tpvec& a, const _Tpvec& b) \ | ^~~~~ /home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin.hpp:757:19: note: in definition of macro ‘OPENCV_HAL_WRAP_BIN_OP_LOGIC’ 757 | inline _Tpvec v_and(const _Tpvec& a, const _Tpvec& b) \ | ^~~~~ ...

You assumed here 0 and 0xffff...ff values only, but it is not assumed in the API itself

Thanks for your comment! I got the point and revert the modify of the API.

asmorkalov · 2022-09-19T07:44:50Z

There are build issues on Windows with MSVC:

[692/2285] Building CXX object modules\imgproc\CMakeFiles\opencv_imgproc.dir\src\color_hsv.dispatch.cpp.obj
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(144): error C2131: expression did not evaluate to a constant
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(107): note: failure was caused by call of undefined function or one not declared 'constexpr'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(107): note: see usage of 'cv::hal_baseline::simd128_cpp::VTraits<cv::hal_baseline::simd128_cpp::v_uint8>::vlanes'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(164): error C2131: expression did not evaluate to a constant
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(107): note: failure was caused by call of undefined function or one not declared 'constexpr'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(107): note: see usage of 'cv::hal_baseline::simd128_cpp::VTraits<cv::hal_baseline::simd128_cpp::v_uint8>::vlanes'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(817): error C2131: expression did not evaluate to a constant
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(815): note: failure was caused by call of undefined function or one not declared 'constexpr'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(815): note: see usage of 'cv::hal_baseline::simd128_cpp::VTraits<cv::hal_baseline::simd128_cpp::v_float32>::vlanes'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\imgproc\src\color_hsv.simd.hpp(820): error C2668: 'cv::hal_baseline::simd128_cpp::vx_load_aligned': ambiguous call to overloaded function
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\core\include\opencv2/core/hal/intrin.hpp(608): note: could be 'cv::hal_baseline::simd128_cpp::v_float64 cv::hal_baseline::simd128_cpp::vx_load_aligned(const double *)'
C:\GHA-OCV-6\_work\opencv\opencv\opencv\modules\core\include\opencv2/core/hal/intrin.hpp(606): note: or       'cv::hal_baseline::simd128_cpp::v_uint64 cv::hal_baseline::simd128_cpp::vx_load_aligned(const uint64 *)'

fengyuentau · 2022-09-22T02:13:53Z

Hello @asmorkalov , liutong has made many contributions to opencv. Do you know why he is still considered as first-time contributor who cannot run and rerun gha workflows himself?

asmorkalov · 2022-09-22T06:31:23Z

I do not know.

alalek · 2022-10-25T21:51:13Z

This patch is tested on QEMU

Which QEMU with RVV 1.0 was used to validate this patch?

I tried upstream QEMU build (RVV patches from sifive are there), but it fails with internal error.

QEMU build:

<qemu_dir>/configure --target-list=riscv64-linux-user --prefix=/opt/riscv
VERBOSE=1 make install -j16

QEMU run:

qemu-riscv64 -g 12345 -cpu rv64,Zve64f=true,vext_spec=v1.0 -L /opt/riscv/sysroot ./bin/opencv_test_imgproc --gtest_filter=Imgproc_ColorHSV.accuracy
Crash message: qemu-riscv64: ...qemu/target/riscv/translate.c:213: decode_save_opc: Assertion `ctx->insn_start != NULL' failed.
riscv-gdb shows signal SIGSEGV, Segmentation fault on this instruction:
- x/i $pc: vand.vv v9,v29,v1
- x/4b $pc: 0xd7 0x84 0xd0 0x27
- address 0x4003277464 <_ZNK2cv4impl12_GLOBAL__N_120CvtColorLoop_InvokerINS_3hal12cpu_baseline12_GLOBAL__N_19HSV2RGB_bEEclERKNS_5RangeE+1438>

BTW, clang 16.0.0 is used for OpenCV compilation (from https://syntacore.com/page/products/sw-tools via 202209 Linux package)

Output with `-d in_asm` QEMU option

----------------
IN: 
0x0000004003277404:  27d10157          vand.vv                 v2,v29,v2
0x0000004003277408:  920998d7          vfmul.vv                v17,v0,v19
0x000000400327740c:  6ee49057          vmflt.vv                v0,v14,v9
0x0000004003277410:  27ad84d7          vand.vv                 v9,v26,v27
0x0000004003277414:  939992d7          vfmul.vv                v5,v25,v19
0x0000004003277418:  00179293          slli                    t0,a5,1
0x000000400327741c:  2bc20257          vor.vv                  v4,v28,v4
0x0000004003277420:  92399e57          vfmul.vv                v28,v3,v19
0x0000004003277424:  5ca051d7          vfmerge.vfm             v3,v10,ft0,v0
0x0000004003277428:  2a2484d7          vor.vv                  v9,v2,v9
0x000000400327742c:  26b787d7          vand.vv                 v15,v11,v15
0x0000004003277430:  9796              add                     a5,a5,t0
0x0000004003277432:  028d82a7          vs1r.v                  v5,(s11)
0x0000004003277436:  26b18057          vand.vv                 v0,v11,v3
0x000000400327743a:  028d8427          vs1r.v                  v8,(s11)
0x000000400327743e:  2a9784d7          vor.vv                  v9,v9,v15
0x0000004003277442:  26bf05d7          vand.vv                 v11,v11,v30
0x0000004003277446:  978a              add                     a5,a5,sp
0x0000004003277448:  2a9584d7          vor.vv                  v9,v9,v11
0x000000400327744c:  028de587          vl1re32.v               v11,(s11)
0x0000004003277450:  26df8457          vand.vv                 v8,v13,v31
0x0000004003277454:  0a078793          addi                    a5,a5,160
0x0000004003277458:  2a940457          vor.vv                  v8,v9,v8
0x000000400327745c:  028788a7          vs1r.v                  v17,(a5)
0x0000004003277460:  c22027f3          csrrs                   a5,vlenb,zero

qemu-riscv64: ../../../riscv/qemu/target/riscv/translate.c:213: decode_save_opc: Assertion `ctx->insn_start != NULL' failed.
----------------
IN: _ZN6cvtestL13signalHandlerEi
0x00000040002abcf8:  3565              addiw                   a0,a0,-7
0x00000040002abcfa:  4611              addi                    a2,zero,4
0x00000040002abcfc:  55f1              addi                    a1,zero,-4
0x00000040002abcfe:  00a66963          bgtu                    a0,a2,18                # 0x40002abd10

"Failed" instruction is not in scope of input code (addr 0x4003277464). So likely, QEMU failed during translation as reported.

hanliutong · 2022-10-26T02:31:01Z

Hello @alalek , thanks a lot for your work!

Which QEMU with RVV 1.0 was used to validate this patch?

The QEMU I use was built from https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next.

If the GNU toolchain is installed in /opt/riscv/bin/, then /opt/riscv/bin/qemu-riscv64 --version shows qemu-riscv64 version 5.2.0 (v5.0.0-6352-g856da0e94f)

And the command I used is

/opt/riscv/bin/qemu-riscv64 -cpu rv64,x-v=true ./bin/opencv_test_imgproc

I tried upstream QEMU build (RVV patches from sifive are there)

I haven't tried it. All testing work of the RVV backend developed for OpenCV is done on the QEMU in the GNU toolchain. But my colleague tried to use upstream QEMU a few months ago and it didn't work with RVV intrinsic.

So I suggest building the GNU toolchain and test OpenCV with qemu-riscv64 in it. This may solve the problem. I'm also updating my clang and testing again in case the problem is caused by the upgrade of the compiler.

Update:
Test with clang 16.0, it's passed. So I think the problem is caused by different QEMU, but not the compiler.

clang version 16.0.0 (https://github.com/llvm/llvm-project.git 76b92df0d6915aa419c6856f97198df3321c35d7)

alalek · 2022-10-26T18:18:18Z

@hanliutong Thank you for the information!

The QEMU I use was built from https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next

QEMU from this link is not updated for the last 2 years. It reuses upsteam qemu version 5.2.0.

With this QEMU 5.2 binary fails on csrrs instruction. Adding Zicsr=true cpu property doesn't help here too.
So I tried to switch from llvm/clang to riscv-collab/riscv-gnu-toolchain, see below.

I tried to build OpenCV with platforms/linux/riscv64-gcc.toolchain.cmake and mentioned riscv-gnu-toolchain toolchain (in Ubuntu 20.04 container).
Unfortunately OpenCV compilation is failed with message.

/usr/bin/ccache /opt/riscv/bin/riscv64-unknown-linux-gnu-g++ --sysroot=/opt/riscv/sysroot  -DOPENCV_ALLOCATOR_STATS_COUNTER_TYPE=int -D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/alalek/projects/opencv/dev/modules/core/include -Imodules/core -I/home/alalek/projects/opencv/dev/3rdparty/zlib -I3rdparty/zlib -I/home/alalek/projects/opencv/dev/3rdparty/include/opencl/1.2 -isystem . -march=rv64gcv_zfh    -fsigned-char -W -Wall -Wreturn-type -Wnon-virtual-dtor -Waddress -Wsequence-point -Wformat -Wformat-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Wsuggest-override -Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections   -fvisibility=hidden -fvisibility-inlines-hidden -O3 -DNDEBUG  -DNDEBUG -g1 -fPIC   -std=c++11 -MD -MT modules/core/CMakeFiles/opencv_core.dir/src/cuda_info.cpp.o -MF modules/core/CMakeFiles/opencv_core.dir/src/cuda_info.cpp.o.d -o modules/core/CMakeFiles/opencv_core.dir/src/cuda_info.cpp.o -c /home/alalek/projects/opencv/dev/modules/core/src/cuda_info.cpp
In file included from /home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin.hpp:233,
                 from /home/alalek/projects/opencv/dev/modules/core/src/precomp.hpp:88,
                 from /home/alalek/projects/opencv/dev/modules/core/src/cuda_info.cpp:43:
/home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin_rvv.hpp: In function 'bool cv::hal_baseline::v_check_all(const v_uint8x16&)':
/home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin_rvv.hpp:1923:31: error: invalid cast from type 'vuint8m1_t' to type 'vuint64m1_t'
 1923 |     v_uint64x2 v = v_uint64x2((vuint64m1_t)vsrl_vx_##suffix##m1(vnot_v_##suffix##m1(a, vl), shift, vl)); \
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/alalek/projects/opencv/dev/modules/core/include/opencv2/core/hal/intrin_rvv.hpp:1932:1: note: in expansion of macro 'OPENCV_HAL_IMPL_RVV_CHECK_ALLANY'
 1932 | OPENCV_HAL_IMPL_RVV_CHECK_ALLANY(v_uint8x16, u8, 7, 16)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Toolchain version:

alalek riscv-gnu-toolchain(rvv-next)$ git remote -v
origin	https://github.com/riscv-collab/riscv-gnu-toolchain.git (fetch)
origin	https://github.com/riscv-collab/riscv-gnu-toolchain.git (push)
alalek riscv-gnu-toolchain(rvv-next)$ git show HEAD
commit da01ba455ce3802ffa84fdca3a089079996dbfc3 (HEAD -> rvv-next, origin/rvv-next)
Merge: 127e5b6 f55e588
Author: Kito Cheng <[email protected]>
Date:   Thu Sep 1 17:12:35 2022 +0800

    Merge pull request #1125 from pz9115/rvv-next
    
    Bump riscv-gcc-rvv-next.

Any thoughts here?

BTW, Dockerfile example from #21625 description is broken near https://github.com/sifive/qemu.git line.

hanliutong · 2022-10-27T02:29:12Z

The QEMU I use was built from https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next

@alalek I apologize for the wrong information: My toolchain was built a long time ago, the branch I used was called rvv-intrinsic(same as the dockerfile in #21625), since there is not a branch called rvv-intrinsic now, I had thought it was renamed to rvv-next, but it seems I was wrong. Seems like the qemu version is mismatch between rvv-intrinsic and rvv-next, the following inforemation may helpful. And I will also try to update the Dockerfile.

root@5ac5223bab1c:/riscv/riscv-gnu-toolchain# git branch
  master
* rvv-intrinsic
root@5ac5223bab1c:/riscv/riscv-gnu-toolchain# cd qemu/
root@5ac5223bab1c:/riscv/riscv-gnu-toolchain/qemu# git remote -v
origin  https://github.com/sifive/qemu.git (fetch)
origin  https://github.com/sifive/qemu.git (push)
root@5ac5223bab1c:/riscv/riscv-gnu-toolchain/qemu# git show HEAD
commit 856da0e94f127d9b06aee6a9f5aecbc4d2830777 (HEAD)
Author: Frank Chang <[email protected]>
Date:   Wed Mar 3 12:52:15 2021 +0800

    target/riscv: rvv-1.0: fix vcompress.vm insn check bug

    The destination vector register group cannot overlap the source vector
    register group or the source mask register for vcompress.vm instruction.

    Signed-off-by: Frank Chang <[email protected]>

And about platforms/linux/riscv64-gcc.toolchain.cmake, it may be currently unavailable, as your tested. This is due to the fact that RVV intrinsic supporting in GCC has been stagnant for a long time. However, LLVM has continued to support RVV intrinsic, but there is no RVV toolchain, so we have a strange toolchain for rvv development currently: use LLVM (clang) as compiler and use the libc, binutils and simulater(QEMU) in the GNU toolchain.

The upgrade of rvv intrinsic in GCC is still working and will be stabled and be integrated into the upstream at the end of this year, and then I will update OpenCV related code to support both gcc and clang.

hanliutong · 2022-10-27T08:52:16Z

And I will also try to update the Dockerfile.

There is the dockerfile for RVV related development and testing:

Dockerfile

FROM ubuntu:20.04

# CMake PPA to get modern CMake
RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        ca-certificates \
        apt-transport-https \
        gnupg \
        software-properties-common \
        wget && \
    wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor | tee /etc/apt/trusted.gpg.d/kitware.gpg >/dev/null && \
    apt-add-repository 'deb https://apt.kitware.com/ubuntu/ focal main' && \
    apt-get clean

RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        gcc \
        g++ \
        git \
        make \
        ninja-build \
        cmake \
        ccache \
        python3 \
        gcc-multilib \
        autoconf \
        automake \
        autotools-dev \
        curl \
        libmpc-dev \
        libmpfr-dev \
        libgmp-dev \
        libglfw3-dev \
        gawk \
        build-essential \
        bison \
        flex \
        texinfo \
        gperf \
        libtool \
        patchutils \
        bc \
        zlib1g-dev \
        libexpat-dev \
        pkg-config \
        libglib2.0-dev && \
    apt-get clean

RUN mkdir /riscv && cd /riscv && \
    git clone -b rvv-next https://github.com/riscv/riscv-gnu-toolchain.git && \
    cd riscv-gnu-toolchain && \
    git config --global http.sslVerify false && \
    git submodule set-url qemu https://github.com/sifive/qemu.git && \
    git submodule update --init --recursive && \
    cd qemu && \
    git checkout 856da0e94f127d9b06aee6a9f5aecbc4d2830777

RUN mkdir /opt/riscv && cd /riscv/riscv-gnu-toolchain && ./configure --prefix=/opt/riscv && \
    make linux -j32 && \
    make build-qemu -j32 && \
    cd ..

RUN cd /riscv  && \
    git clone https://github.com/llvm/llvm-project.git && \
    mkdir llvm-project/build && cd llvm-project/build && \
    cmake -DLLVM_PARALLEL_LINK_JOBS=2 -DLLVM_TARGETS_TO_BUILD="host;RISCV" -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_BUILD_TYPE=RELEASE ../llvm && \
    make -j32 && \
    ln -s /riscv/llvm-project/build /opt/rvv-llvm && \
    cd ..

USER root

CMD bash

alalek · 2022-10-27T23:48:13Z

I build qemu from mentioned commit:

https://github.com/qemu/qemu/tree/856da0e94f127d9b06aee6a9f5aecbc4d2830777
branch on sifive's fork: https://github.com/sifive/qemu/commits/v5.2.0-rvv-rvb-zfh

Problems with binaries compiled with upstream clang and enabled RVV are gone (at least for tests with observed qemu crashes).
Looks like there is some lack of RVV support in upstream qemu for now.

alalek · 2022-10-29T19:43:31Z

modules/imgproc/src/color_hsv.simd.hpp

+        v_float32 v_g_eq_max = v_eq(v_g, v_max_rgb);
+        v_h = v_select(v_r_eq_max, v_sub(v_g, v_b),
+              v_select(v_g_eq_max, v_sub(v_b, v_r), v_sub(v_r, v_g)));
+        v_float32 v_res = v_select(v_r_eq_max, v_and(v_lt(v_g, v_b), vx_setall_f32(360.0f)),


v_and(v_lt(v_g, v_b), vx_setall_f32(360.0f)

v_select() should be used instead of bits manipulation.

BTW, comparison functions and v_select() should work through dedicated masks type (vbool32_t in case of RVV) instead of the same data type.
This is old legacy design bug - comparison returns the same type as inputs type.
I believe it should be redesigned during adding of new "scalable" API.

asmorkalov · 2022-11-22T09:53:02Z

@hanliutong friendly reminder.

hanliutong · 2022-11-23T03:43:19Z

Sorry for very late reply.
I have already use v_select instead of bits manipulation.

comparison functions and v_select() should work through dedicated masks type

I agree with that, it makes sense. But it looks like it's going to be a big modification, especially for other backends. I'm working on RVV now, and then other backends, but that might take more time.

alalek · 2022-11-23T08:44:22Z

modules/core/include/opencv2/core/hal/intrin.hpp

+    OPENCV_HAL_WRAP_BIN_OP_LOGIC_FLT(v_float32)
+    #if CV_SIMD_64F
+    OPENCV_HAL_WRAP_BIN_OP_LOGIC_FLT(v_float64)
+    #endif


Why do we still trying to add bitwise operations for floating point types?

Drop that from intrinsics API.

Use vreinterpret and/or v_select in the code directly with a TODO mark to rework on masks.

hanliutong · 2022-11-28T13:11:59Z

Hello @alalek , I've done some work on the mask type,and there is a proposal and commit #22878. Since this may be a large modification and not very relevant to this PR, I think the the good way is create a new PR when it is ready besides this. And maybe we can merge this patch firstly is it is ok for you.

alalek

Thank you 👍

Modify the SIMD loop in color_hsv. * Modify the SIMD loops in color_hsv. * Add FP supporting in bit logic. * Add temporary compatibility code. * Use max_nlanes instead of vlanes for array declaration. * Use "CV_SIMD || CV_SIMD_SCALABLE". * Revert the modify of the Universal Intrinsic API * Fix warnings. * Use v_select instead of bits manipulation.

hanliutong added 3 commits September 2, 2022 13:52

Modify the SIMD loops in color_hsv.

a58ad63

Add FP supporting in bit logic.

417f80f

Add temporary compatibility code.

72c6466

hanliutong mentioned this pull request Sep 16, 2022

Redesign the SIMD macro. #22463

Merged

6 tasks

asmorkalov mentioned this pull request Sep 16, 2022

!!! NOT FOR REVIEW !!! [SVE] Example HAL-compatible SVE code for Linear Resize. #20640

Closed

6 tasks

asmorkalov requested a review from alalek September 16, 2022 14:12

asmorkalov added platform: riscv optimization labels Sep 16, 2022

alalek reviewed Sep 16, 2022

View reviewed changes

Use max_nlanes instead of vlanes for array declaration.

0fea0af

Use "CV_SIMD || CV_SIMD_SCALABLE".

96fc586

Revert the modify of the Universal Intrinsic API

9c9aba9

alalek reviewed Oct 29, 2022

View reviewed changes

Fix warnings.

3bb38e9

alalek reviewed Nov 23, 2022

View reviewed changes

Use v_select instead of bits manipulation.

e32eeab

hanliutong force-pushed the hsv branch from 2c8f3de to e32eeab Compare November 23, 2022 11:11

hanliutong mentioned this pull request Nov 28, 2022

RFC: Redesign comparison functions in universal intrinsic by using mask type. #22878

Open

alalek approved these changes Nov 28, 2022

View reviewed changes

alalek merged commit a32f2cd into opencv:4.x Nov 28, 2022

alalek mentioned this pull request Jan 8, 2023

(5.x) Merge 4.x #23113

Merged

mshabunin mentioned this pull request Jun 5, 2023

imgproc/cvtColor: fixed invalid read in BGR2HLS #23750

Merged

Uh oh!

Modify the SIMD loop in color_hsv. #22520

Modify the SIMD loop in color_hsv. #22520

Uh oh!

Conversation

hanliutong commented Sep 15, 2022 • edited by alalek Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Readiness Checklist

Uh oh!

alalek Sep 16, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanliutong Sep 22, 2022

Choose a reason for hiding this comment

Uh oh!

alalek Oct 28, 2022

Choose a reason for hiding this comment

Uh oh!

hanliutong Oct 29, 2022

Choose a reason for hiding this comment

Uh oh!

asmorkalov commented Sep 19, 2022

Uh oh!

fengyuentau commented Sep 22, 2022

Uh oh!

asmorkalov commented Sep 22, 2022

Uh oh!

alalek commented Oct 25, 2022

Uh oh!

hanliutong commented Oct 26, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alalek commented Oct 26, 2022

Uh oh!

hanliutong commented Oct 27, 2022

Uh oh!

hanliutong commented Oct 27, 2022

Uh oh!

alalek commented Oct 27, 2022

Uh oh!

alalek Oct 29, 2022

Choose a reason for hiding this comment

Uh oh!

asmorkalov commented Nov 22, 2022

Uh oh!

hanliutong commented Nov 23, 2022

Uh oh!

alalek Nov 23, 2022

Choose a reason for hiding this comment

Uh oh!

hanliutong Nov 23, 2022

Choose a reason for hiding this comment

Uh oh!

hanliutong commented Nov 28, 2022

Uh oh!

alalek left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

hanliutong commented Sep 15, 2022 •

edited by alalek

Loading

alalek Sep 16, 2022 •

edited

Loading

hanliutong commented Oct 26, 2022 •

edited

Loading