Fix dynamic loading of clBLAS and clFFT (formerly, clAmdBlas and clAmdFft)

[JoeHowse]

resolves #5444

Problem

OpenCV attempts to dynamically load the clAmdBlas and clAmdFft libraries using filenames and function names that became outdated in 2013-2014. The issue and the necessary name changes are described in detail by Dr. Fredrik C. Bruhn in his blog post at https://bruhnspace.com/en/bruhnspace-opencv-optimization-project/.

Also, OpenCV's teardown code for clAmdFft is commented out for no apparent reason.

Solution

This pull request updates the dynamic loading code for the clAmdBlas and clAmdFft libraries (now called clBLAS and clFFT) and also uncomments the clAmdFft teardown code.

Tests

I have tested the changes on the following systems:

• An up-to-date Manjaro Linux (x64) system with clBLAS 2.12.0 and clFFT 2.12.2 from the AUR repository
• An up-to-date Windows 10 (x64) system with pre-built clBLAS 2.12.0 and clFFT 2.12.2 releases from the clMathLibraries GitHub repositories (https://github.com/clMathLibraries)

Without the changes, opencv_version --opencl and opencv_perf_core both report that the libraries are missing:

    Has AMD Blas = No
    Has AMD Fft = No

With the changes, opencv_version --opencl and opencv_perf_core both report that the libraries are found:

    Has AMD Blas = Yes
    Has AMD Fft = Yes

With or without the changes, opencv_perf_core runs successfully.

[alalek]

Thank you for contribution!

Did you measure performance changes after enabling of clFFT?

[JoeHowse]

Thanks for the review. I have now pushed changes to fix the generators, re-generate the headers, and disable the teardown code. I have successfully re-tested the changes on Windows 10 and Manjaro Linux. Please review the pull request again.

I have run performance comparisons (with v. without the clMath libraries) using perf_opencv_core. As far as I understand:

• OpenCV uses clBLAS for GEMM
• OpenCV uses clFFT for DFT

Thus, I looked at the results from OCL_GemmFixture_Gemm and OCL_DftFixture_Dft.

The use of the clMath libraries yields mixed results, ranging from a significant speed-up to a significant slow-down, depending on the device, data size, and data type. Basically, I would say that these optimizations will be valuable in some applications. I have pasted the total times below and I am attaching the full output for various cases. Later (not as part of this pull request), I plan to do tests with additional hardware and with real-world applications.

Running on Vega 8 + Ryzen V1605B + Windows 10

Without clMath libraries

[----------] 144 tests from OCL_DftFixture_Dft (33134 ms total)
[----------] 24 tests from OCL_GemmFixture_Gemm (39603 ms total)

opencv_perf_core_vega8_win10_without_clmath.txt

With clMath libraries

[----------] 144 tests from OCL_DftFixture_Dft (80982 ms total)
[----------] 24 tests from OCL_GemmFixture_Gemm (25820 ms total)

opencv_perf_core_vega8_win10_with_clmath.txt

Running on RTX 3080 + Ryzen 5950X + Manjaro Linux

Without clMath libraries

[----------] 144 tests from OCL_DftFixture_Dft (4526 ms total)
[----------] 24 tests from OCL_GemmFixture_Gemm (1700 ms total)

opencv_perf_core_rtx3080_manjaro_without_clmath.txt

With clMath libraries

[----------] 144 tests from OCL_DftFixture_Dft (4074 ms total)
[----------] 24 tests from OCL_GemmFixture_Gemm (2279 ms total)

opencv_perf_core_rtx3080_manjaro_with_clmath.txt

[alalek]

Well done!

[alalek]

What kind of problem is observed with 'wb'?

[JoeHowse]

With Python 3, 'wb' gives TypeError: a bytes-like object is required when we try to write a string to the file.

'w' works with both Python 3 and Python 2 strings, and (in our use case) it produces an ASCII-encoded text file.

'wb' is (in my view) simply wrong here because it implies that we are writing a binary file. We are not; we are writing a text file. Despite being conceptually wrong, 'wb' may work for writing text files in Python 2 because Python 2 represents strings as byte arrays.

[JoeHowse]

Thanks for the second review. I have made the changes more consistent by:

• Renaming *clamblas* files to *clblas*
• Renaming *clamdfft* files to *clfft*
• Changing 'wb' to 'w' in parser_cl.py as well. This change makes the parsers compatible with Python 3, and does not break Python 2 compatibility.

I have re-tested successfully. If you see any other issues, please let me know.

[alalek]

Awesome 👍