Process masked integer norms chunk by chunk and reuse each loaded mask
and predicate across channels, avoiding repeated mask processing.
Extend norm_mask performance coverage with three-channel 8U, 8S, 16U,
16S, and 32S inputs for INF, L1, and L2 norms.
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
Replace separate widening multiplication and FP64 addition with
widening FMA in the unmasked and masked FP32 L2 norm kernels.
Finite FP32 products are exactly representable in FP64, so this
preserves numerical results without changing the accumulation order.
Tail and mask undisturbed policies are retained.
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
core: optimize float REDUCE_SUM2 with RVV - #29930
### Summary
Add an RVV 1.0 kernel for `cv::reduce` with `dim=0` and `CV_32F`
input/output through the CPU dispatch mechanism.
The optimized path targets the floating-point `REDUCE_SUM2` operation.
### Implementation
Process four source rows per vector iteration to reduce intermediate
buffer traffic while preserving source-row accumulation order.
The RVV kernel uses LMUL=4 and dynamic vector lengths for tail handling.
Output writes are deferred until all input rows have been read. This
preserves correct behavior when the source and destination matrices
overlap.
The implementation is VLEN-agnostic.
### Functional Testing
The Reduce tests were run with:
```bash
./bin/opencv_test_core \
--gtest_filter='*Reduce*:*reduce*' \
--test_threads=1
```
### Performance Testing
Performance was measured with:
```bash
./bin/opencv_perf_core \
--gtest_filter='*reduceR*' \
--perf_threads=1
```
Test environment:
- SpacemiT K3
- VLEN = 256
- GCC 14.3.0
- Release build
- Single thread
- 10 samples per case
Results were compared against an unmodified `5.x` baseline.
`CV_32FC1 REDUCE_SUM2` median execution time (ms):
| Size | Baseline | Patched | Speedup |
| --- | ---: | ---: | ---: |
| 640x480 | 0.20 | 0.08 | 2.50x |
| 1280x720 | 0.64 | 0.29 | 2.21x |
| 1920x1080 | 1.33 | 1.05 | 1.27x |
Speedups are approximate and calculated from the rounded benchmark
output.
### Co-authors
- Yang Wang <yangwang@iscas.ac.cn>
- Yuansheng <yuansheng@isrc.iscas.ac.cn>
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] 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
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] 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
Add a CV_SIMD_SCALABLE path for the DIS patch processing kernels using
universal intrinsics and runtime vector lane counts.
Keep the existing CV_SIMD128 implementation unchanged to avoid affecting
fixed-width SIMD targets. The scalable path vectorizes patch rows with
v_float32 and handles remaining elements with the existing scalar code.
This enables native RVV vectorization for processPatch(),
processPatchMeanNorm(), computeSSD(), and computeSSDMeanNorm().
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
core: rvv: optimize 8U row reduce sum with vwaddu.wv - #29923
### Summary
Optimize the RVV implementation of `reduceRowSum_8u32s` by using the
native widening add instruction `vwaddu.wv`.
The generic scalable-vector path expands each `u8m1` input vector into
two `u16m1` halves and performs two separate load/add/store sequences
for the `u16` accumulation buffer.
On RVV, an `u8m1` vector and an `u16m2` vector have the same number of
elements. This allows the implementation to use an `u16m2` accumulator
directly and combine widening and addition with `vwaddu.wv`:
```text
u16m2 = u16m2 + u8m1
```
This removes the explicit widening and low/high `u16` accumulator split,
reducing the vector operations in the hot accumulation loop.
The existing scalar tail and 256-row `u16`-to-`u32` flush logic remain
unchanged.
The implementation is VLEN-agnostic.
### Functional Testing
The Reduce tests were run with:
```bash
./bin/opencv_test_core \
--gtest_filter='*Reduce*:*reduce*'
```
### Performance Testing
Performance was measured with:
```bash
OPENCV_FOR_THREADS_NUM=1 ./bin/opencv_perf_core \
--gtest_filter='*Reduce*:*reduce*'
```
Test environment:
- SpacemiT K3 / X100
- RVV 1.0
- VLEN = 256
- GCC 14.3.0
- Release build
- Single thread
Results were compared against an unmodified `5.x` baseline.
Median execution time (ms):
| Size / Type | Baseline | RVV `vwaddu.wv` | Speedup |
| --- | ---: | ---: | ---: |
| 640x480 8UC1 | 0.09 | 0.05 | 1.80x |
| 640x480 8UC4 | 0.36 | 0.16 | 2.25x |
| 1280x720 8UC1 | 0.27 | 0.12 | 2.25x |
| 1280x720 8UC4 | 1.08 | 0.56 | 1.93x |
| 1920x1080 8UC1 | 0.62 | 0.29 | 2.14x |
| 1920x1080 8UC4 | 2.43 | 1.11 | 2.19x |
Geometric mean speedup: **~2.09x**.
`REDUCE_MIN`, `REDUCE_MAX`, and `REDUCE_SUM2` performance remains
essentially unchanged, indicating that the speedup is localized to the
optimized 8-bit row SUM path.
### Co-authors
- Yang Wang <yangwang@iscas.ac.cn>
- Yuansheng <yuansheng@isrc.iscas.ac.cn>
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] 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
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] 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
video:rvv: optimize PyrLK tracker with RVV - #29947
### Summary
Add an RVV path to `LKTrackerInvoker` for patch interpolation and
covariance matrix accumulation.
### Implementation
Vectorize bilinear interpolation of image pixels and derivatives, and
accumulate A11, A12 and A22 using RVV widening operations. Reuse
temporary vectors and keep the main computation at `e16,m1` and
`e32/f32,m2` to limit vector register pressure.
### Functional Testing
```bash
./bin/opencv_test_video \
--gtest_filter='Video_OpticalFlowPyrLK.accuracy' \
--test_threads=1
./bin/opencv_test_video \
--gtest_filter='Video_OpticalFlowPyrLK.submat' \
--test_threads=1
```
Correctness was verified with:
- `Video_OpticalFlowPyrLK.accuracy`
- `Video_OpticalFlowPyrLK.submat`
### Performance Testing
```bash
OPENCV_FOR_THREADS_NUM=1 \
./bin/opencv_perf_video \
--gtest_filter='*OpticalFlowPyrLK_self*' \
--perf_threads=1
```
Performance was measured with `OpticalFlowPyrLK_self` using a single
thread on an RVV 1.0 system with VLEN=256.
All 96 benchmark cases improved with no regression. The sum of
per-case median execution times decreased from 409.89 ms to 332.33 ms,
a reduction of 18.9%. The best case decreased from 8.41 ms to 5.50 ms,
corresponding to a 34.6% reduction in execution time (1.53x speedup).
Median execution time (ms):
| Metric | Baseline | RVV | Time reduction |
|---|---:|---:|---:|
| Sum of per-case medians across all 96 cases | 409.89 | 332.33 | 18.9% |
| Best case | 8.41 | 5.50 | 34.6% |
### Co-authors
- Yang Wang <yangwang@iscas.ac.cn>
- Yuansheng <yuansheng@iscas.ac.cn>
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] 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
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] 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
Add an RVV HAL implementation for CV_32F to CV_16S conversion.
The RISC-V convertScale HAL already handles several source/destination
depth combinations, but CV_32F to CV_16S currently returns
CV_HAL_ERROR_NOT_IMPLEMENTED and falls back to the generic core path.
Implement the missing conversion using native RVV intrinsics. The
identity-scale case skips the multiply-add, while scaled conversions
apply alpha and beta before narrowing to signed 16-bit output.
The implementation is VLEN-agnostic and uses vsetvl for tail handling.
Functional test:
```text
./build-rvv/bin/opencv_test_core \
--gtest_filter='*ConvertScale*'
```
Performance was measured with opencv_perf_core on SpacemiT K3
(RVV 1.0, VLEN=256), comparing against an unmodified 5.x baseline.
CV_32F -> CV_16S median time:
```text
1920x1080 C1, alpha=1:
26.16 ms -> 1.46 ms (17.92x)
1920x1080 C1, alpha=1/255:
24.10 ms -> 1.45 ms (16.62x)
1920x1080 C4, alpha=1:
103.76 ms -> 6.06 ms (17.12x)
1920x1080 C4, alpha=1/255:
96.03 ms -> 5.68 ms (16.91x)
```
All four corresponding opencv_perf_core cases pass.
Co-authored-by: Yang Wang [yangwang@iscas.ac.cn](mailto:yangwang@iscas.ac.cn)
Co-authored-by: Yuansheng [yuansheng@iscas.ac.cn](mailto:yuansheng@iscas.ac.cn)
The generic odd-radix DFT path created the index vector with
vsetvlmax_e32mf2() and kept it live across a subsequent setvl() call used
for the current processing chunk.
This code pattern can produce incorrect results with GCC 15.2 using the
default optimized VSETVL strategy. Core_DFT.accuracy and
Core_DCT.accuracy fail with the RVV HAL enabled, while disabling VSETVL
global fusion makes the same tests pass.
Generate the index vector after setting the vector length for each
q-loop chunk instead. Keep all vector operations within the same local
qvl and advance q explicitly by that value.
This preserves the existing odd-radix DFT algorithm while avoiding
vector values that span changes of VL.
Tested on SpaceMIT K3 with GCC 15.2.0, RVV 1.0 and VLEN=256:
RISCV_RVV_SCALABLE=ON
WITH_HAL_RVV=ON
CMAKE_BUILD_TYPE=Release
Core_DFT and Core_DCT accuracy tests pass with GCC's default VSETVL
optimization enabled.
Co-authored-by: Yuansheng <yuansheng@iscas.ac.cn>
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
