OpenGL 4.3 Support Is A Ways Out In Mesa

[phoronix]

Phoronix: OpenGL 4.3 Support Is A Ways Out In Mesa

While the OpenGL 4.3 specification was just released (along with OpenGL ES 3.0), there's already a beta NVIDIA Linux proprietary driver supporting this latest desktop graphics API from Khronos. AMD will also soon be released a Catalyst beta with the GL 4.3 / GLSL 4.30 support. However, the open-source Mesa support will still be a ways out...

http://www.phoronix.com/vr.php?view=MTE1NTI

[brent]

It would be great to see more focus in Mesa development. Many of the features required for GL 3.2/3.3 and even some required for 4.x are already done, but support for 3.1 still isn't fully done yet! It would make more sense to focus on completing 3.1, and after that 3.2, and so on.

[Prescience500]

With Gallium and all, shouldn't this process go faster this time around because devs can focus more on optimizations and features than simple enablement?

[sandain]

It would be great to see more focus in Mesa development. Many of the features required for GL 3.2/3.3 and even some required for 4.x are already done, but support for 3.1 still isn't fully done yet! It would make more sense to focus on completing 3.1, and after that 3.2, and so on.

To my knowledge, the only major hurdle to getting OpenGL 3.1 support out the door is ARB_uniform_buffer_object, which although listed as 'not started' is nearing completion on Intel hardware thanks to Eric Anholt. GL 3.2 and 3.3 should also fall into place rather quickly given the fact that most of the extensions are already done.

I would have to argue that it doesn't make much sense to focus only on the 3.1 features, then 3.2, etc. Picking the low hanging fruits and scratching itches first seems like the way to move forward most rapidly.

[Kayden]

The GL_ARB_debug_output support in Mesa originated with a request from Valve for Mesa supporting this OpenGL extension

Actually, Mesa's support for GL_ARB_debug_output was written by Dylan Noblesmith (nobled), a community contributor, with some finishing touches from Marek. While at Valve, Eric made our driver output some performance data via ARB_debug_output, but this was really just leveraging the work nobled had done...the extension already existed.

[9a3eedi]

I hope this doesn't sound like a very stupid question, but what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of a lack of developers or funding? Or lack of documentation and avaliable specifications for the things they're working with? Or is it perhaps due to patent issues?

I was just wondering... I don't mean to imply that Mesa aren't doing a good job.. In fact, they're doing a pretty good job if you ask me

[smitty3268]

what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of

a lack of developers

Yes.

funding?

Yes.

Or lack of documentation and avaliable specifications for the things they're working with?

No.

Or is it perhaps due to patent issues?

No, except for floating-point textures, required for 3.0+, which are present in Mesa but not compiled by default unless you configure it to ignore those patents.

[Kayden]

I hope this doesn't sound like a very stupid question, but what is the reason that Mesa is lagging behind in terms of OpenGL support? Is it because of a lack of developers or funding? Or lack of documentation and avaliable specifications for the things they're working with? Or is it perhaps due to patent issues?

I was just wondering... I don't mean to imply that Mesa aren't doing a good job.. In fact, they're doing a pretty good job if you ask me

Thank you :) I'd say it was a lack of developers, and now it's just that we have a lot of ground to catch up.

When I started working on Mesa two years ago, the Intel 3D "team" was basically Eric and Ian. Plus, Eric was also maintaining the kernel tree at the time, so his attention was divided. (There were a few others, but mostly those two; Kristian had also been working on GL, but was beginning to transition to Wayland as his primary focus.) When it comes down to it, there's really only so much you can do with two guys...especially when you break that down into: 1) adding support for new GL extensions and versions, 2) new hardware bring-up, 3) bug fixing, 4) performance enhancements, 5) writing a shader compiler, 6) developing an open source OpenGL conformance suite (piglit), 7) customer support and random firefighting, and more. Even with amazing developers, it's just too much.

Fast forward to today, and things look a lot different. There are ~eight of us in Portland who meet up regularly, all working full time on OpenGL. In the extended team, there are several people dedicated to working on the kernel, one working on developer tools, a number of people working on Android and EGL related stuff, and more. With the extra help, we're finally beginning to catch up and close the gap. The pace at which things are getting done has definitely increased substantially. Plus, we still have solid help from the rest of the community. Brian remains a constant aid to us, especially as we evolve core Mesa, and we're really grateful. Jose's work on apitrace is invaluable. I could go on and on.

Access to the GL specs is not an issue...the specs for everything we're working on are publicly available at either opengl.org or khronos.org. Ian's also fairly involved with the OpenGL ARB (architecture review board), so he stays on top of the latest specs. Hardware documentation varies. The Intel developers are in good shape there. I think things are decent for AMD hardware as well, though I'd have to defer to one of the Radeon developers. As far as I know, Nouveau continues to be completely reverse engineered, which has to be extremely hard.

[PeterKraus]

So in this "extension matrix", the extensions marked as "DONE (x,y)" are working only on X and Y? And stuff marked as "DONE" works on all platforms?
Cheers.

[Jonno]

So in this "extension matrix", the extensions marked as "DONE (x,y)" are working only on X and Y? And stuff marked as "DONE" works on all platforms?

In theory yes, but in practice, DONE sometimes mean DONE (swrast). And DONE (x) sometimes mean "work on some hw using x" (usually a hw generation, rarely a single hw model). And it is not always kept up-to-date, so DONE(x,y) does not always preclude it from working on z too. Additionally, DONE (swrast) means it work on at least one of softpipe and llvmpipe, not always both...