There are two overviews I use during my training, and I would like to share with you. Normally I write them on a whiteboard, but it has advantages having it in a digital form.

Transfer speeds per bus

The below image gives an idea of theoretical transfer speeds, so you know how a fast network (1GB of data in 10 seconds) compares to GPU-memory (1GB of data in 0.01 seconds). It does not show all the ins and outs, but just give an idea how things compare. For instance it does not show that many cores on a GPU need to work together to get that maximum transfer rate. Also I have not used very precise benchmark-methods to come to these views.

We zoom into the slower bus-speeds. So all the good stuff is at the left and all buses to avoid are on the right.  What should be clear is that a read from or write to a SSD will make the software very slow if you use write-trough instead of write-back.

What is important to see that localisation of data makes a big difference. Take a look at the image and then try to follow with me. When using GPUs the following all can increase the speed on the same hardware: not using hard-disks in the computation-queue, avoiding transfers to and from the GPU and increasing the computations per byte of data. When an algorithm needs to do a lot of data-operations such as transposing a matrix, then it’s better to have a GPU that has high memory-access. When the number of operations is important, then clock-speed and cache-speed is most important.

You don’t see in this image how much time it takes to do an operation on the CPU or GPU itself when the data is available. These “transfer-speeds” are directly related with the actual FLOPS (frequency times number of cores times number of operations per core). Then you understand why these maximum theoretical FLOPS do not result in very high FLOPS in all real-life software: data-transfer is part of reality.

Operations and Data-size

This image shows the optimal OpenCL-hardware given operations per byte and data-size. It is a relative representation where to find the best hardware for devices. So if you have a lot of data (and thus transfers), there is a moment you could better use a APU (AMD Fusion or Intel Sandy Bridge). If the operations per byte are low, then it might be best just to use a CPU (using OpenCL).

As it really depends on the actual hardware (for instance GPUs on APUs are currently not really that powerful), use this image only to ask yourself the right questions for your algorithm. More on this in the upcoming new “hardware buying guide”.

I hope these images gave you an easy insight in how things work in the world of OpenCL. If you want more, just see our more extensive training-program.

Does your computer have OpenCL-capable hardware? Read on, if you want to find out…

For people who only want to run OpenCL-software and have recent hardware, just read this paragraph. If you have recent drivers for your GPU, you can be sure OpenCL is already supported and you can run OpenCL-capable software. NVidia has support for OpenCL 1.1 since drivers 280.13, so if you need OpenCL 1.1, then make sure you have this version or later. If you want to use Intel-processors and you don’t have an AMD GPU installed, you need to download the runtime of Intel OpenCL.

If you want to know if your X86 device is supported, you’ll find answers in this article.

Often it is not clear how OpenCL works on CPUs. If you have a 8 core processor with double threading, then it mostly is understood that 16 pipelines of instructions are possible. OpenCL takes care of this threading, but also uses parallelism provided by SSE and AVX extension. I talked more about this here and here. Meaning that an 8-core processor with AVX can compute 8 times 32 bytes (8*8 floats or 8*4 doubles) in parallel. You could see it as parallelism of parallelism. SSE is designed with multimedia-operations in mind, but has enough to be used with OpenCL. The absolute minimum requirement for OpenCL-on-a-CPU is SSE3, though.

A question I see often is what to do if you have more devices. There is no OpenCL-package for all devices, so you then need to install drivers for each device.

Read on to find out exactly which processors are supported.

Finding useful hardware

In short: hardware from 2010 and 2011 has OpenCL-support, hardware from late 2008 to beginning 2010 have reasonable support. Older hardware has support (if you bought the best of the best), but might not give real good speed-up. To be sure (as there are always exceptions), you need to know which processor and graphics card are installed.

Windows

As OpenCL works on CPUs, GPUs and accelerators, the first step is to get a list of all devices. Under the “System and Security” section of the “Control Panel” you’ll find the device manager. This lists all devices. We are interested in “display adaptors” and “processors”. Check for the brands AMD, ATI, NVidia and Intel.

Alternatively you can use GPU-z (CPUs and GPUs), GPUz (GPUs only) or GPU Caps Viewer (GPUs only, but also a lot on OpenCL-support) to find the information. For CPUs CPU-Z is very useful, as shows you immediately if your CPU supports SSE4.2 and AVX for exquisite OpenCL-performance.

