Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.
Oh wow, didn't expect this so soon. The Mesa driver for Intel graphics and Nvidia Fermi (GeForce 400, GeForce 500) on Linux have now reached OpenGL 4.3 compliance with "ARB_robust_buffer_access_behavior" now being done.

A pretty impressive push has been done on Mesa recently, which a lot of people are going to see the benefits from soon enough.

As always, you can see the current status of OpenGL support in open source drivers on the Mesa Matrix website.

Looks like the next stable Mesa release is going to be a really good one. Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
6 comments

Kristian May 24, 2016
They also removed "KHR_robust_buffer_access_behavior" from GL3.txt, meaning that as it stands now nvc0 and radeonsi are only missing "GL_KHR_robustness" from OpenGL 4.5. i965 is also missing "GL_ARB_ES3_1_compatibility" but it does support OpenGL ES 3.1.

There isn't much missing from OpenGL 4.4 either.
edo May 24, 2016
unless you use haswell, in which case nothing changes, not until the release after this one
Pecisk May 25, 2016
Nice rush towards completing OpenGL API support. There's lot of things to be done but it is awesome to see so much progress revealed. Intel needs support of older archs where it's suitable, and of course optimize and speed will be next goal for devs (as API will be locked in place).
mattsturgeon May 25, 2016
Quoting: edounless you use haswell, in which case nothing changes, not until the release after this one

Are you saying this is only for broadwell and newer? (I've got a sandy bridge (i5-2450M) laptop)

I was under the impression mesa was the userspace side and device specific drivers were in the kernel (not that I've actually looked into it!)
MayeulC May 25, 2016
Ou
Quoting: mattsturgeon
Quoting: edounless you use haswell, in which case nothing changes, not until the release after this one

Are you saying this is only for broadwell and newer? (I've got a sandy bridge (i5-2450M) laptop)

I was under the impression mesa was the userspace side and device specific drivers were in the kernel (not that I've actually looked into it!)

Well, there are of course device specific drivers in the kernel, but in userspace too, because you need to generate machine code tailored to the one you will be running it on. Drivers that use Gallium 3D, which acts as an abstraction layer for device functionality, can be used to share some common code between drivers, thus sometimes enabling features for multiple drivers as a time (think about syntax evolutions,for example, like array of arrays. Once you did the code to handle it, which is based on previous driver code, it enables it in multiple drivers). Intel is not using Gallium, though, so they have to do their their own thing in i965.
mattsturgeon May 27, 2016
Quoting: MyeulCOu
Quoting: mattsturgeon
Quoting: edounless you use haswell, in which case nothing changes, not until the release after this one

Are you saying this is only for broadwell and newer? (I've got a sandy bridge (i5-2450M) laptop)

I was under the impression mesa was the userspace side and device specific drivers were in the kernel (not that I've actually looked into it!)

Well, there are of course device specific drivers in the kernel, but in userspace too, because you need to generate machine code tailored to the one you will be running it on. Drivers that use Gallium 3D, which acts as an abstraction layer for device functionality, can be used to share some common code between drivers, thus sometimes enabling features for multiple drivers as a time (think about syntax evolutions,for example, like array of arrays. Once you did the code to handle it, which is based on previous driver code, it enables it in multiple drivers). Intel is not using Gallium, though, so they have to do their their own thing in i965.

I must have been under the (wrong) impression that all the mesa drivers were using the same abstraction - or that all the open source kernel drivers were outputting the same low level API..

Thanks for the info :)
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.