Developers Voice Concerns About OpenGL 4.1 State Tracker

To no surprise, when mentioning an OpenGL 4.1 state tracker for Gallium3D being proposed as a Google Summer of Code project on Sunday morning, there has been a lot of interest in this work via the Phoronix Forums and several responses from key Mesa developers on the project's mailing list. The consensus among these core developers have been that this project is far too large to be completed over the course of a single summer and that it may not be wise essentially throwing out the Mesa code-base, as proposed by the Belgian student.

The first response to this OpenGL 4.1 Gallium3D State Tracker proposal by Denis Steckelmacher came from Corbin Simpson. Corbin is a former GSoC developer himself when he began work on the ATI Gallium3D R300 driver.

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.

Marek Olšák, a very active independent contributor to Mesa / Gallium3D as of late (particularly with regard to the ATI drivers), responded with a much more detailed analysis. Marek's key points included:

- It doesn't make sense to fork/strip away Mesa.
- IT doesn't make sense to focus upon only the OpenGL 4.1 Core Profile without supporting the OpenGL Compatibility Profile.
- It would take way too long to develop this OpenGL-4.1-core-profile state tracker. Certainly more than a year. Mesa's limited OpenGL 3.x support has already taken years.
- A more useful Google Summer of Code project for Mesa may be to tackle some of the OGL3 functionality already on the project's TODO list.
- If Denis is serious about starting from scratch, a better approach may be due to first work on removing the Mesa IR (Mesa's intermediate representation before the commands are turned into the hardware-specific instructions). When Mesa IR is removed, the TGSI (the Gallium3D IR) could be replaced by real GLSL IR. Eliminating this IR and migrating to GLSL IR is also something Intel has wanted to do and would be needed for them to eventually move over to the Gallium3D architecture after they have invested a lot in enhancing Mesa's GL Shading Language compiler.
- "I am especially interested in the performance improvements the simplified code (mainly state management) would bring."

Brian Paul agrees with Marek's statements.

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.

Denis though has responded back and is still interested in this OpenGL 4.1 State Tracker task.

He seems quite passionate and motivated to develop an OpenGL 4.1 Core state tracker for Gallium3D this summer, so that at least a subset of the specification will work. Fortunately, he is also a fan of phasing out Mesa IR and TGSI. That though is where the mailing list discussion is at right at the moment.

This Belgian student has also joined the Phoronix Forums to engage with that even livelier discussion.

Let's see what will happen this summer and whether he moves forward with writing an OpenGL 4.1 state tracker or focuses just upon improving Mesa. Regardless, we wish him the best of luck as the free software graphics drivers for Linux need all of the help they can get in terms of supporting the latest OpenGL capabilities, making their performance more reputable and closer to the binary blobs, and to support the latest features of the graphics cards on the market.