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:
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:
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.
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
9 comments
Let applications enable/disable threaded gl in Mesa? It'd be as simple as it sounds.
0 Likes
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 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.
5 Likes, Who?
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
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
0 Likes
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.
0 Likes
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.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 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.
0 Likes
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.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.
Sorry, I'm tired and possibly missing something - which spec are you after in particular?
0 Likes
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;)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.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.
Sorry, I'm tired and possibly missing something - which spec are you after in particular?
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!
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
0 Likes
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.
This is why i feel AMD really needs a GUI control center for Application profiles among other things.
0 Likes
Patreon
PayPal
See more from me