cuda4dnn: fix version check diagnostic

[YashasSamaga]

The checkVersions() that was introduced in #17788 was partially useless since a version mismatch (that could create problems) would throw an exception before checkVersions().

The FP16 and device compatibility checks have been removed from BackendRegistry. BackendRegistry creates a static local object. Hence, subsequent calls to get targets with device id changed can return the wrong set of targets. These checks are instead done in initCUDA now. The target will switch to FP32 if FP16 is not supported.

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 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

force_builders=Custom
buildworker:Custom=linux-4
build_image:Custom=ubuntu-cuda-cc52:18.04
Xbuild_image:Custom=ubuntu-cuda:18.04

[crackwitz]

I believe this is related, but might not be: https://forum.opencv.org/t/dnn-gpu-broken-cuda-issues-pls-help/1298
someone reported this:
checkVersions CUDART version 11020 reported by cuDNN 8100 does not match with the version reported by CUDART 11000

[YashasSamaga]

I believe this is related, but might not be: https://forum.opencv.org/t/dnn-gpu-broken-cuda-issues-pls-help/1298
someone reported this:
checkVersions CUDART version 11020 reported by cuDNN 8100 does not match with the version reported by CUDART 11000

This is mostly because of the new compatibility system and versioning scheme since CUDA 11.1. I will look into it and make appropriate changes here since it's related.

First introduced in CUDA 11.1, CUDA Enhanced Compatibility provides two benefits:

By leveraging semantic versioning across components in the CUDA Toolkit, an application can be built for one CUDA minor release (such as 11.1) and work across all future minor releases within the major family (such as 11.x). 

By leveraging the semantic versioning starting with CUDA 11, components in the CUDA Toolkit will remain binary compatible across the minor versions of the toolkit. In order to maintain binary compatibility across minor versions, the CUDA runtime no longer bumps up the minimum driver version required for every minor release - this only happens when a major release is shipped. This feature is called CUDA Enhanced Compatibility.

References: https://docs.nvidia.com/deploy/cuda-compatibility/index.html

[asmorkalov]

@YashasSamaga Friendly reminder about the patch.

[YashasSamaga]

This might be a breaking change. The issue is that BackendRegistry is a singleton object but the available targets for CUDA depend on the current device that has been selected.

If the user initially used a device without FP16 support and then switches to a device with FP16 support, FP16 target won't be returned with getAvailableTargets since the registry is initialized when the device without FP16 support was present.

So now it always returns both targets and there is a fallback to FP32 in initCUDABackend if FP16 isn't supported.

[alalek]

Thank you!