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.
Just a note to not get overly excited about threaded OpenGL in Mesa. While it's true it could help a bunch of games, there's also games it likely won't help or even make worse. Feral Interactive's ports already do it, and I'm sure others do too.

To be clear, I'm not saying it can't help games that already have some form of it in future, and some it could easily help right now.

I recently wrote about AMD developer Marek wanting to get the threaded OpenGL code into Mesa, so use that as a reference if you've no clue what I'm talking about here. Essentially it's an attempt to make Mesa not so CPU-heavy.

The problem is, a bunch of games already use it. A developer from Feral Interactive noted on the Mesa list:
QuoteFor what it is worth, all the Feral games have a dispatch thread that
primarily calls GL functions.

You can see the Feral developer gave even more information in this post when asked about comparisons with how NVIDIA does it in their driver:
QuoteWe can't directly compare to Nvidia's option, as our threaded GL implementation is a necessity for us. OpenGL contexts must be bound to a specific thread, unlike D3D devices, and we have games written for D3D using multiple threads to dispatch graphics work (and sometimes using multiple D3D devices from the same thread). We make one dispatch thread for each GL context to avoid having to unbind the context from a thread. There is some locking so that only one game thread may submit to a context's dispatch thread at once, but that locking is very lightweight compared to what would happen if we repeatedly attached and detached GL contexts on game threads. GL_KHR_context_flush_control was supposed to help with that, by allowing opting out of flushing the GL context when unbinding it from a thread, but last time we tried that, there were some synchronous X requests in SDL2 making it remain slow.

Having said that, we did at one point have a path which used GLX_MESA_multithreaded_make_current when it was available. We found the GL dispatch threads was quicker on all the games we were working on at the time.


So before anyone goes jumping for joy about it possibly landing in Mesa, just be aware that it's not a one size fits all approach and could make some games worse. This is one of the reasons that it wouldn't be enabled by default.

It's nice to see Mesa getting attention from developers really pushing OpenGL, so they can also get more feedback.

Hopefully this feedback will help the Mesa developers decide what to do.

Reading some more replies, it seems like they might go for a whitelist of applications and games known to work with it which does sound like a reasonable solution to me. However, some are not happy with the idea of having any kind of application profiles or specific lists, even just to get the ball rolling.

I expect the discussion on it will go on for some time until a solution is worked out that satisfies the majority. Article taken from GamingOnLinux.com.
7 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.
9 comments

STiAT Feb 7, 2017
Let applications enable/disable threaded gl in Mesa? It'd be as simple as it sounds.
Samsai Feb 7, 2017
QuoteReading some more replies, it seems like they might go for a whitelist of applications and games known to work with it which does sound like a reasonable solution to me. However, some are not happy with the idea of having any kind of application profiles or specific lists, even just to get the ball rolling.
I do understand why some people are negative about such application profiles because in recent times these have been brought up multiple times and it seems that the Mesa devs are increasingly interested in using such profiles. As far as I'm concerned, if they really want to implement these profiles they should at least be kept properly separated from the main logic to keep the code clean in the long run. I would really hate to see Mesa become a mess of case-by-case optimizations on top of other case-by-case optimizations. I'm much more in favour of developers doing those optimizations themselves.
cRaZy-bisCuiT Feb 7, 2017
If a wider range of games will benefit from it I'm totally fine with a white list. I'd rather like to have the threaded optimization be implemented this way then to have an automatic that doesn't work and produces regressions or isn't activated in some scenarios where it might increase the performance.


By the way, is there anyone on the forum that could test the difference of those optimizations with nVidia and "Cities in Motion 2"? If OpenGL 4.x games might not benefit, I'd like to see if this older game does benefit.


Last edited by cRaZy-bisCuiT on 7 February 2017 at 7:35 pm UTC
Guraan Feb 7, 2017
Does anyone know a mirror to the spec? Was trying on mesa3d.org but all links in extensions are broken for me and google did not give any hit.
Liam Dawe Feb 7, 2017
Quoting: Samsai
QuoteReading some more replies, it seems like they might go for a whitelist of applications and games known to work with it which does sound like a reasonable solution to me. However, some are not happy with the idea of having any kind of application profiles or specific lists, even just to get the ball rolling.
I do understand why some people are negative about such application profiles because in recent times these have been brought up multiple times and it seems that the Mesa devs are increasingly interested in using such profiles. As far as I'm concerned, if they really want to implement these profiles they should at least be kept properly separated from the main logic to keep the code clean in the long run. I would really hate to see Mesa become a mess of case-by-case optimizations on top of other case-by-case optimizations. I'm much more in favour of developers doing those optimizations themselves.
Well, I think they just grab from a list, it's not actually in the code directly, that's what a whitelist is for to separate from becoming game-specific stuff.
Guraan Feb 7, 2017
Quoting: Guest
Quoting: GuraanDoes anyone know a mirror to the spec? Was trying on mesa3d.org but all links in extensions are broken for me and google did not give any hit.

Sorry, I'm tired and possibly missing something - which spec are you after in particular?
the ogl registry spec (official/draft) (like the ones on https://khronos.org/registry/OpenGL/index_gl.php), they had the GLX_MESA_multithreaded_make_current document on the mesa3d site but now i cannot even access the root of that one.
Shmerl Feb 7, 2017
Some settings are already application specific in /etc/drirc
Guraan Feb 7, 2017
Quoting: Guest
Quoting: Guraan
Quoting: Guest
Quoting: GuraanDoes anyone know a mirror to the spec? Was trying on mesa3d.org but all links in extensions are broken for me and google did not give any hit.

Sorry, I'm tired and possibly missing something - which spec are you after in particular?
the ogl registry spec (official/draft) (like the ones on https://khronos.org/registry/OpenGL/index_gl.php), they had the GLX_MESA_multithreaded_make_current document on the mesa3d site but now i cannot even access the root of that one.

Hmm, I'm only aware of the Khronos site for official OpenGL specs, and of course the online man pages through opengl.org (which are basically just info pulled from the spec itself). So if they don't have what you're looking for, can't help much there sorry!
No Worries, mesa3d is up again and the spec is available at https://mesa3d.org/extensions.html for those (besides me) that wants to read it O;)

Edit: direct link: https://mesa3d.org/specs/MESA_multithread_makecurrent.spec dated 2011, is this actually the correct one?


Last edited by Guraan on 7 February 2017 at 11:31 pm UTC
Guest Feb 8, 2017
Quoting: liamdaweReading some more replies, it seems like they might go for a whitelist of applications and games known to work with it which does sound like a reasonable solution to me. However, some are not happy with the idea of having any kind of application profiles or specific lists, even just to get the ball rolling.

This is why i feel AMD really needs a GUI control center for Application profiles among other things.
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.