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

[Corbin Simpson]

Sounds quite cool. This would definitely be a worthwhile project. My
only concern is that this would be too much work for a single summer.
Projects should err on the side of being too small rather than too
big.

I'd definitely recommend applying when applications are open.

On Sun, Mar 13, 2011 at 4:09 AM, Denis Steckelmacher
<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, 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
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>