Linux

Easiest way is to install ‘sysinfo’, which tells everything about your computer. Alternatively you can find supported CPUs with:

cat /proc/cpuinfo | grep sse3

A list of GPUs with:

lspci | grep VGA

Apple

You get the GPU-drivers provided with the OS. I found an overview of supported GPUs here and here. Support for CPUs is also already there. If you want to develop software on a MAC, you will find examples here and will find XCode completely ready.

The only down-side is that the drivers cannot be manually updated.

Intel CPUs

You can choose to use Intel’s drivers, or AMD’s drivers.

Intel OpenCL drivers

Intel’s drivers require support for SSE4.1. Below is an overview of all CPUs released until now which support OpenCL via the intel driver. Do you have a Core processor, scroll down to AMD OpenCL drivers.

AVX (Q1 2011)

• 2nd Generation Core i-series (SandyBridge).

SSE 4.2 (Q1 2009 – Q3 2010)

• Core i7 Processors
• Core i5 Processors
• Core i3 Processors
• Xeon 55XX series
• Xeon 56XX series
• Xeon 75XX series

SSE4.1 (Q2-Q3 2008)

• Xeon 74XX series
• Quad-Core Xeon 54XX, 33XX series
• Dual-Core Xeon 52XX, 31XX series
• Core 2 Extreme 9XXX series
• Core 2 Quad 9XXX series
• Core 2 Duo 8XXX series
• Core 2 Duo E7200

AMD OpenCL drivers

AMD’s drivers support above devices and processors with SSE3 or SSSE3. They claim support for SSE2.x too – but since not much extra speed could be squeezed out of these, I only list CPUs with at least SSE3 support.

SSSE3

• Quad-Core Xeon 73XX, 53XX, 32XX series
• Dual-Core Xeon 72XX, 53XX, 51XX, 30XX series
• Core 2 Extreme 7XXX, 6XXX series
• Core 2 Quad 6XXX series
• Core 2 Duo 7XXX (except E7200), 6XXX, 5XXX, 4XXX series
• Core 2 Solo 2XXX series
• Pentium dual-core processor E2XXX, T23XX series

SSE3

• Atom processors (SSE3_ATOM)
• Dual-Core Xeon 70XX, 71XX, 50XX Series
• Dual-Core Xeon processor (ULV and LV) 1.66, 2.0, 2.16
• Dual-Core Xeon 2.8
• Xeon processors with SSE3 instruction set support
• Core Duo
• Core Solo
• Pentium dual-core processor T21XX, T20XX series
• Pentium processor Extreme Edition
• Pentium D
• Pentium 4 processors with SSE3 instruction set support

It is interesting to know that AMD and Intel have different optimisation techniques and therefore sometimes AMD’s and sometimes Intel’s drivers give faster code.

The AMD SDK can be downloaded from http://developer.amd.com/amdapp

AMD CPU/APU

Intel officially only supports their own processors, so you cannot use Intel’s drivers.

To have good support for OpenCL, it is a good bet to have at least SSE4a-support – which is on their K10-architecture:

• Phenom
• Phenom II
• Athlon II

You have run-time and compile-time of the C-code and of the OpenCL-code. It is very important to make clear when you talk about compile-time of the kernel as this can be confusing. Compile-time of the kernel is at run-time of the software after the compute-devices have been queried. The OpenCL-compiler can make better optimised code when you give as much information as possible. One of the methods is using Function Qualifiers. A function qualifier is notated as a kernel-attribute:

__kernel __attribute__((qualifier(qualification)))  void foo ( …. ) { …. }

There are three qualifiers described in OpenCL 1.x. Let’s walk through them one by one. You can also read them here in the official documentation, with more examples.

vec_type_hint

It tells what type of vectors is used in the computation, and its width. If you say for example that float4 will be used, the vectorisator tries to optimise the code for that. Especially Intel is very much fan of using this hint; strangely AMD (with VLIW in its Radeons) does not push this hint much. Example, with clear naming of a kernel that works on int8:

__kernel __attribute__((vec_type_hint(int8)))  void foo_int8 ( …. ) { …. }

