PDA

View Full Version : Image Support and clCreateImage2d



ijackson
02-10-2010, 04:18 AM
Hi All,

I have an application in mind, that would make really good use of OpenCL image processing. I assume that a GPU is going to be best placed to do this, and I was surprised to find that CL_DEVICE_IMAGE_SUPPORT evaluated to false, when I had my clGetDeviceIDs flag set to CL_DEVICE_TYPE_GPU. I have a ATI Radeon HD 4850. Isn't a lack of image support a big hole?

Anyway, supposing I set the flag to CL_DEVICE_TYPE_CPU, where there is image support, what exactly is it that I'm to supply to host_ptr in clCreateImage2D? In Cocoa speak, I have tried to send it "im", where im is created by:

unsigned char *im = (unsigned char*) malloc(height*pitch);
memcpy(im, [bmImage bitmapData], height*[bmImage bytesPerRow]);

basically exactly as the Apple example code does. I'd follow the way the example code does it, but I can't find any examples that actually use the method that has the clCreateImage2D call in it. When I do this, I get a CL_INVALID_HOST_PTR error. Any help would be much appreciated.

Thank you,

Ian.

ijackson
02-11-2010, 02:49 AM
Never mind. I figured it out. The image I was passing was fine. I just had other arguments in clCreateImage2D set wrong. :oops:

dbs2
02-11-2010, 05:06 AM
Note that image processing on the CPU is not going to be nearly as fast as on the GPU. GPUs have special hardware for interpolation and format conversion, which speeds those up. You will probably be better off using buffers on the CPU. (If you need to do interpolation between pixels the Apple CPU implementation is highly optimized, but still much slower than a GPU hardware implementation.)

ijackson
02-11-2010, 09:57 PM
Well, indeed. As I'm only just recently starting to look at OpenCL, it comes a surprise, that presumably, image support is the exception rather than the rule, for most of the GPUs out there (based on the fact that my computer is new and doesn't have image support). I've already created an implementation of my algorithm that uses multiple cores, so I don't know if there's any point in pursuing the OpenCL route for the CPU. However, I only need one channel value from the image (e.g. I can just take red), so I can try creating a 2D array of values to mimic the image, and go from there. The output would need three channels though, so I guess I'd have to output as a 3D array, or perhaps I can have a struct that the application and the kernel can both read?

dbs2
02-12-2010, 04:48 AM
Image support should be expected on GPUs, but the problem is that OpenCL is much more stringent about the precision of image support than a bunch of GPUs' hardware. (Notably the AMD 4000 series are a bit tricky.) Of course AMD doesn't even support the 4000 series at all, so that says something about how good they are for OpenCL, unfortunately.

For your output of three channels you should just do either an RGB output or an RRRR...GGGG...BBBB... type output depending on what final format you need for the images.

ijackson
02-12-2010, 11:51 PM
Thanks very much. It's useful to know the lie of the land. A bit disappointing that my card is perhaps sub-standard, but I have only just started looking at OpenCL, so I don't know the significance of not having the image support.

Anyway, the RRRR..., GGGG..., BBBB... output would work well in my situation. Thank you for that. But I see that "a buffer object stores a one-dimensional collection of elements". Does that mean I have to turn my image into one long 1D array?

Ian.

dbs2
02-13-2010, 10:51 AM
Effectively yes. You would access it as:

red = data[y*row_width+x+red_offset];
green = data[y*row_width+x+green_offset];

etc.

ijackson
02-13-2010, 07:14 PM
Thank you, that is what I have done.

Ian.