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

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.