Mesa 18.0.4 Released With A Handful Of Bug Fixes

[F.Ultra]

... sometimes is better to let people think you are a moron, than type something and remove the doubt completely.

This Odin knew to be true in ancient times. Hávamál (Sayings/Songs of the High One) #27 roughly translated:

A foolish man,
who among people comes,
had best be silent;
for no one knows
that he knows nothing,
unless he talks to much.
He who previously knew nothing
will still know nothing
talk he ever so much.

[nanonyme]

Why attack him? I want Mesa to support compatibility OpenGL 4.6 too. There are some use cases, including some games, that need it. I hope sometime in the future developers will have some free time to tackle it.

Any real-world examples of such games so we don't need to move in the world of imaginary software where you might as well yearn for OpenGL 10?

[F.Ultra]

Why attack him? I want Mesa to support compatibility OpenGL 4.6 too. There are some use cases, including some games, that need it. I hope sometime in the future developers will have some free time to tackle it.

If so then the games should request a core context and not a compatibility context. The reasons for all of this can be seen at the OpenGL Wiki https://www.khronos.org/opengl/wiki/..._and_Profiles:

Context types

Until version 3.0, all versions of OpenGL were fully backwards compatibile with earlier ones. Code written against OpenGL 1.1 could execute just fine on OpenGL 2.1 implementations.

OpenGL version 3.0 introduced the idea of deprecating functionality. Many OpenGL functions were declared deprecated, which means that users should avoid using them because they may be removed from later API versions. OpenGL 3.1 removed almost all of the functionality deprecated in OpenGL 3.0. This includes the Fixed Function Pipeline.

However, since many implementations support the deprecated and removed features anyway, some implementations want to be able to provide a way for users of higher GL versions to gain access to the old APIs. Several techniques were tried, and it has settled down into a division between Core and Compatibility contexts.

There are other context variations as well. OpenGL 3.1 and ARB_compatibility

A new extension, ARB_compatibility, was introduced when OpenGL 3.1 was revealed. The presence of this extension is a signal to the user that deprecated or removed features are still available through the original entrypoints and enumerations. The behavior of such implementations is defined with a separate, much larger, OpenGL Specification. Thus, there was a backwards-compatible specification and a non-backwards compatible specification. OpenGL 3.2 and Profiles

When OpenGL 3.0 was introduced, a new context creation mechanism was introduced as well. Since later versions could remove functionality, it was important that the user be able to ask for a specific version of OpenGL, one that they had written their code against.

However, the ARB_compatibility extension posed a problem: the implementation decided whether to define it or not. A user could not request to deactivate ARB_compatibility; it was forced on them. This also meant that the core specification had to be a proper subset of the compatibility specification; the core specification couldn't provide functionality that the compatibility one did not provide.

Thus, another change was made to context creation.

The 3.0 form of context creation did not have the concept of profiles. There was only one form of OpenGL: the core specification. In 3.2, OpenGL was effectively split into two profiles, core and compatibility. An implementation was only required to define core, so compatibility is not guaranteed to be available. However, on most implementations, the compatibility profile will be available.

Platform Issue (MacOSX): When MacOSX 10.7 introduced support for OpenGL beyond 2.1, they also introduced the core/compatibility dichotomy. However, they did not introduce support for the compatibility profile itself. Instead, MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.


The 3.2 wording also changed what kind of contexts can be returned, allowing 3.0 and higher versions to be given when not directly asked so long as they support ARB_compatibility or are the compatibility profile of that version of OpenGL. So if you ask for 2.1, the implementation is free to give you 3.2 compatibility; it was not previously free to do this.

Because of the change in wording, the way to detect the changed functionality is to check the extension string. If WGL_ARB_create_context_profile is present, then it uses the 3.2 wording. Otherwise it uses the 3.0/3.1 wording. Forward compatibility

A context, of version 3.0 or greater, can be created with the "forward compatibility" bit set. This will cause, for the given profile, all functionality marked "deprecated" to be removed. You can combine the forward compatibility bit with core and compatibility contexts.

For 3.0, this means that all deprecated functionality will no longer be available. This simulates the 3.1 experience.

For 3.1, this means that any remaining deprecated functionality (things deprecated in 3.0 but not removed in 3.1) will be removed. Basically, wide-lines. Also, you're not likely to see implementations offer ARB_compatibility if you pass forward compatibility.

For 3.2+ compatibility, it should mean nothing at all. Since no functionality is marked deprecated in the compatibility profile, the forward compatibility bit removes nothing.

For 3.2+ core, it again means that all functionality that is still deprecated (wide-lines) will be removed.

Recommendation: You should use the forward compatibility bit only if you need compatibility with MacOS. That API requires the forward compatibility bit to create any core profile context.

[TemplarGR]

Any real-world examples of such games so we don't need to move in the world of imaginary software where you might as well yearn for OpenGL 10?

You don't need to be smug when you obviously don't know what you are talking about, you only end up embarrassing yourself... One such example is Dying Light... And you can find many others if you only use google.

[nanonyme]

You don't need to be smug when you obviously don't know what you are talking about, you only end up embarrassing yourself... One such example is Dying Light... And you can find many others if you only use google.

That's really bizarre. Compatibility contexts literally means you're using legacy features that were removed so it can't be using 4.6 feature set well. Edit: just checked, nothing above 3.3 compatibility context is required for Dying Light. So yeah, the distance to catch isn't nearly as large as insinuated in the first post

[F.Ultra]

That's really bizarre. Compatibility contexts literally means you're using legacy features that were removed so it can't be using 4.6 feature set well. Edit: just checked, nothing above 3.3 compatibility context is required for Dying Light. So yeah, the distance to catch isn't nearly as large as insinuated in the first post

I think the main problem is that from what I've hear the binary nvidia drivers sets the version on both comp and core to the same value so devs who use nvidia (and many game devs seams to do) sees that and probably uses the wrong context due to not understanding which profile does what. It's the same that happened to the gamma settings, lots of games set the gamma in the wrong context which nvidia accepts which is why e.g you cannot change gamma in games like Amnesia on mesa.