Homework 2: More image operations with
You should write down answers to all questions, make an archive of
that and your resulting source files and mail to me.
No strict deadline. My recommendation is to finish before HW 2, that
is after easter.
In this lab the intention is that you use OpenCL. It is mostly similar
to CUDA. We want to widen your scope a bit, while getting further into
the basic image processing tools.
Please have some tolerance for mistakes. I had to whip this together
rather quickly. All steps are tested, but only on my Mac so you may
need to make some adjustments for other systems.
Some vital notes on OpenCL
CUDA's threadsynchronize() is now called barrier(), with some related
calls in the mem_fence() family. You also have to specify what memory
access you synchronize, CLK_LOCAL_MEM_FENCE, CLK_GLOBAL_MEM_FENCE, or
both (with the binary or operator "|").
CUDA's shared memory is now called local, declared __local.
Your source code is not part of the main program but must be loaded as
a text buffer.
1. Getting started: Hello, World!
Here is our own Hello World! for OpenCL:
Like all my parallel Hello World! examples, it uses the string "Hello "
plus an array of offsets to produce "World!", thus making a tiny
parallel computation and still does what it should, produces the string
"Hello World!". This is, however, quite a bit longer and harder to read
than the CUDA example.
gcc hello_world_cl.c CLutilities.c -lOpenCL
-I/usr/local/cuda/include -o hello_world_cl
(For MacOSX, the library should be replaced by -framework OpenCL, as
You are not supposed to edit the code (although you are welcome to
experiment, of course). But knowing what the code does, you should be
able to figure out where some interesting things take place. First of
all, have a look at the input data and the kernel, and then at the main
Question: How is the
communication between the host and the graphic card handled?
Question: What function executes your kernel?
Question: How does the kernel
know what element to work on?
2. Histogram calculation on the GPU
Histograms are common tools in image processing, for gathering some
basic statistics of an image. On the CPU, it is a straight forward
sequential task. Your task is to figure out a suitable way to perform
this on the GPU. I am not saying that any approach is right or wrong.
This is not a tough operation, so don't expect a big speedup.
loadimage.c and loadimage.cl (below) form a lab shell for this
task. loadimage.c loads the Lenna image and passes it to two
processing routines (CPU and GPU) that, for now, caclulates the
luminance of the first 256 pixels. Results are printed to stdout.
Timing is included, and you should expect the CPU to outperform the GPU
since the problem is too small. With some more work for each thread
(work item) the balance will be better.
Here is the Lenna image:
gcc loadimage.c CLutilities.c -lOpenCL
-I/usr/local/cuda/include -o loadimage
and run with
You may wish to use local
memory (what we called shared in
CUDA). Local memory is declared in the kernel like this:
__local float myBuffer;
Question: How did you
parallize the problem?
Question: What performance did you get, and why?
3. Wavelet transform
The wavelet transform is a famous
operation that is used in image
compression algorithms. In its simplest form, from an image it
calculates four images of 1/4 the size, each pixel being produced by a
combination of four source pixels, different for each of the four
resulting images. These operations are:
out1 = (in1 + in2 + in3 + in4)/4
out2 = (in1 + in2 - in3 - in4)/4
out3 = (in1 - in2 + in3 - in4)/4
out4 = (in1 - in2 - in3 + in4)/4
This is pseudocode, refers to entire pixels in a 2x2 neighborhood, and
four output pixels in suitable positions. Translate to real code. Note
that each pixel consists of three color channels (red, green, blue).
You also need to adjust the numerical range somewhat while computing.
Notice that the original image can be reconstructed perfectly from this
For the famous Lenna image, the result is like this:
Wavelet transformed Lenna
Essentially, what you see is one low-res image, two images describing
edges and one describing extreme points. As you can see, there is less
information in the latter images, which means that they are easy to
Implementing this transform in OpenCL is perfectly doable. Would you
use shared/local memory in such an implementation?
Lab files: invertimage.c and invertimage.cl (below) form a lab shell
task. invertimage.c loads the Lenna image and passes it to two
processing routines (CPU and GPU) that, for now, just inverts the
resulting images are displayed side by side.
Here is the Lenna image:
a) Implement the transform on the CPU first. Add timing and measure.
b) Port your resulting code to OpenCL code and put in the OpenCL kernel.
What speedup did you get compared to your CPU version?
Question: Why do you think a
wavelet coded image can be easier to compress than the original?
Extra (if you have time):
Make a wavelet inverse and see if you can get the original image back.
(If you are interested in image coding it is also interesting to study
the data reduction.)
That's all for this homework. Submit your results to me.