Default assumption is that the computations will be done using int scalars(!). Intel says in its documentation that is uses vectors of fours as default to optimise on. While in their SDK 1.1 they suggest hinting for float4 or int4, but in 1.5 they say this hint turns off the auto-vectorizer if the width is not 4 * 4 bytes (float4 or int4). AMD tells you should use vectors of 4 wide, but not to use this hint – it just tries to optimise for vector of 4 wide (like Intel). NVidia is also silent on this one. Nevertheless it is always wise to use this hint, as you never know what kind of optimisations the compiler is capable of.

I my experience this hint does not work always to auto-vectorise scalar-kernels. Packing the bytes together always works better. If you have a good example of a not-too-simple kernel with scalars that vectorised well using this hint, let me know in the comments.

work_group_size_hint and reqd_work_group_size

The compiler does not see how the kernel will be called, but it could optimise the scheduler if it knew in advance. work_group_size_hint tells the possibledimension of NDRange, reqd_work_group_size is alike but very strict. It is not documented on how the compilers handle these differently or at all. On GPUs this hint gives a good speed-up. Just try with and without to see how it works for your kernel. Example of a kernel that needs a workgroup of 64x1x1:

__kernel __attribute__((reqd_work_group_size(64, 1, 1)))  void foo ( …. ) { …. }

Multiple attributes

You can use several attributes, when needed. While you might think you can use more attributes separated by a spaces, officially they are notated as a comma-separated list between the double parentheses. Example of a kernel that works on float4 and assumes a 1D-workgroup of 32:

__kernel __attribute__((vec_type_hint(float4), work_group_size_hint(32, 1, 1)))  void foo ( …. ) { …. }

It has no logic to use both work_group_size_hint and reqd_work_group_size, though.

For functions which are not kernels, these hints cannot (officially) not be used. I could not find what the official documentation says on this, but I assume the compiler uses the same hints for the kernel and all the called functions.

Last words

OpenCL is low-level and to give it space to evolve, less explicit coding is needed. Writing code that can be optimised by the compiler I always say to my trainees that they should keep a copy of the unoptimised code, because every year the compiler gets better. Using vec_type_hint also keeps you focused on packing the data together and think as the compiler: can in every step 4 operations be done at the same time? And if so, can I show the compiler how?

Why work_group_size_hint and reqd_work_group_size are actually needed, is a question I have. I hope this will be resolved in 2.0 that you just compile a kernel given an NDRange and then run it. Want more explanation? Ask your questions in the comments.

And remember: always keep a copy of your unoptimised scalar kernel, as you cannot tell what future compilers are capable of.

Intel, AMD and NVidia have all written implementations of the Black-Scholes algorithm for their devices. Intel has described a kernels in their OpenCL optimisation-document (page 28 and further) with 3 random factors as input: S, K and T, and two configuration-constants R and V. NVidia is easy to compare to Intel’s, while AMD chose to write down the algorithm quite different.
So we have three different but comparable kernels in total. What will happen if we run these, all optimised for specific types of hardware, on the following devices?

• Intel(R) Core(TM) i7-2600 CPU @3.4GHz, Mem @1333MHz
• GeForce GTX 560 @810MHz, Mem @1000MHz
• Radeon HD 6870 @930MHz, Mem @1030MHz

Intel’s example

Since Intel provides the smallest kernel, here you have an idea how Black-Scholes works. As you can see, it is very nicely parallel with only references to global id tid.

__kernel __attribute__((vec_type_hint(float4)))
void BlackScholes(
	__global float4 *callResult,
	__global float4 *putResult,
	const __global float4* S,
	const __global float4* K,
	const __global float4* T,
	float r,
	float v)
{
	size_t tid = get_global_id(0);
	float4 d1 = 0.0f;
	float4 d2 = 0.0f;
	//int4 calls = (int4)'c';
	d1 = (log(S[tid] / K[tid]) + (r + v * v / 2) * T[tid]) / (v * sqrt(T[tid]));
	d2 = d1 - v * sqrt(T[tid]);
	callResult[tid] = S[tid] * CND4(d1)- K[tid] * exp(T[tid] * -r) * CND4(d2);
	putResult[tid] = K[tid] * exp(T[tid] * -r) * CND4(-d2) - S[tid] * CND4(-d1);
}

It is used for approximating the best price for an option in the financial world. Read this post on the matter, which explains in easy language what it does. It is also interesting to know that it was developed for computers slower than a Casio calculator.

