cuda::flip - Use in-place npp function for inplace arguments

[nglee]

Resolves #17840

#17863 (comment)

cv::cuda::GpuMat::create does not allocate a new GpuMat if required size and type equals existing size and type.

opencv/modules/core/src/cuda/gpu_mat.cu

Lines 160 to 161 in bf8136e

	if (rows == _rows && cols == _cols && type() == _type && data)
	return;

This PR implements cv::cuda::detachOutput to allocate a new GpuMat in such cases. Unfortunately, _dst is const so assignment is not possible. Instead, this implementation clones src.

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 OpenCV (BSD) License.
• To the best of my knowledge, the proposed patch is not based on a code under GPL or other license that is incompatible with OpenCV
• The PR is proposed to proper branch
• There is reference to 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

[alalek]

It is not a CUDA-only issue for this particular function.

It is related to many CPU and OpenCL implementations (almost zero tests for this mode).
So some robust generic approach should be applied.

Possible fixes degrade performance, so we want to forbid such usages (to keep OpenCV library and applications optimized).
We don't want to trying fixing that and adding corresponding tests.

see also #13570 (it is closed without raising a general issue)

[nglee]

@alalek
The updated code referred to the following lines.
https://github.com/opencv/opencv/blob/3.4/modules/imgproc/src/filter.dispatch.cpp#L918-L924

Consulting this issue comment, should we raise an exception instead?

[nglee]

#17840 (comment)

Instead of copying the source matrix, this code calls in-place npp function if given in-place arguments.

[asmorkalov]

Looks good to me. Passed test on Ubuntu 18.04 with CUDA 10.2 and GPU 1080Ti.

[asmorkalov]

👍

[asmorkalov]

@nglee The same issue is reproducible with master branch too, but the code for master is moved to opencv_contrib repo. Could you propose yet another PR to contrib repository too?

[nglee]

@asmorkalov
I've opened one: opencv/opencv_contrib#2612

[tomoaki0705]

nglee The same issue is reproducible with master branch too, but the code for master is moved to opencv_contrib repo. Could you propose yet another PR to contrib repository too?

@asmorkalov Once in the past, I was pointed from @alalek that this is not necessary, porting one PR from opencv to opencv_contrib.

#12666 (review)

once this modification is approved, I'll open a PR for opencv_contrib, too.

It is not necessary. I will merge these changes during next regular "Merge 3.4" PRs.

And alalek also did the same recently
original
ported

Was there any special reason for this PR to be ported to opencv_contrib ?
I'm just curious.

[asmorkalov]

It's good idea to have CUDA implementations aligned between branches, especially if the patch could be ported as is without serious modifications.

[tomoaki0705]

@asmorkalov , my point is not "why", but "who".
If I make modification for CUDA stuff in 3.4 branch, should "I" port it to contrib, or can I keep it untouched so "alalek" can port it ?

[asmorkalov]

General approach is to merge 3.4 to master weekly or so. Alalek does it and you usually hould not worry about it. Cuda changes cannot be just merged to contrib with git and some manual work is required. I usually ask the PR author to do porting as soon as author is in context can can do it faster.