decision's profile - activity

From top of my head, I don't think there are constructors for it. You might be able to fiddle with a publicly accessible data pointer ("data") in combination with manually manipulating the reference pointer (i.e., "release()" method), but I'm not sure this is a good (or even performant) way to do it.

You can of course go the opposite way and let OpenCV execute your kernels for you, see the *interop methods.

I imagine the ROS package is just found (and used) before the installation that you added.

Instead of fiddling with CMakeLists.txt, add the exact path on commandline as an argument to cmake or - easier - find the appropriate field when using ccmake GUI.

Great. Please mark the answer as useful and/or the thread as solved. Thanks.

Include <OpenCl/cl.h> or so, depeding on the OpenCL SDK you're using. Notice that you need that if you're using anything OpenCL-related that's not completely wrapped inside OpenCV.

Use something like

size_t local_centroids_size = CENTROIDS.rows * CENTROIDS.cols * sizeof(float);
...
args.push_back( make_pair( (size_t)local_centroids_size, (void *)NULL ) );
...
OpenCLExecutreKernel( ..., args, ..);

You will want to adapt it, esp. change the number of bytes to a sizeof(int) factor. Basically, that's the same syntax as with use of setKernelArg.

HTH!

I'm pretty sure now it's a bug in AMDs OpenCL debugger, which showed the pointer as being null.. Duh.

So I have this really annoying problem involving a custom kernel and cv::ocl::openCLExecuteKernelInterop.

The problem is that whenever I use uchar* as argument type to the kernel, the value during runtime is null (0x00000000), while I made sure several times that the .data member of the image has a valid value and is passed to the args vector correctly. (The data member is of type uchar*; I use it to pass the cl_mem pointer -- the place where the image date on the device is located -- to the kernel.) This only happens with uchar*!! If, for example, I change no host source code, but only the kernel implementation to use, say, uchar4*, float* or int*, I do get the pointer value that I passed as argument to the interop method. How strange is that? (Or is it..?)

Existing ocl methods work, i.e. I tested setTo and threshold. The latter supports CV_8U images and calls a kernel that uses char *, so I think it can't be AMDs OpenCL implementation..(?). I also don't see how OpenCV's kernel signature is different from mine (__global uchar * src)..

I really don't get it. Any help appreciated.

Since you use the debug version of the performance test utility, let me ask: Are you comparing GPU vs. CPU performance of your HOG application in release build? If not, you should.

I think the clEnqueue{Read|Rrite}BufferRect method is the most dominant one which utilizes 1.2 features to transfer to/from regular cv::Mats. If you don't have 1.2, you probably can change the source so that it will work with 1.1. On the other hand, I don't know at all if other 1.2 features are used elsewhere.

You should parse your cl-File by hand into a char * array, then you can call cv::ocl::openCLExecuteKernelInterop to execute it. Unfortunately, this function isn't described in the docs.

I think I've seen the same error, and I think it had to do with OpenCV linking CRT library statically. If you compile OpenCV yourself, try disabling static CRT in your build.

Has cmake detected your opencl SDK installation? It appears that opencl symbols are missing. Either the compiler command leaves the libraries out for some reason, or the path is not set correctly. (Of course, there can be even other reasons.) I'd look for the cmake configuration summary. In cmake gui, you can also check if opencl sdk paths are set correctly.

I'm just beginning to learn about OpenCL in general and OpenCV+OpenCV in particular, but I think it means the following:

With help of the utility functions ocl::Info, ocl::getoclContext and others you are able you create programs and compile kernels on your own. After a call to ocl::getDevice, OpenCV should have done all the necessary initialization work, so you are able do enqueue your own kernels.

Without having seen the implementation, my guess is that it's image_size * filter_size, i.e. n²*m², like for "regular" filtering.

A few weeks ago, I stumbled upon a paper that claimed a O(1) filter (with certain restrictions for the filter), but I don't know the details.

Are you actually linking opencv_ocl243.lib ?