Benchmarks

I used the original code of the SDKs and edited the selection-methods for platform and device-type.

NVidia’s code

NVidia GPU: 0.00082 s
AMD GPU: 0.00159 s (0.00120 to 0.00202 on Catalyst 11.12)
AMD CPU: 0.07400 s  (0.074520 on Catalyst 11.12)
Intel CPU: 0.01525 s

Very clear results: pretty optimised for NVIDIA GPUs. See that for CPUs Intel’s drivers give a much faster result than AMD.

Intel’s code

As there was no software, I hacked the kernel into NVidia’s version. I made a float4-version of NVidia’s CND and altered Intel’s code a little so it gave back both calls and puts. Unluckily it did not give correct results for AMD and Intel according to the program, so more work for later. For the code I used see above listing. Add “unsigned int optN” to be complete, and the trick with callMask in the original code you can use in the float4-version of CND.

“__attribute__((vec_type_hint(float4)))” did not make the Intel CPU work faster, even if they claimed it in their article. This compiler-hint also gave an error for NVIDIA and AMD.

NVidia GPU: 0.00019 s
AMD GPU: 0.00035 s (0.00025 to 0.00090 on Catalyst 11.12)
AMD CPU: 0.00529 s (0.00469 on Catalyst 11.12)
Intel CPU: 0.00159 s

Knowing that NVidia gave correct results with this version, we can assume float4 is a good thing.

AMD’s code

As AMD’s code is totally different (both kernel and host), you cannot compare these results with the other two.

NVidia GPU: 0.514 s
AMD GPU: 0.154 s (0.126s on Catalyst 11.12 – not much fluctuation)
AMD CPU: 0.105 s (0.102s on Catalyst 11.12)
Intel CPU: 0.161 s

AMD had the strangest results. It seems the CPU via AMD’s drivers is 5 times as fast as NVidia and also faster than AMD’s GPU. They successfully made Radeons get faster results than Geforces on this one.

A last word

Next time let’s try an algorithm that needs more memory-optimisations. But as stated above, I am going to use all the results later.

HTML5 has the future, now Flash and Silverlight are abandoning the market to make the way free for HTML5-video. There is one big problem and that is that it is hard to protect the content – before you know the movie is on the free market. DRM is only a temporary solution and many times ends in user-frustration who just want to see the movie wherever they want.

If you look at e-books, you see a much better way to make sure PDFs don’t get all over the web: personalizing. With images and videos this could be done too. The example here at the right has a very obvious, clearly visible watermark (source), but there are many methods which are not easy to see – and thus easier to miss by people who want to have needs to clean the file. It therefore has a clear advantage over DRM, where it is obvious what has to be removed. Watermarks give the buyers freedom of use. The only disadvantage is that personalised video’s ownership cannot be transferred.

Personalised & Watermarked

Awareness is the most important thing when it comes to copy-protection. People have to know it is watermarked. Consumers don’t have the feeling they are tricked when some organisation knocks at their door – they would have acted more responsibly when they knew their name was printed on the media. In the previous century we bought the box around the DVD, and the content of the DVD is of everybody – the signature of an actor should be put on the box. This century we don’t get a box anymore and we only know we get sued when sharing the movie with friends. Just looking at the past 20 years I cannot say that people have a good feeling of ownership. I believe that using the visual opportunities as shown below, or even putting a personalised message like “for your 2011 birthday, hugs from auntie”, gives the buyer a better feeling of ownership than the 1 minute long warnings before the movie starts.

This 2007 Master thesis by Martin Zlomek discusses various ways of watermarking and how they can be attacked. It is quite honest which are good and which are not – see chapter “robustness”. Recompression, scaling, cropping, noising, denoising, blurring, sharpening all have ways to deform the watermark but take the movie itself with it. Using several movies and blur out differences keeps being a good attack. This means that it is as bad as DRM, once professionals focus on the movie. Difference is that you can never tell where the watermark can be hidden too and thus must make a gamble all is removed when releasing the movie.

When streaming the movie, the renting-company could use the technique to build up a better customer-relation. A personalised advertisement can be added anywhere inside the movie. This could make it possible to show the movie for free, which disrupts the illegal market.

