[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