After OpenGL 4.5, The Mesa OpenGL 4 Support Matrix

[phoronix]

Phoronix: After OpenGL 4.5, The Mesa OpenGL 4 Support Matrix

Now that OpenGL 4.5 was released yesterday by the Khronos Group, while NVIDIA already has an OpenGL 4.5 driver, it will be a longtime before the open-source Mesa/Gallium3D drivers are able to claim OpenGL 4.5 compliance...

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

[Prescience500]

I'm glad the article mentioned the ability of Mesa to keep up when there's a new graphics API to transition to. With all of this talk of a new graphics API, I've been wondering how such a new API would effect Mesa's ability to keep up, especially in the long run? Will it for sure make things harder to keep up with or might a new API eventually make it easier for Mesa to keep up because of a cleaner and simpler API?

Also, assuming that AMD eventually implements their previously discussed strategy of using the mesa drm for both free and nonfree drivers, how might that effect things relative to just sticking with OpenGL? I know it was suggested by Michael that they might not be pursuing it any longer, we don't really know what is going on. Also, even if it was stopped now, they may pursue it later as the mesa drm slowly catches up to the blob or if Linux market share increases (or other favorable market dynamics change) enough to justify additional investment.

[smitty3268]

I certainly would be incredibly surprised if OpenGL 4.5 support for Mesa was reached within the next twelve months.

I wouldn't be. Maybe 15 months. We're getting very close now.

[Luke_Wolf]

Michael, enough with the negativity about Mesa, seriously. The fact is Mesa is making great progress. Oh sure they won't be at the latest openGL standard for a while, but given that Khronos is likely to take a few years designing the new API, by the time it's ready, Mesa will probably be ready.

Also I would regard AMD's lack of communication on the matter a good thing, not a bad thing. AMD said that it would take a lot of work and it'd take time for them to refactor catalyst and the radeon kernel driver to handle this, Not having word on it means that they're probably still working on it, and of course it has to pass legal which with both the video decode engine and dynamic power management took a really long time, no reason this would go any faster. The only question for me is if there'll really be a point to catalyst by the time that AMD is finally ready to do the code drop, as the only point to catalyst even right now is performance, and I expect the performance difference to only decrease with time, and for that difference to be made smaller faster starting whenever they finish up with getting API support up to current.

[Ericg]

Michael

Hey, Michael, when you do these OpenGL updates can you do us a favor and bold the ones that aren't done yet? It just makes it a lot easier to pick out whats actually LEFT to be done.

[Michael]

Michael, enough with the negativity about Mesa, seriously. The fact is Mesa is making great progress. Oh sure they won't be at the latest openGL standard for a while, but given that Khronos is likely to take a few years designing the new API, by the time it's ready, Mesa will probably be ready.

Also I would regard AMD's lack of communication on the matter a good thing, not a bad thing. AMD said that it would take a lot of work and it'd take time for them to refactor catalyst and the radeon kernel driver to handle this, Not having word on it means that they're probably still working on it, and of course it has to pass legal which with both the video decode engine and dynamic power management took a really long time, no reason this would go any faster. The only question for me is if there'll really be a point to catalyst by the time that AMD is finally ready to do the code drop, as the only point to catalyst even right now is performance, and I expect the performance difference to only decrease with time, and for that difference to be made smaller faster starting whenever they finish up with getting API support up to current.

It's not negativity, it's simply reporting the state of affairs...

Last call it wasn't that they didn't have any update, they couldn't confirm or deny whether the project was even existing at that point...

[Michael]

Hey, Michael, when you do these OpenGL updates can you do us a favor and bold the ones that aren't done yet? It just makes it a lot easier to pick out whats actually LEFT to be done.

Too hard to classify when Intel often has GL extensions implemented but not the other drivers, so what should be bolded?

[schmidtbag]

Hey, Michael, when you do these OpenGL updates can you do us a favor and bold the ones that aren't done yet? It just makes it a lot easier to pick out whats actually LEFT to be done.

Agreed, this would be nice.

I find all these new APIs slightly discouraging. While DirectX, Metal, and sort of Mantle aren't really within the immediate interest of linux, I'm worried about linux and the open source drivers managing to keep up with any APIs beyond OpenGL. Mesa is catching up fast, but it seems a successor to OpenGL is necessary and probable. I'm worried if the drivers will ever get enough time and devotion to mature in terms of performance and architectural functionality; stuff beyond APIs. I would much appreciate being able to use crossfire (without catalyst) before I retire my computer, but with the rate of all these API changes I feel like that might not happen.

[Ericg]

Too hard to classify when Intel often has GL extensions implemented but not the other drivers, so what should be bolded?

Good question. -Personally- I would say as long as one driver has it implemented then I'd mark it as "Done" since the common-infrastructure is probably there and just individual drivers need to handle their driver-specific stuff. But thats just my opinion.

[Daktyl198]

Okay, could somebody PLEASE point me to an explanation of Mesa's part in modern Linux graphics?
For example, how the fuck does Gallium interact with Mesa? It uses "State Trackers" for literally everything EXCEPT OpenGL? That, it passes over to MESA for translation? Wouldn't it be like, 100 times easier to just write an OpenGL state tracker for Gallium3D and leave Intel to deal with their own OpenGL shit? (Since they refuse to use Gallium apparently). The only drivers I really see benefiting from the MESA driver structure are older drivers that really can't change over (or are long dead) and some ARM or other out-of-the-way GPUs

"Duplicating work is bad!" Yeah, but if it made it easier to catch up to OpenGL compliance (For AMD&NVidia&other Gallium users) AND ended up in faster OpenGL on Gallium drivers, why don't we do it?

Again, I'm ignorant on this subject, so could somebody point me to a blog post about this or something?