OpenCL support in BBB

[sajeevan k]

Hi all,


I am trying to make a video capture application with OpenCV and QT in Beaglebone Black RevC(with Debian Jessie image).
When I attempt to run the application in Beaglebone black, the following errors are shown.

CMEM Error: init: Failed to open /dev/cmem: 'No such file or directory'
TIOCL FATAL: The cmemk kernel module is not installed. Consult the OpenCL UserGuide at http://software-dl.ti.com/mctools/esd/docs/opencl/index.html

As per the link https://www.mail-archive.com/beagl...@googlegroups.com/msg42027.html, I tried to solve the issue. But the problem is not solved.

Also the following links shows the TI AM335x doesn't have a GPU in it. So it cannot support OpenCL.

1) https://groups.google.com/forum/#!topic/beagleboard/pZpc5egCaUw.
2) https://e2e.ti.com/support/embedded/linux/f/354/t/500780

But is openCL necessary for videostreaming applications ?
Whether openCV is sufficient for that?
Is there any video streaming applications which does not use openCL.
What I understood is openCL is only for parallel processing?
Whether it is necessary to use Beaglebone X15(in which openCL is supported) to run a video streaming applications?

Thanks for the advice in advance.

Thanks and Regards,
Sajeevan.K

[Robert Nelson]

No OpenCL isn't required to run OpenCV. There just happens to be an OpenCL option to accelerate OpenCV.

But that doesn't really matter for the beaglebone black as you'll need to do OpenCV in software..

Or upgrade to the BeagleBoard-X15...

Regards,

[sajeevan k]

Hi,


Thank You for the advice.

We decided to go for AM57x controllers for our Applications.

Thanks & Regards,
Sajeevan.K

[Bill M]

Greetings Robert,

For my clarification, is OpenCL just not possible on the Beaglebone Black? I was hoping maybe we had gotten to the point where we could parallelize across the graphics subsystem, and am guessing since the BBB only has the single application core, the two PRUs, and the graphics system, then the PRUs and the graphics system would be the only options for parallelization.

I ran into the same problem as Sajeevan. I know part of my problem is that I am using a bone kernel, which doesn't appear to have cmemk available. I'm also using both PRUs in my project, so if OpenCL can't parallelize across the graphics system, then I know trying to build cmemk to get it to work would be a waste of time, and I should just rebuild OpenCV with OpenCL disabled. Any input appreciated.

Thanks,

Bill

[Robert Nelson]

On Sun, Jun 17, 2018 at 5:39 PM, Bill M <billme...@gmail.com> wrote:
> Greetings Robert,
>
> For my clarification, is OpenCL just not possible on the Beaglebone Black? I
> was hoping maybe we had gotten to the point where we could parallelize
> across the graphics subsystem, and am guessing since the BBB only has the
> single application core, the two PRUs, and the graphics system, then the
> PRUs and the graphics system would be the only options for parallelization.
>
> I ran into the same problem as Sajeevan. I know part of my problem is that I
> am using a bone kernel, which doesn't appear to have cmemk available. I'm
> also using both PRUs in my project, so if OpenCL can't parallelize across
> the graphics system, then I know trying to build cmemk to get it to work
> would be a waste of time, and I should just rebuild OpenCV with OpenCL
> disabled. Any input appreciated.

"Hardware Accelerated" OpenCL is not currently possible on the BBB..

The BBB utilizes the SGX 530:

https://en.wikipedia.org/wiki/PowerVR#Series5_(SGX)

Notice the year: Jul 2005

Now look at OpenCL:

https://en.wikipedia.org/wiki/OpenCL#OpenCL_1.0

"OpenCL 1.0 released with Mac OS X Snow Leopard on August 28, 2009."

So as stated, if you want hardware OpenCL from a board built by the
beagleboard.org project pick up the x15, where the DSP's have had
software written to implement OpenCL..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Bill M]

Greetings Robert,

Thanks for the information, that does clear things up immensely. If you don't mind, I have two other questions I was hoping to pose to you (if there is a better place, please let me know).

