Gallium3D OpenCL May Finally Get Some Needed Love

It was in early 2009 when we heard that OpenCL and OpenGL 3.1 state trackers would be here hopefully soon for Gallium3D. Well, nearly two years later, neither state tracker has yet to emerge. There's no OpenGL 3.x state tracker in development and core Mesa only has limited support for OpenGL 3.0, while the latest Khronos specification is now at OpenGL 4.1 with OpenGL 4.2 not being far off. There has been work on an OpenCL Gallium3D state tracker for nearly two years, but it's not mainline and is far from working. That may finally change in the coming months.

In the second half of 2009 we saw the emergence of Mesa Clover, which was the initial work by Zack Rusion to bring OpenCL support over Mesa and Gallium3D. To this date, the Clover state tracker and other code has not been merged into the mainline Mesa Git tree but is living in a separate repository. Even the OpenCL Mesa discussions have been minimal over the past two years with no concerted effort to bring the Open Computing Language to open-source drivers. Right now under Linux you can just fine OpenCL support in the closed-source NVIDIA and AMD graphics drivers for their supported hardware. Only once last year that I recall was there even a big discussion about OpenCL for Mesa on the respective mailing list.

Mesa/Clover hasn't been officially touched since last November and is not yet in a state that's useful for end-users or even enthusiasts. This is while Khronos released OpenCL 1.1 last year and we imagine OpenCL 1.2 isn't too far off either. Like the OpenGL situation has become, chances the OpenCL 1.2 specification will be published even before the Mesa / Gallium3D support for OpenCL 1.0 is in place.

Though sparking some new hope for Clover is Denis Steckelmacher. This is the same student developer living in Belgium that a few weeks back proposed writing an OpenGL 4.1 Core state tracker this summer without any OpenGL dependence on legacy Mesa code. While greater OGL3/OGL4 support in the open-source graphics drivers, that proposal for Google's Summer of Code was deemed unrealistic by developers.

Denis had then submitted a new proposal to replace Mesa IR with GLSL IR as that is a less ambitious but still sought after improvement by Mesa developers. There wasn't too much excitement there and LunarG is already working on LunarGLASS, which is to use LLVM IR for Mesa. Intel developers are also supposedly already working on gutting out Mesa IR for GLSL IR too.

Denis has now written a new proposal to the mailing list on Saturday and it involves working on OpenCL support for Mesa. He wrote, "after some messages on this list, I reconsidered my GSoC proposal and decided to give a try at an OpenCL state tracker. I will base my work on the Clover branch of Mesa."

Steckelmacher isn't sure on some LLVM IR to TGSI conversion (LLVM is to be used as part of the OpenCL compiling in Mesa) and some other areas of OpenCL integration into Gallium3D / Mesa, but this seems what he's now interested in addressing if accepted into Google's Summer of Code. If this doesn't end up working out, his next proposal will be to just work on improving Mesa's OpenGL 3.x and GL Shading Language (GLSL) support this summer.

Besides finally having OpenCL support in open-source GPU drivers on Linux, in theory, an OpenCL state tracker may finally make it possible to run OpenCL on the CPU under Linux using open-source software. This would be done by using the LLVMpipe driver that runs on the CPU and is optimized by the Low-Level Virtual Machine. Working OpenCL support would also make it possible to decode videos using it too, such as some of the work that other open-source developers have been tackling to provide WebM/VP8 video decoding over OpenCL, but that work is also in an early and slow state.

Let's hope though that Steckelmacher's ambitions remain high and that he's able to produce working code by summer's end. Also talked about as expressed Mesa GSoC projects this year is a VDPAU state tracker for H.264 and/or possibly WebM and Theora support using shaders on the Gallium3D architecture. Another proposal is for proper multi-GPU and GPU hot-switching support.