Only disadvantage is that all above costs a lot of processing-power which could raise the price per video too much.

The fast lane

Using video-cards and GPGPU, a video can be watermarked with GPGPU much faster than with traditional techniques. An implementation using GPUs I found here [PDF], but many more possibilities exist. Compression can be prepared quite far (motion-detection, actual compression, etc), before additional data is added. Finishing the video-compression using OpenCL could start delivering the movie for streaming fast.

StreamComputing thinks along with you to get ideas for your problem and gets your product developed. Look around at the site to see what we also do – ask us any question you have via the contact-form.

This article is of interest for you, if you don’t want to read the whole new specifications [PDF] for OpenCL 1.2. As not everything is clear yet without drivers out there, there will be some edits to this article the coming time – feedback is very welcome.

After many meetings with the many members of the OpenCL task force many ideas sprout. And each 17 or 18 months a new version comes out of OpenCL to give all these ideas form. You see ideas coming up which are totally new, already brought outside in another product by a member, or not appearing as other members voted against. The last category is very interesting and hopefully we’ll see a lot of forum-discussion soon what should be in the next version as it is missing now.

With the release of 1.2 there was also announced that (at least) two task forces will be erected. One of them will target integration in high-level programming languages, which tells me that phase 1 of creating the standard is complete and we can expect to go for OpenCL 2.0. I will discuss these phases in a follow-up and what you as a user, programmer or customer can expect and how you can act on it.

Another big announcement was that Altera is starting to support OpenCL for a FPGA-product. In another article I will let you know everything there is to know. For now I concentrate on the actual differences in this version software-wise, and what you can do with it. I have added links to the 1.1 and 1.2 man-pages, so you look it up.

New Kernel-functions

The most rudiment debug-tool, printf, first needed to have a vendor-specific extension enabled, but now you can flood the standard output without it. For who hasn’t tried printf yet, have a global size of 1000, let the CPU print “ping\n” and the kernels “pong\n” – then you know exactly why you need to e careful with this function.

The function popcount returns the number of ones in a variable. So if x is 5 (binary 101), then popcount(x) is 2. A nice explanation of fast popcount on SSE is here. It counts bits regardless of what it represents, so it also counts the sign-bit.

Replaced functions

The OpenCL group prefers to change the name of functions when the parameter-list changes. Below are the “new” functions I encountered.

clEnqueueMarker, clEnqueueBarrier and clEnqueueWaitForEvents have been merged into clEnqueueMarkerWithWaitList and clEnqueueBarrierWithWaitList. The barrier and marker functionality are still the same, but if a non-NULL waiting-list is given it will also continue if all the events have occurred. Before this was tricky to program. A new option is that you can fire an event when all previous events have occurred.

clCreateImage2D and clCreateImage3D have been merged into clCreateImage. clCreateFromGLTexture2D and clCreateFromGLTexture3D have been merged into clCreateFromGLTexture. As the functions were comparable and the parameter texture_target handles the differences, not much changed. What is new (and a mayor reason for merging these functions) is the adding of 1D images, and support for image-arrays (see below for explanation how they work). 1D images were introduced to be compliant with OpenGL 1D images.

Mem-flags CL_MEM_COPY_HOST_WRITE_ONLY, CL_MEM_COPY_HOST_READ_ONLY and CL_MEM_COPY_HOST_NO_ACCESS have been added to describe how the host can connect to the object at the device, where 1.1 only described how the device could access the object and if the memory was allocated at the device or the host.

clUnloadCompiler and clGetExtensionFunctionAddress got changed to clUnloadPlatformCompiler and clGetExtensionFunctionAddressForPlatform and now must specify the platform. This seems to be logical, as clUnloadCompiler probably removed compilers of all platforms, and the function-address seems to be unspecified when more platforms were loaded. Not much used functions though.

DirectX

Besides the fancy 1D images, support for DirectX 9 and 11 textures also have been added. DX9 is an interesting choice, but this way such software can be given a longer life by adding OpenCL to speed it up. I still disagree it has official KHR-support as it only works under Microsoft code – under Linux (and all its deratives like Android) and OSX it is not supported.

