[Mesa-dev] Organisation of the OpenCL state tracker

Denis Steckelmacher steckdenis at yahoo.fr
Wed Apr 27 06:17:27 PDT 2011


Hello,

I'm very happy to have been accepted as a Google Summer of Code student ! 
Thanks to all who voted for my proposal, and thanks to Google.

It's now the time to discuss the details of the implementation before 
beginning to code. I have already a fairly good idea of how I will implement 
things, but my question for today is "Where do I place my code ?".

Before I start explaining my question, I would say that I launched a 
Wordpress-based blog to share my progress and thoughts with everyone 
interested. It can be reached at http://steckdenis.wordpress.com. I'll try to 
keep it up to date with what I do.

Its first post is about the object of this mail : do I work directly on Clover 
or do I copy it in the Mesa source tree, under src/gallium/state-trackers ?

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 
Gallium util functions exist. Another problem is that the Gallium3D interfaces 
are private, so it will be difficult to build Clover without the Mesa source 
code.

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 blog post ends with a paragraph over the Gallium infrastructure used by 
the state trackers, that is to say the state tracker managers and the state 
trackers APIs (using Mapi). The problem is that OpenCL is only one API. The 
OpenCL context is created by OpenCL itself, not by EGL, WGL or GLX. So, do I 
have to break the Gallium3D model by not using the state trackers APIs, or do 
I have to create a state tracker API (that I will base on the OpenVG state 
tracker, very simple and that I understand very good) and a "pass-through" 
state tracker manager for OpenCL ?

Finally, if I create a directory in the Mesa source tree, how do you want me 
to name it ? Clover, Coal (these two names appear in the current Clover code) 
or the already-suggested Chloride ?

Best regards,
Denis Steckelmacher.


More information about the mesa-dev mailing list