After OpenGL 4.5, The Mesa OpenGL 4 Support Matrix

[spiridow]

It would be nicer if we had something like this:

http://www.x.org/wiki/RadeonFeature/#index1h2

It could be generated using script from GL3.txt, with some manual edits if needed.

Maybe there already exists something like this on some wiki?

http://cgit.freedesktop.org/mesa/mesa/plain/docs/GL3.txt

[OneTimeShot]

Actually, I think that MESA is now already "fully caught up" in so far as it supports pretty much everything that the Intel IRIS chipset does (OpenGL 4.0/4.2 depending on which one you buy). Note that Intel are the only company that have a big requirement for MESA to match their chips' capabilities, so that is what is happening.

I am at the point where I really think that the bits of MESA Intel haven't done are the bits where Haswell IRIS chips have bugs. Which would certainly explain why their Windows drivers "support OpenGL 4.0, but it doesn't work very well"...

Almost certainly the Broadwell chips will fix the hardware OpenGL 4.2 bugs, allowing Mesa to progress a bit further. I'll bet that existing Haswell chips *never* get to OpenGL 4.0, just like older Intel chips never got to 3.3 (although the marketing said they theoretically could!).

Whether Broadwell's 4.5 OpenGL support is buggy is something we'll find if MESA stops at 4.3 later next year

[GreatEmerald]

Nice, so by the time tessellation is done we'll be instantly up to 4.2.
So, how about skipping Mesa 11 and 12 and going right to Mesa 13?

[przemoli]

Michael,

Can You use smaller font of cont. width next time?

Like this:

GL 4.1, GLSL 4.10:
GL_ARB_ES2_compatibility DONE (i965, nv50, nvc0, r300, r600, radeonsi)
GL_ARB_get_program_binary DONE (0 binary formats)
GL_ARB_separate_shader_objects DONE (all drivers)
GL_ARB_shader_precision started (Micah)
GL_ARB_vertex_attrib_64bit not started
GL_ARB_viewport_array DONE (i965, nv50, nvc0, r600)

vs

GL 4.1, GLSL 4.10:
GL_ARB_ES2_compatibility DONE (i965, nv50, nvc0, r300, r600, radeonsi)
GL_ARB_get_program_binary DONE (0 binary formats)
GL_ARB_separate_shader_objects DONE (all drivers)
GL_ARB_shader_precision started (Micah)
GL_ARB_vertex_attrib_64bit not started
GL_ARB_viewport_array DONE (i965, nv50, nvc0, r600)

[log0]

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?

Mesa is the frontend, exposing OpenGL(ES), GLX/EGL. It passes data to Gallium or to drivers (Intel and co). It also handles a lot of the really common functionality, shader compiling, functionality emulation etc. Gallium implements a set of state trackers OpenGL(ES), GLX/EGL, Xorg, video stuff, (D3D). A Gallium driver only has to target Gallium and will get all this functionality for free, doesn't have to implement all this state trackers itself. That is my understanding of the story. There is no conflict with Intel drivers afaik.

[Emdek]

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.

It would be nicer if we had something like this:

http://www.x.org/wiki/RadeonFeature/#index1h2

It could be generated using script from GL3.txt, with some manual edits if needed.

Maybe there already exists something like this on some wiki?

[Luke_Wolf]

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...

You did not just report the state of affairs, you put a negative spin on it by focusing on the fact that it's not at the latest standard, and using statements like it being years behind, and you've done this each time you've done one of these articles as of late. Putting a positive spin on it would be showing how much progress has been made and putting a predictive outcome on when Mesa is likely to reach OpenGL 4.5 support. Simply reporting the facts would be to simply highlight the changes since the latest stable Mesa, with no predictive statements, and any commentary being on what are the big ticket items and which are the small jobs for what needs to be completed.

And I thought you knew better about Politispeak, "We can neither confirm nor deny the existence of project X" means either:
A). The Project is currently underway but we are not prepared at this time to speak about it
B). We're currently evaluating the feasibility of this project and we're still deciding if we're going to go through with it
or
C). We want to keep our options open and not commit to anything at this time.

[mark45]

OpenGL 4.x is only relevant for a small portion of AAA games, other than that almost no software stack uses it and since the new Khronos graphics API is about to cover GL 4.x and up it's better to just wait for the new API to come up and learn it. Nvidia support should come right after the new API is published, as usually.

Besides, the new Khronos API will certainly be (much) simpler and better than GL4. With GL4 you have 20 ways to do the same thing and each way may or may not work properly on different drivers.

[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?

[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.