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

[Denis Steckelmacher]

Hello,

Thank you for your mail, it's exactly what I need to be able to find the right GSoC project. I agree with you for most of the points, but I have some small comments.


> 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.

I just read some pages of the OpenGL 4.1 Compatibility profile, chapter E.2 : "Deprecated and Removed Features". The difference in terms of pages is not too big between the Core and de Compatibility profiles, but it seems that implementing the Compatibility profile would require much more work. There are many more functions, more parameters, and also all the fixed-function pipeline that needs to be implemented over the programmable pipeline used by Gallium. Implementing it in a new state tracker will be useless, as it will be reduced to make a new Mesa, during years, and with no gain.

Also, I don't want to replace Mesa but to make a "small" state tracker implementing a subset of OpenGL, and then extending it to cover the latest OpenGL specification available. It's possible that Mesa will continue to be used for years, even with OpenGL 3+ support, in parallel of my state tracker that could be used by pure OpenGL 3+ Core-compatible applications, possibly with a small advance over Mesa in some areas (like performance or features). As you said later in your mail, it could be interresting to see what gains of performance having a smaller and cleaner state tracker could give.

I short, this state tracker would be an experiment, to see how could be the gains of having a lightweight state tracker. It could also be useful is some years if OpenGL 4.x Core becomes widely used on Linux and that Mesa falls too far behind OpenGL.

> 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.

I again agree with your idea. I have just two remarks :

The first one is that I hope that OpenGL 2.x will not be used anymore in ten year (but OpenGL 1.x is still used in some modern applications, so I may be wrong). Starting from scratch could have the same effect as abandoning Classic Mesa in favor of Gallium : a few years of development, and then great results (Phoronix has shown that r300g can now be faster that fglrx in a fair amount of cases). I also hope that more applications will use the OpenGL Core profile, and that the ones that doesn't will stick to what Mesa supports and will support.

The second one is a small division of the OpenGL features I have done on a sheet of paper. It's not comprehensive, only what came in my mind :

* There are changes that will benefit both the new state tracker and the current Mesa implementation, for instance work on the GLSL compiler to support GLSL 3.30 and 4.10, and the infrastructure work in Gallium. Large parts of my work will also be used by the current Mesa.
* The GL3.txt file shows many extensions already implemented, mainly in Gallium (the current Mesa is only touched to expose the client API, the driver work is done in Gallium and will be reused).

Then there are the features I need to reimplement, by copying them from Mesa or by writing them from scratch. Here is the time loss.

> 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.

Here is the big problem, and why I to discuss with the developers instead of coming one day saying "Hello, here is your state tracker" and being rejected.

I completely agree that we cannot do the work without Intel, but the main question is what to do with Mesa IR and TGSI.

I first thought that my state tracker could directly pass GLSL IR to the pipe drivers, modified in my branch to accept GLSL IR. Then I saw that this would require far too much work to modify all the pipe drivers and that I cannot do this alone.

Your solution seems the best : starting by removing Mesa IR from Mesa and passing GLSL IR directly to the pipe drivers (without going through the TGSI step of the migration) . I think that it would be possible to make the pipe drivers able to use either TGSI or GLSL IR, possibly using a "light" version of my state tracker (implementing only what is needed to test the infrastructure with examples and some real applications) to check that all is good, and then work on Mesa to remove Mesa IR, having the pipe drivers ready, and giving time to Intel to work on their Classic driver. Nevertheless, I don't know if it will be easy to use GLSL IR with Gallium and with the classic drivers (here are plenty of classic drivers to make compatible with GLSL IR, except if we choose to have both GLSL IR and Mesa IR supported in the current Mesa state tracker).

I think it's all I wanted to say. I repeat that I agree with you and I am ready to work on whatever part of Mesa you want or is the best for Free Software. These remarks are here to expose idea. Maybe some of them will be useful :) . I'm also sorry for the big and maybe difficult to understand mail.

Best regards,
Denis Steckelmacer.