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

Brian Paul brian.e.paul at gmail.com
Mon Mar 14 09:08:29 PDT 2011


Denis,

I completely agree with Marek.  It always sounds exciting to start
with a clean slate and disregard the "old" code but I don't think it's
the right move here.

A very large portion of the 4.1 core profile overlaps with the code we
have now and the code we need to write to support OpenGL 3.x.  It just
doesn't make sense to fork the code and duplicate that work in two
places.  Not to mention bug fixing etc.

As Marek mentioned, there's a number of Mesa projects that would be
better candidates for Summer Of Code projects.  We'd certainly welcome
your help with those.

-Brian


On Sun, Mar 13, 2011 at 7:42 PM, Marek Olšák <maraeo at gmail.com> 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>
> 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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>


More information about the mesa-dev mailing list