[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker

[Denis Steckelmacher]

Hello,

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 
say).

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 
elegant.

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 
possible.

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 
importance.

* 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 
implementation.
* 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 
applications.

The questions
=============

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.

Best regards,
Denis Steckelmacher.