OpenCL on Kaveri

Kaveri APUs from AMD are the first APUs with hUMA support. This is a big step for OpenCL development. We can now read and write directly from the GPU to global RAM. Copying huge amount of memory from RAM to GPU memory and back is now needless. I want to give a short overview of the characteristics of OpenCL programming with Kaveri and its performance.


By default your Kernel is compiled with 32 bit address width. You should set the environment variable GPU_FORCE_64BIT_PTR to 1 to access the complete RAM. The GPU device of my Kaveri (A10-7850k) has the following specifications:

Device Name: Spectre (AMD Accelerated Parallel Processing, OpenCL 1.2 AMD-APP (1445.5))
Address Bits: 64
Little Endian: true
Global Memory Size: 512 mb
Base Address Alignment Bits: 2048
Global Memory Cache Size: 16 kb
Local Memory Size: 32 kb
Clock Frequency: 720 MHz
Compute Units: 8
Constant Buffer Size: 64 kb
Max Workgroup Size: 256

Since the mentioned GPU has 512 processing units, we get a wave front size of 64 which is typical for AMD. The global memory size is a bit confusing. It pretends that we can only access 512 MB global memory, which is not true.

Continue reading

C++ Web Toolkit Wt (witty)

During the last days I made a simple web application, which serves you chess puzzles to solve. You can see it here
Before starting this little project I decidet to use Wt as a framework to learn something new. Also it seemed to be very easy to use and had similarities to Qt which I am already familiar with.
I want to share my impressions after my first little project with it. I will start with my negativ impressions:

  • The ownership of objects does not feel clear at the beginning. Although there are rules for ownership, there are special cases which may not be intuitive at the beginning.
  • Even for my simple application there were some Wt related bugs that cost me some time.
  • Because Wt is a serverside framework, your UI could feel a bit slow. Wt solves this for some standard usecases. For example a menu widget can preload all its child widgets and switch its content client side. If you want more special things, e.g. change the border color of a widget when it is clicked, you either accept the latency or you have to write javascript code for this. The good thing is Wt offers good ways to integrate javascript.
  • You can choose the layout between two predefined styles and a “bootstrap” theme (in version 1, 2 and 3). In my opinion there could be more predefined themes, although I did not realy miss them.

Of course there are also many good things to mention:

  • Wt comes with many basic examples you can learn from.
  • It is very active developed. All bugs I reported got fixed within one week.
  • All communication between client and server is handled by Wt. This makes web development feel like developing for a desktop.
  • You dont have to care what browser the client is using. Wt handles this.

If I would use Wt again for my next project depends on the complexity of the UI and the communication with the backend. If the UI is extremly complex I would probably choose another framework like GWT, because to make the UI fast you need to have client side code. If the UI is not to complex, and the focus lies on the backend, I would definitely use Wt again.