Hello,

This is the first post of this blog. I'm very happy to say that I was accepted at the 2011 edition of the Google Summer of Code.

My proposal was to work on the Clover Mesa branch to add OpenCL support to the Free Software hardware acceleration stack. I'm highly motivated and I'll do my best to finish this hard work on time, even with some extras if I have time.

This first blog post is to begin to define the structure of my work. I'll send a mail to the mesa-dev mailing list to ask the devs, but I summarize it here to share my thoughts with others.

The primary question is : do I use a separate code base (Clover) or do I add my work on the Mesa git tree.

Currently, Clover already contains some code, but it's mainly a build-system architecture and some files with function skeletons. The "useful" code seems to be less than 1000 lines long.

If I work directly on Clover, I'll make a library independant of Mesa for the software path, and relying on Gallium for the accelerated path. The problem is that I would have to reinvent the wheel at some places, for exemple where util functions exist. An other problem is that the Gallium3D interface is private, so it will be difficult to build Clover without the Mesa source.

If I create a state tracker in the gallium directory of Mesa, I will be able to use all the Gallium infrastructure and utils, and my work will be easily buildable by every person wanting to test it. This solution isn't perfect though, as I will have to copy/paste and adapt the already-existing code of Clover in a new location, refactoring it from C++ to C.

The Gallium infrastructure is also a bit special : there are two levels of state trackers : one state tracker manager (EGL, GLX or directly the Mesa DRI interface) and one state tracker API (OpenGL, OpenVG, etc). OpenCL doesn't fit very good this model. An OpenGL context can be created using either EGL or GLX, but an OpenCL context is created directly by OpenCL itself. I think I'll have to break the Gallium model my implementing the OpenCL state tracker as a state tracker manager, or even not a state tracker following the Gallium definition but instead a simple piece of code, exposing the OpenCL API, and build into a nice .so library by a very simple Gallium target. I'll look at some other state trackers facing the same problem, like vdpau I think, to see how they integrate with Gallium.

So, I'm open to any suggestion for the archiecture to use for my work.