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 > <steckde...@yahoo.fr<mailto:steckde...@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@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