The new functions clCreateFromDX9MediaSurfaceKHR, clEnqueueAcquireDX9MediaSurfacesKHR and clEnqueueReleaseDX9MediaSurfacesKHR are comparable to clCreateFromD3D10Texture2DKHR, clEnqueueAcquireD3D10ObjectsKHR and clEnqueueReleaseD3D10ObjectsKHR. clCreateFromD3D11BufferKHR, clCreateFromD3D11Texture2DKHR, clCreateFromD3D11Texture3DKHR, clEnqueueAcquireD3D11ObjectsKHR and clEnqueueReleaseD3D11ObjectsKHR are like their D3D10-counterparts.

Sharing like cl_khr_d3d10_sharing for DX9 and 11 is enabled with cl_khr_dx9_media_sharing and cl_khr_d3d11_sharing. The counterparts of clGetDeviceIDsFromD3D10KHR are clGetDeviceIDsFromD3D11KHR and clGetDeviceIDsFromDX9MediaAdapterKHR.

Multi-user and Multi-device

As OpenCL-devices get more powerful, it is very probable the device can better be shared. Also it gets more common to have multiple GPUs in a system, and/or have various capable devices now CPUs get better support.

clEnqueueMigrateMemObjects helps with multiple devices to copy memory objects from one device to another; first this had to be done by copying via the host.

clCreateSubDevices partitions a device in sub-devices. It can be partitioned in equal parts, specified sizes, or depending on specific hardware. The last option can split the devices based on i.e. cache-hierarchy, so that the different subdevices have shared cache at the given level. The functions clRetainDevice and clReleaseDevice have been altered to handle sub-devices. First this was under the extension device_fission.

Intitalisation of data

clEnqueueFillBuffer and clEnqueueFillImage help with initialising data by filling it with a pattern or a colour. This was first best done at the host, or with a kernel specially written for it, or just ignored. Now our lives have been improved.

Building

It seems that more effort is put in making sure the kernels are better protected. The function clBuildProgram can be split up between clCompileProgram and clLinkProgram. If I understand correctly, it is comparable to how clCreateProgramWithBinary works, as this takes compiled binaries.

clGetProgramInfo en clGetProgramBuildInfo have been extended to get information on how the program has been built. The new function clGetKernelArgInfo returns specified information on the arguments used for building the kernel. This is useful when the building of the software is separated from the program, such as is the case when binaries are used.

Image arrays

An array of 1D or 2D images can be written by write_image{f|i|ui|h}. The image ID is given by the y (1D) or z (2D) value. With read_image{f|i|ui|h} you need to specify the coordinates plus the image-number, int2 for 1D and int3 for 2D images.

get_image_array_size returns the number of images in an array. It is the responsibility of the software to keep things in order, as it does not give an array of image-numbers.

Other

Macros CL_VERSION_1_2 and __OPENCL_C_VERSION__ have been added. The first one gives 120 just like CL_VERSION_1_1 gives 110, the last one gives 100, 110 or 120.

Double-precision is now an optional core feature instead of an extension. Meaning, you just need to check if the device supports it, but you don’t need to pragma it in.

CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE has been deprecated. It gives the smallest alignment in bytes which can be used for any data type. It is quite comparable to CL_DEVICE_MEM_BASE_ADDR_ALIGN. This could help select the best device for an alignment-optimised kernel, but is rarely used.

A new flag CL_MAP_WRITE_INVALIDATE_REGION has been added to cl_map_flags. This is comparable to CL_MAP_WRITE, but without guarantees memory is not being overwritten.

Storage class specifiers extern and static are now supported. A storage class settles the scope of the variable (c definition here). I need to get deeper into this, as I would think extern is __global, and static is __local – I’ll keep you posted to get this more clear.

Video

Tim Mattson of Intel explains some of the highlights of OpenCL 1.2 in this 12 minute video

Typos are a programmers worst nightmare, as they are bad for concentration. The code in your head is not the same as the code on the screen and therefore doesn’t have much to do with the actual problem solving. Code highlighting in the IDE helps, but better is to use the actual OpenCL compiler without running your whole software: an Online OpenCL Compiler. In short is just an OpenCL-program with a variable kernel as input, and thus uses the compilers of Intel, AMD, NVidia or whatever you have installed to try to compile the source. I have found two solutions, which both have to be built from source – so a C-compiler is needed.

• CLCC. It needs the boost-libraries, cmake and make to build. Works on Windows, OSX and Linux (needs possibly some fixes, see below).
• OnlineCLC. Needs waf to build. Seems to be Linux-only.

