[Mesa-dev] Organisation of the OpenCL state tracker
maraeo at gmail.com
Fri May 20 00:22:05 PDT 2011
On Wed, Apr 27, 2011 at 3:17 PM, Denis Steckelmacher
<steckdenis at yahoo.fr> wrote:
> 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
> 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.
I guess anything using the Gallium interface should live in Mesa.
Moving Clover to src/gallium seems reasonable to me.
There actually is C++ code in Mesa - it's the GLSL compiler, so C++
doesn't seem to be a problem, but still C is preferable.
More information about the mesa-dev