[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker
steckdenis at yahoo.fr
Sat Mar 12 06:39:52 PST 2011
I'm a Belgian young student and I follow the Mesa's development for nearly two
years now. I'm just 18 yars old and it's the first year I'm elligible to the
Google Summer of Code.
I originally planned to work on KDE, but I find Mesa more interesting. The
project on which I would work is a pure OpenGL 4.1 Core state tracker for
Gallium 3D. I know that it isn't the easiest task to do during a summer, but I
already started thinking about it and I have plenty of free time from now to
months after the summer (I will begin IT studies, but I do programming for
nearly eight years now (yes, the half of my life), so I hope it will not be
too difficult and time-consuming). I've read parts of the Open GL 4.1 Core
specification, the OpenGL 4.1 Core summary card, and many examples.
Code-wise, I have already dived in the Gallium3D codebase and I understand it.
My nearly two years following of the Mesa's development taught me how a
graphics card works. I especially followed the development of the r300g driver
(I use an ATI Radeon X1270 graphics card) and the llvmpipe driver.
I'll keep it short about me, but feel free to ask me more questions. The
purpose of this mail is to ask some questions and to share some ideas about
this OpenGL 4.1 state tracker. Keep in mind that I'm young and not a
professional in the computer graphics world (and also that my mother language
is French, so sorry for my bad English, and the lack of precision in what I
Here are now some thoughts about this state tracker.
Replacing Mesa ?
I have read the Google Summer of Code Ideas page on freedesktop.org, and there
is an "OpenGL 3.1 state tracker" idea on it. The summary if this idea says
that the student should start by copying Mesa and the Mesa state tracker and
then remove the unneeded stuff. I don't know wich way could be the easiest,
but I think that starting this state tracker "from scratch" could be more
My idea is to create a new directory under src/gallium/state_trackers, and to
put in it most of the state tracker. There are two alternatives : having just
one gl4 state tracker, or having gl4, gles2 and glcommon subdirectories (like
does Nouveau for their pipe drivers). glcommon will contain code shared
between OpenGL and OpenGL ES 2, and the two other directories will contain
code specific to either OpenGL 4 or OpenGL ES 2 (it seems that OpenGL ES 2 is
nearly a subset of OpenGL 4 Core, so it will not be too difficult to have two
state trackers in one).
With these state trackers, implementing the public API of OpenGL, Mesa will
become useless (it will be kept for OpenGL 2.1 compatibility, or even for
OpenGL 3+ compatibility profile when it will be ready). It's possible to put
the rest of the libGL code into src/gallium/targets. This piece of code will
load the proper pipe_driver and state tracker, using either GLX or EGL, if
Advantages of starting from scratch
Starting from scratch requires more work but is also more future-proof. We can
for instance build the state-tracker in a way compatible with OpenGL ES and
OpenCL, to ease the implementation of GL_ARB_ES2_compatibility and sharing of
objects between OpenGL and OpenCL. A clean code-base is also easier to extend
when future versions of OpenGL will be available.
It's also convenient to be able to cleanup Mesa, in a heavier and quickier way
than copying it and removing stuff. I will say later what I want to drop.
Last, big parts of Mesa can be copied, for example the GLSL compiler. The best
of Mesa can be kept.
What to implement
Here are what I would try to implement in this state tracker, in order of
* The OpenGL 3+ core API, starting at OpenGL 3.0, with the infrastructure done
to be able to easily add features up to OpenGL 4.1 and future versions. For
this, the state tracker must be clean and not too big. Implementing a feature
in Gallium and the pipe drivers is already complex enough.
* The EGL and GLX context-creation APIs. I'll start with EGL, which is used on
Wayland and cleaner than GLX.
* If it is easy to add just what is needed to have the OpenGL ES 2 API
available, and if I've the time, I will also try to do that.
* An implementation of some GL3 or GL4 features in llvmpipe is possible too. I
have no graphics card capable of OpenGL 4 (only a RS690M, using the r300g
driver), so it seems that I will not be able to test this state-tracker on
real hardware (I've a GeForce 210, 3.3-capable, but I don't know if Nouveau is
ready to support OpenGL 3).
* It could be useful to be able to use the OpenVG state tracker in my EGL
* Maybe Clover can be used to add OpenCL support to this state tracker.
What not to implement
In short : all the old stuff.
* OpenGL 1.x, OpenGL 2.x and the Compatibility profile.
* Support for DRM drivers.
* The indirect mode of GLX, wich isn't used anymore by the majority of
The first one is : are you interested by this ? Do you think it is possible to
start this state tracker and to have it in a "testable" shape in three months
(by "testable" I mean that we can run some example programs that use only a
subset of the OpenGL Core profile, for example KWin, compatible with OpenGL ES
2, OpenGL 3 Core and which can use EGL).
I've also a question regarding the GLSL compiler and TGSI : I will not
implement an ir_to_mesa converter, but instead an ir_to_tgsi if needed. I
don't know what is going on in the work of replacing TGSI with GLSL IR or even
with LLVM IR. Fortunately, i think that converting the GLSL compiler's output
to what can be used in the pipe driver will not be the more difficult part of
the state tracker.
Lastly, I have still to completely understand mapi and all the code handling
the creation of a context given an API and extensions. Maybe this code is only
needed for indirect GLX.
Thanks for reading. I understand that this task is very big, but I hope that I
will be able to make interesting things during this summer and that it will
help Mesa to catch up on OpenGL. I will now continue to read the Gallium
interfaces code and the OpenGL spec. I'm open to any question or remark.
More information about the mesa-dev