GPU Graphics Processing

It is pretty normal that graphics applications use GPU power for their image processing needs. The graphics cards where primarily designed to better support that kind of processing and offload computational power requirements from the main processor the CPU.

GPU computing came not over night. It was first introduced for boosting 2D applications. Simple desktop operations like moving a regions like a window or scaling and help in fast video decoding where first targets. Somewhat later came support for 3D operations. The later is now widely used through OpenGL APIs. The capabilities of the graphic cards increased and OpenGL was extended to support specialised programming on the GPU. The fragment and vertex shaders appeared. Programming of them is in a assembler language. So do not expect much convenience reading, while looking at the assembler code. However, for hard coded graphic operations it plays quite nicely. Compiz, for instance, uses this language for its desktop effects. Long times the assembler code was only available through the proprietary OpenGL drivers from ATI, Nvidia or Intel. Now the open source drivers begin to mature in supporting GPU programming. So it is possible to run Compiz with newer versions of the Nouveau or Radeon drivers. These two types of shaders, vertex and fragment, where joined and later a more convenient expression form for shaders was specified through GLSL. GLSL is OpenGL Shader Language. Newer OpenGL API’s support programming of them in a more straight forward manner. GLSL is officially part of OpenGL since version 2.0.

The C-like GLSL language is much more pleasing at least to most developers eyes. So it is possible to use this language by non specialised programmers to do fast computing on the GPU. If you understand and can write C, imagine you create a graphics filter of your own and process your graphics data through OpenGL directly on the GPU. Its fast and slick and you do not have to wait for a programming hero to convert your favorite algorithm for the GPU to run reasonably fast. But its works only on GPU’s. So either there is a software fallback in case your driver does not support GLSL or you are limited to a subset of hardware and drivers. Thats not so good for sharing and wide spreading your nice ideas.

The Kronos Group, which is the formal body behind OpenGL, specified the new OpenCL standard to improve portability and allow for much more flexible programming. OpenCL has, like GLSL, a C-alike syntax. It is a subset of C with some extensions. OpenCL is now adopted by osX SL and available as vendor driver from Nvidia. If you read adopted by Apple’s osX, you guess right, it is as well available for phones and tablet computers. The AMD Stream SDK contains a OpenCL implementation for CPUs. OpenCL makes the GPU now scriptable with a easy fallback to CPU. Of course thats all very young and up to date exist no open source implementation.

Cross Platform Toolkits and CM

Some readers might wonder, why ICC Examin has not yet a new osX package. There are several issues with FLTK. The most annoying is FLTK has no real colour management policy. But stop. Which cross platform toolkit has? Right – none. Qt has non, Gtk – don’t know? The situation dates from times where RGB was just native display values. But that is changing completely. osX has with SL colour server functionality on top of Quartz integrated. On Linux early prototypes date back to 2008 and start to be integrated as CompIcc project.

Application developers be warned. FLTK and Qt defaults to “Generic RGB” on osX SL. This means no sRGB primaries, alias a different Gamut, and a Gamma of 1.8.

Do not assume sRGB on all platforms. And worse, a application can not assume anything about the colour space of the toolkit. Trolltech and FLTK, and Gnomes Gtk too, can change the underlaying colour space at good will. So colour managed applications using these cross platform toolkits are merciless exposed to this situation.