I'm guessing remoteproc is the future as far as the PRUs go, and I'm still using uio_pruss for my project. In my case, I am receiving an 8 bit parallel feed from a camera module using GRB422 format. If my math is right, 15 frames a second X 320x240 image X 2 bytes per pixel = a little over 2 meg a second that I am sending from the PRU straight to a patch of memory set aside by uio_pruss. My question is, do you think remoteproc could handle that in a way that wouldn't require tying up the application processor and respect the real time requirements of the video feed? I apologize if this is a vague question. I'm sure I don't understand remoteproc well enough yet, but I'm afraid of going down a possible dead-end. At the same time, I also want to make my stuff maintainable and future compatible (and do what the cool kids are doing).

The other question (unfortunately, probably just as vague) is related. I use a script to modprobe uio_pruss before I start my program (and the subsequent PRU program). Under Debian 7.8, my script would have to load, unload, and reload uio_pruss like so:

modprobe uio_pruss extram_pool_sz=2097152 #Have to enable uio_pruss kernel module
modprobe -r uio_pruss    #then disable it
modprobe uio_pruss extram_pool_sz=2097152 #then enable it again. Dont know why

otherwise, my program would error. In Debian 8.7, I can load it just once, and everything works fine. Now I am trying to do it under Debian 9.3, and have found that if I do it once and run my program, everything runs, but I get no video feed. If I end the program, unload uio_pruss, and reload it, then run my program again, it works. But I can't do like before where I load, unload, and reload, and then just run my program. If I do, I get a bus fault. But loading it, running the program, closing the program, unloading uio_pruss, reloading it, and then running my program again, works. I know this is weird and probably tied to me doing something obviously wrong, I was just wondering if there are any known issues or things to look out for with uio_pruss under the different Debian versions. And if I need to do more sleuthing and come back with a better defined problem, I will of course understand.

Thanks again for all of your help, and everything you do for the BB community!

[Robert Nelson]

On Sun, Jun 17, 2018 at 10:46 PM, Bill M <billme...@gmail.com> wrote:
> Greetings Robert,
>

which kernel? uname -r

For newer kernels using uio_pruss you should follow:

https://github.com/mvduin/py-uio

[Bill M]

Greetings Robert,

On Debian 7.8:   3.8.13-bone70

On Debian 8.7:   4.4.127-bone-rt-r22

On Debian 9.3:   4.4.132-bone22

Thanks for the reference. I will probably work with that (translating to C/C++, since I haven't completely dived into Python yet), and I'm guessing this might be helpful?:

https://github.com/beagleboard/linux/tree/3.8/drivers/uio

in my code, I've been using this:

prussdrv_map_extmem(&pruExternalMemoryVirtual);

and this:

pruExternalMemoryPhysical = (void *)prussdrv_get_phys_addr(pruExternalMemoryVirtual);

to get virtual and real addresses to the external ram pool. I've been treating it like 'free real estate' thinking nothing else was using it. I write the physical address to a pointer in my PRU code (that I get from the map file for the PRU program) so the PRU can write camera data straight to it over the OCP, and in my main program use the virtual pointer to read the image data into OpenCV.

Thanks a million (again)!

 

[Robert Nelson]

On Mon, Jun 18, 2018 at 6:37 PM, Bill M <billme...@gmail.com> wrote:
> Greetings Robert,
>

> On Debian 7.8: 3.8.13-bone70
> On Debian 8.7: 4.4.127-bone-rt-r22
> On Debian 9.3: 4.4.132-bone22

You really should upgrade to v4.14.x-bone

>
> Thanks for the reference. I will probably work with that (translating to
> C/C++, since I haven't completely dived into Python yet), and I'm guessing
> this might be helpful?:

No, he just uses python, but he's been working on the memory sharing
interfaces, if you look at the examples..

Just make sure your using v4.14.x-bone to take full advantage of it..

[Bill M]

What do I feed to update_kernel.sh for that?

[Robert Nelson]

On Mon, Jun 18, 2018 at 6:49 PM, Bill M <billme...@gmail.com> wrote:
> What do I feed to update_kernel.sh for that?

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.14.x-ti

But before you do that, make sure you run:

sudo apt update
sudo apt install --only-upgrade bb-cape-overlays kmod

Then make sure you have the latest bootloader:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

any issues run:

sudo /opt/scripts/tools/version.sh

and we can fix the image..

[Bill M]

Awesome. Thanks!