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.
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
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
6 comments
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.
There isn't much missing from OpenGL 4.4 either.
3 Likes, Who?
unless you use haswell, in which case nothing changes, not until the release after this one
0 Likes
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).
0 Likes
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!)
0 Likes
Ou
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.
Quoting: mattsturgeonQuoting: 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.
1 Likes, Who?
mattsturgeon May 27, 2016
Quoting: MyeulCOuQuoting: mattsturgeonQuoting: 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 :)
0 Likes
Patreon
PayPal
See more from me