For both you can just give the source-file of the kernel, optionally which driver/device to use. With OnlineCLC it is not very clear what is meant with the “device” option and I am trying to find that out and hope to update this article soon. CLCC has an extra option to specify the device-type (GPU, CPU, etc) to use. It is for instance possible to have these commands as an external command in your IDE, so you can check your kernel when needed. And don’t forget to write your test-cases with this – assuming the test-machine has all the devices.

Watch out! It is using the hardware for compiling too, so it can crash your machine as hard as you can do with your own GPGPU-software.

Getting CLCC working on Linux

The downloaded version 0.1 of CLCC does not work out-of-the-box on a recent Linux-distribution with the latest boost-libraries. You can check out of SVN, wait for the upcoming version 0.2 or enter the below fixes.

The file src/CMakeLists.txt needs “cmake_minimum_required(VERSION 2.8)” at the top and

if (UNIX)
target_link_libraries(clcc ${CMAKE_DL_LIBS})
endif()

to make the linking working. In options.cpp replace “ifdef __LINUX__” with “ifdef __linux__“. In main.cpp en clpp.cpp replace “#include <boost/exception.hpp>“ with “#include <boost/exception/all.hpp>“. That’s all.

Now run

cmake -G "Unix Makefiles" .
make

in the root of the project. Now you are ready to run CLCC. Any feedback can go to george at organicvectory dot com.

Disclaimer: I am not a lawyer and below is my humble opinion only. The post is for insights only, not for legal matters.

GPL was always a protection that somebody or some company does not run away with your code and makes the money with it. Or at least force that improvements get back into the community. For unprepared companies this was quite some stress when they were forced to give their software away. Now we have host-kernels-languages such as OpenCL, CUDA, DirectCompute, RenderScript don’t really link a kernel, but load it and launch it. As GPL is quite complicated if it comes to mixing with commercial code, I try to give a warning that GPL might not be prepared for this.

If your software is dual-licensed, you cannot assume the GPL is not chosen when eventually used in commercial software. Read below why not.

I hope we can have a discussion here, so we get to the bottom of this.

The GPL FAQ

The claim is that if a kernel is a independent piece of software that does not get linked but loaded, then GPL does not protect the code. The GPL FAQ says this about GPL-plugins for non-free software:

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with the non-free main program.

From the first paragraph we can conclude that if the kernel is generalised to a standard plugin (for instance all have “kernel void performFilter()“) and is accompanied with the GPL-license, that it is permitted to load that kernel from non-free software. And yes, ‘exec’ seems to be a better description of launching a kernel than ‘linking’.

The second paragraph describes what happens when loading&launching a kernel would be the same as linking. I can only think of certain cases, but those are avoidable.

What makes it more difficult is that lot of existing software has complete functionality and GPGPU-code is truly a plugin which replaces existing functionality. Meaning the software is not dependent on it and the faster code.

How to get legal protection?

Always be explicit. If you really want to be sure, extend the GPL by stating that loading the kernel-file is seen as dynamic linking and as such the GPL is applied, etc. etc. How exactly this can be done, ask your lawyer. For commercial kernels I would recommend you to check licenses that go with Java code – as jar-files can be decompiled.

Which license do you use yourself?

In the series Basic Concepts I try to give an alternative description to what is said everywhere else. This time my eye fell on alternative convenience methods in two cases which were introduced there to be nice to devs with i.e. C/C++ and/or graphics backgrounds. But I see it explained too often from the convenience functions and giving the “preferred” functions as a sort of bonus which works for the cases the old functions don’t get it done. Below is the other way around and I hope it gives better understanding. I assume you have read another definition, so you see it from another view not for the first time.

Vector Elements

Vectors can be seen as structs on which the computations can be implied to all the elements at the same time. Each element can be accessed by .sX with X being 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F depending on the number of elements in the vector with a 16-vector having all 16 and an 8-vector only 0 to 7. The convenience methods are .x, .y, .z, .w, .hi, .lo, .even en .odd. Below are the the methods defined in the standard. The abbreviation N.D. stands for non-defined. For 3-vectors some functions are not explicitly not-defined, but vague in how to be implemented, so therefore I put “??” to them.

