OpenCL for OpenCV on Pi

[spinoza1791]

Has anyone been able to run OpenCV on the Pi GPU using OpenCL? Is there an example somewhere demonstrating accessing the GPU with OpenCV using OpenCL?

[doe300]

Being able to run OpenCV is one of the goals of this project. But at this stage is is neither tested nor expected to work.

[spinoza1791]

will you announce here once VC4CL is compatible with OpenCV?

…

On Thu, Apr 12, 2018, 6:13 AM doe300 ***@***.***> wrote: Being able to run OpenCV is one of the goals of this project. But at this stage is is neither tested nor expected to work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZX8mNItkjhmfWvfeYKGc1hCBsRLxRjtks5tnzbBgaJpZM4TNdeX> .

[masterchop]

its a shame, it seems the GPU will help the maker comunity alot but no results so far anywhere. Damm Nvidia taking all the AI, i purchase the Movidious stick while i wait for this to happen, let see how it goes once i get it.

[soulslicer]

What about Caffe? Caffe is currently the only deep learning library to properly support OpenCL 1.2. If this can be made to work with Caffe, itll really be very powerful for AI work

[thortex]

OpenCL-enabled OpenCV is located in my Github;
https://github.com/thortex/rpi3-opencv/
https://github.com/thortex/rpi3-opencv/releases/tag/v3.4.2-opencl

I'm testing original test cases provided by OpenCV;
https://github.com/thortex/rpi3-vc4cl/
https://github.com/thortex/rpi3-vc4cl/releases
https://github.com/thortex/rpi3-vc4cl/tree/master/test/opencv

There are 16,182 tests from 132 test cases.
I've run 2,865 test, got 1,555 NGs, and 1,308 OKs.

opencv-opencl-test.zip

[doe300]

There are 16,182 tests from 132 test cases.
I've run 2,865 test, got 1,555 NGs, and 1,308 OKs.

That sounds promising. For the failed tests, how good are the outputs? Are they any good to debug issues in VC4CL?

[spinoza1791]

Fantastic Thor! My goal is to run OpenCV on Pi against the GPU, while also running a small YOLO model against the Pi CPU (NNPack). This way I can spread the load, so that video processing and NN do not compete for the same processor. Do you think this is possible with your release?

…

On Sun, Jul 22, 2018 at 12:19 AM, Thor Watanabe ***@***.***> wrote: OpenCL-enabled OpenCV is located in my Github; https://github.com/thortex/rpi3-opencv/ https://github.com/thortex/rpi3-opencv/releases/tag/v3.4.2-opencl I'm testing original test cases provided by OpenCV; https://github.com/thortex/rpi3-vc4cl/ https://github.com/thortex/rpi3-vc4cl/releases https://github.com/thortex/rpi3-vc4cl/tree/master/test/opencv There are 16,182 tests from 132 test cases. I've run 2,865 test, got 1,555 NGs, and 1,308 OKs. opencv-opencl-test.zip <https://github.com/doe300/VC4CL/files/2216741/opencv-opencl-test.zip> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZX8mG9GUdClA33c6z3kjXICNUGNpEG-ks5uJAt5gaJpZM4TNdeX> .

[thortex]

log.arith.zip

I attached OpenCL Arithmetic test result of OpenCV 3.4.2 above.

Warning/Error summary is listed below:

• Warning: OpenCV uses clGetProgramInfo API to save OpenCL program cache.

[ WARN:0] Can't save OpenCL binary into cache: /root/.cache/opencv/3.4.2/opencl_cache/32-bit--Broadcom--VideoCore_IV_GPU--0_4/core--lut_02217d060320fc126306ad16885be711.bin
OpenCV(3.4.2) /home/pi/rpi3-opencv/setup/opencv-3.4.2/modules/core/src/ocl.cpp:3752: error: (-220:Unknown error code -220) OpenCL error CL_INVALID_VALUE (-30) during call: clGetProgramInfo(handle, CL_PROGRAM_BINARIES, sizeof(ptr), &ptr, NULL) in function 'getProgramBinary'

• Line#264: 64-bit operations are not supported by the VideoCore IV architecture, ...
• Line#1103: ./modules/core/test/ocl/test_arithm.cpp:179: Failure (Add/Subtract/Multiply)
• Line#7243: MinMax test.

If VC4CL supports clGetProgramInfo(), it's good to execute OpenCL tests for shortening processing time.

[thortex]

Hi spinoza1791 , I think it won't work yet.
We have to debug VC4CL properly to run OpenCV in OpenCL mode.

[doe300]

Thanks @thortex for testing this and the logs.

A few quick comments on the log:

• VC4CL only supports 64-bit types in a very limited scope (when statically convertible to 32-bit types). Idk, if you can deactivate 64-bit types from the OpenCV tests, but these tests will probably never pass.
• The warning with the CL_INVALID_VALUE in clGetProgramInfo I will have to look into it. Looks like the VC4CL does something wrong there.
• Even if it works, at least at the moment I would not enable caching, since currently the compiler (and the code generated) is the thing which changes the most in VC4CL.

[thortex]

Thanks @doe300,

I checked the following fails:

Line#1103: ./modules/core/test/ocl/test_arithm.cpp:179: Failure (Add/Subtract/Multiply)

And I found failure patterns:

• signed 8-bit data type matrix operation is OK, but unsigned 8-bit is failed.
• signed 16-bit data type matrix operation is OK, but unsigned 16-bit is failed.
• float64 data type matrix operation is OK, but float32 is failed.

an example result of unsigned 8-bit data type matrix Add operation is:

[128  30   7     [ 56  32  55    [255 255 255
  20  15   4   +   89  55  12  =  255 255 255
  50  25   5]      11  89  98]    255 255 255]

The expected result is:

[128  30   7     [ 56  32  55    [184  62  62
  20  15   4   +   89  55  12  =  109  70  16
  50  25   5]      11  89  98]     61 114 103]

I don't know why, but VC4CL returns 0xFF for all result of operation.

[doe300]

That's some interesting results, I will have to look into it.
What is the output for unsigned 16-bit integers? Are all elements set to 0xFFFF?

64-bit floating point test cannot pass, it is probably just skipped.

[thortex]

mini.zip

I attached mini.zip (including six test results for matrix add arithmetic operation).

CPU only: Matrix src1 + Matrix src2 = Matrix dst1
OpenCL (VC4CL): Matrix usrc1 + Matrix usrc2 = Matrix udst1

What is the output for unsigned 16-bit integers? Are all elements set to 0xFFFF?

It's 65535 (0xFFFF) described in line #722 of mini.log.

mini-debug.log includes VC4CL debugging outputs.