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

[José Fonseca]

I also agree with Marek FWIW.

If we want a cleaner / more agile code base, then we could fork off the
old mesa drivers which aren't being actively maintained/tested into a
separate branch, put them in just-bugfixes/no-new-features life support
mode; therefore allowing greater freedom to refactor support for the
active/maintained drivers, without the hassle of updating old drivers
and its associated risks.

Jose


On Sun, 2011-03-13 at 18:42 -0700, Marek Olšák wrote:
> Hi Denis,
> 
> I don't think forking the current Mesa codebase and making a Core-profile-only state tracker is a good idea. The OpenGL 4.1 Core and Compatibility specifications have 518 and 678 pages, respectively, which means more than 70% of the codebase would be the same. The Core profile is not so popular and we still will have to maintain all the deprecated OpenGL 1.x features for the existing applications to work, which is the majority. The deprecated features are not such a big pain and usually they don't get in the way of new, more modern features. Also what if someone is using the OpenGL 4.1 Compatibility profile? We'd be screwed. Note that NVIDIA have no plans to promote the Core profile, they claim the deprecated features run at full speed on their driver and they advise their users to use the Compatibility profile.
> 
> Anyway this is more like a decade project than a summer project to me. Look, there is this GL3 to-do list over here:
> http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
> New features are being implemented at a quite slow pace. A complete rewrite would freeze the feature set for a year or two, because already-implemented features would be worked on again. Also you don't wanna develop a new OpenGL state tracker without Intel on board. I guess that's obvious. A much, much more useful project would be to work on the features listed in the to-do list, and in my opinion this would be the most useful GSoC project for OpenGL users.
> 
> If the main motivation to start from scratch is to clean up the current stack, there is an easier way. The eventual plan could be as follows. First, any necessary work to remove the Mesa IR should be done, after that TGSI could be replaced by the GLSL IR. This is a crucial step for Intel to even consider moving over to Gallium, so it's not like we have any other choice, at least I don't see one. Then the only "classic" driver would be Gallium itself, at which point the cleanup would begin, potentially leading to a merge of "mesa/main" and "st/mesa". I am especially interested in the performance improvements the simplified code (mainly state management) would bring.
> 
> I'd be interested in other people's ideas too.
> 
> Marek
> 
> 
> On Sun, Mar 13, 2011 at 12:09 PM, Denis Steckelmacher <steckdenis at yahoo.fr<mailto:steckdenis at yahoo.fr>> wrote:
> 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<http://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.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org<mailto:mesa-dev at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>