To get an idea what a float4 is, here is an (incompletely) description:

struct float4 {
….float s0, s1, s2, s3;
….float x, y, z, w;
….float hi, lo, odd, even;
….float2 s01, s02, s03, s10, s12, s13, s20, s21, s23, s30, s31, s32;
….float2 xy, xz, xw, yx, yz, yw, zx, zy, zw, wx, wy, wz;
….float3 s012, s021, s023, s032, s031, s013, … /* etc */
….float3 xyz, xzy, xzw, … /* etc */
….float4 s0123, s0132, … /* etc */
/* etc – see remark below */

} float4

We are missing i.e. float8 s10123422, but that is quite hard to define in a struct (and neither is defined well in the definitions which imply no repetitions of elements). Just try if .s0011 and .xxyy works with your drivers.

Conversions

Next are conversions between types. The specified and complete function is using convert_destType<_sat><_roundingMethod>. Most developers are familiar with explicit conversions like:

float a = 5.6f;
int b = (int) a; // = 5

In OpenCL this is the convenience function and only works with ascalars and one rounding mode without saturation; a explicit conversion ‘(destType)’ can be described as ‘convert_destType_rte’ (or ‘convert_destType’).

You do use (type) when you want to widen a scalar to a vector. For example:

float8 f = (float8) 1.0f;

If you get used to convert_ then you don’t have think which method to use depending on if its a scalar or vector and depending if you need rte-rounding or another rounding and depending if you need saturation or not. As a bonus the rounding modes with 2 examples.

Thank you

Thank you for your time; I hoped you liked the alternative view. Check the rest of the series, while it is still small.

Want to have both your GTX and Radeon working as OpenCL-devices under Linux? The bad news is that people failed trying to get Radeon as a compute device and the GTX as primary. The good news is that the other way around works pretty easy (with some luck). You need to install both drivers and watch out that libglx.so isn’t overwritten by NVidia’s driver as we won’t use that GPU for graphics – this is also the reason why it is practically impossible to use the second GPU for OpenGL.

First install NVidia and don’t let the installer change xorg.conf or install anything OpenGL-like (if asked) – so go for the minimum. I eventually used the trick to install both the deb (or rpm) and use the installer, to have the system well cleaned but having no problems when there is a new kernel. Under ubuntu I use ‘sudo stop gdm‘ to stop X, to give room to the installer – and ’sudo stop gdm‘ to get it going again. Second step is to install the fgrlx-driver of Radeon the normal way. Be warned: you could be unlucky and will need to try a few times to get the right order to have certain files overwritten; I was unluckily having strange screen-behaviour (not detecting the size of the screen correctly which made certain parts of the screen unreachable) which went away after installing the Radeon-drivers again. Edit: cairo-dock was also causing trouble.

When rebooting, the fglrx-driver gets loaded, but the nvidia-driver doesn’t. Below is a script that needs to be run (as root) to get nvidia loaded (check if the directory of lspci is correct when not on Ubuntu). First try if ‘modprobe nvidia‘ actually works for you (then run clinfo from AMD’s SDK and see if NVidia pops up). If ‘modprobe nvidia‘ doesn’t work, the installation of the driver was not successful.

#!/bin/bash

modprobe nvidia

if [ "$?" -eq 0 ]; then

  # Count the number of NVIDIA controllers found.
  N3D=`/usr/bin/lspci | grep -i NVIDIA | grep "3D controller" | wc -l`
  NVGA=`/usr/bin/lspci | grep -i NVIDIA | grep "VGA compatible controller" | wc -l`

  N=`expr $N3D + $NVGA - 1`
  for i in `seq 0 $N`; do
    mknod -m 666 /dev/nvidia$i c 195 $i;
  done

  mknod -m 666 /dev/nvidiactl c 195 255

else

  exit 1
fi

If you want this under init.d, then check out this post (check if the directory of lspci is correct, when not on Red Hat). Above script was taken from this blog post by ‘mfatica’ of NVidia. Above found working with NVidia drivers 280.13 and AMD drivers 8.892.

All was tested with AMD APP 2.5 and CUDA 4.0. Let me know if it worked for you, or if you needed to do something extra/different.

A final note. In case you need a totally headless configuration, check this PDF by AMD on remote computing, as AMD needs X to be running.