Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay!
You may remember recently I wrote about 'threaded GL dispatch' in Mesa possibly getting merged, after AMD's Marek suggested it and there was some backlash, well, it has continued.

For those that don't know, threaded GL dispatch will help to split up the application and OpenGL into different threads to hopefully improve performance. It can improve some games, while make things worse on others (some already do it in-engine).

Ian Romanick replied to the mailing list entry without pulling any punches:
QuoteNo, it absolutely is not fine to merge. We have never allowed such a thing, and I'll be damned if I'll allow this project to start. Things that land that are known to be broken never actually get fixed. Then we have to waste time fielding bug reports and Phoronix threads because
users turn on the performance features and everything breaks. It's just a terrible idea.


However, Eric Anholt was keen to point out they often merge-in code that's not even close to being done:
QuoteYeah, just like how we gated the GLSL compiler until it was completely done (we didn't) and NIR until it was completely done (we didn't) and Vulkan until it was completely done (we didn't) and...

Software that people care about gets fixed. I'm also concerned that nobody actually cares about getting glthread working completely, given Marek's attitude toward piglit conformance (and my also ignoring the branch for the last however many years). However, "we have never allowed merging broken software that's only turned on under env vars/configure" is totally false. We do that regularly for big things we care about.


There seems to be a lot of words being thrown around, which is perfectly normal for big changes to projects like this it's just that this is all on a public mailing list where anyone can subscribe to see it.

Also, it seems Civilization VI is another game that would benefit from it and Valve are apparently looking to use the code with a white-list on SteamOS, from Marek's post:
QuoteFYI. Civilization VI is another game that works with and benefits from glthread. The game was just released. Even Nvidia is CPU-bound on highest details and can't reach 45 fps with full hd. People wanting to play Civ VI with decent frame rate will want glthread. I don't think they care too much about our the community processes, so I expect there will be quite a few users using out-of-tree builds of Mesa.

Also, Pierre-Loup from Valve said on IRC yesterday that they are probably gonna ship glthread and make their own whitelist, regardless of the outcome of this discussion. It would be preferable to have that whitelist in master too, but that may be difficult if we can't merge it.

If distributions and vendors start shipping glthread, we might as well merge it, because at that point there is no advantage in keeping this out of tree if it forces users to use out of tree builds. We'll get bug reports regardless.


It will be very interesting to see what the real outcome is, hopefully whatever is better for the end-user and not what the developers feel should be the way because of ideological reasons or whatever. Article taken from GamingOnLinux.com.
7 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more information here.
About the author -
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.
See more from me
The comments on this article are closed.
18 comments
Page: 1/2»
  Go to:

GustyGhost 10 February 2017 at 2:16 pm UTC
If SteamOS does adopt a whitelist for this, it really could become a "best distro for gaming" out of the box.
Creak 10 February 2017 at 2:26 pm UTC
View PC info
  • Supporter
  • Top Supporter
Oh "whitelist"... I don't like where this is going...

This is exactly what proprietary NVIDIA and (ex-)AMD drivers do and it has a lot of repercussions on the maintainability and stabilization of the drivers. It is also a pain in the ass to debug since each and every games will have their own special tweaks specified in the drivers, which means more code paths to debug.

Oh this is a BAD idea..
Liam Dawe 10 February 2017 at 2:36 pm UTC
CreakOh "whitelist"... I don't like where this is going...

This is exactly what proprietary NVIDIA and (ex-)AMD drivers do and it has a lot of repercussions on the maintainability and stabilization of the drivers. It is also a pain in the ass to debug since each and every games will have their own special tweaks specified in the drivers, which means more code paths to debug.

Oh this is a BAD idea..
It shouldn't be as complicated as you think, it is after-all only checking a single white-list for one feature to see if they need to look at that code. That's until they make it smart enough to not need the white-list. Sure, it adds a bit of complexity, but everything they add does. Like Marek keeps saying, it will not be enabled by default so users shouldn't run into problems.
Creak 10 February 2017 at 2:44 pm UTC
View PC info
  • Supporter
  • Top Supporter
I think that GL threading is definitively not the silver bullet. I know... I keep posting that everywhere, but GL threading is almost the same as the threading capacities in Vulkan. And in the end, look at the benchmark differences between OpenGL and Vulkan: zero. Some games win a bit, but not that much, and some games loose a bit too.

For instance, look here: http://www.phoronix.com/scan.php?page=article&item=mesa-17-radeon&num=1
The improvements between 13.0 and 17.0 are very impressive on the RADV (kudos to the devs!), but if you compare the 17.0 results in Dota 2 for Vulkan and OpenGL, OpenGL wins all the time! And as for The Talos Principle, Vulkan is now just on par with OpenGL performances.

I'll repeat that again: multi-threading the renderer is, of course, a good thing, but a game engine is not just a 3D engine.

Edit:
About the whitelist, today it's "just" threaded GL, but if we open this door, a lot of other features will get in this whitelist as well.


Last edited by Creak at 10 February 2017 at 2:51 pm UTC
Creak 10 February 2017 at 2:54 pm UTC
View PC info
  • Supporter
  • Top Supporter
CreakAbout the whitelist, today it's "just" threaded GL, but if we open this door, a lot of other features will get in this whitelist as well.
Well.. it was even faster than I expected...
http://phoronix.com/scan.php?page=news_item&px=Mesa-RFC-DRIRC-Compat-Change
FireBurn 10 February 2017 at 3:10 pm UTC
We already have a list of programs that don't conform to strict OpenGL standards and thus driconf allows errors to be downgraded to allow games & programs to run. The only difference with GLThread is it's a performance boost rather than broken functionality workaround - and yes I know those work arounds are often disputed too
Mblackwell 10 February 2017 at 3:22 pm UTC
Nvidia's current driver doesn't have a whitelist for multithreading, instead it enables it on everything and performs some heuristics and disables it on the fly if performance is being affected.
Creak 10 February 2017 at 3:26 pm UTC
View PC info
  • Supporter
  • Top Supporter
MblackwellNvidia's current driver doesn't have a whitelist for multithreading, instead it enables it on everything and performs some heuristics and disables it on the fly if performance is being affected.
I'm not sure it's "on the fly", I think it's more integrated profiles for specific games, as better explained here: https://www.quora.com/How-does-Nvidia-optimize-specific-games-via-driver-updates?share=1
STiAT 10 February 2017 at 3:27 pm UTC
@Creak
You do not see a lot of performance improvement by current vulkan implementations because the engines are FAR from finished porting to Vulkan.

Just quoting the article about Croteam before:
QuoteIHVs engineers know very well that I've been crying for years (since multi-core CPUs started to become standard) to allow us to record GPU command buffers on separate thread. But that didn't happen in DX10, nor DX11, nor any of OpenGL iterations. So our engine was adapted to work with what we had. Now that DX12 and Vulkan came, it will take quite some rewrite to get it all turned upside down. Until that's done, Vulkan will be at disadvantage. But the very fact that it is close to DX11 in speed while it's working practically in emulation shows how much potential there is. This discrepancy is what you see in Doom and TTP vs RorTR.

They need to get this done, and it's a lot of work. That's why I always say be careful, we'll probably not see the first real DX12/Vulkan games before next year. They're using the technology, but by far not optimized.
Liam Dawe 10 February 2017 at 3:30 pm UTC
Creak
MblackwellNvidia's current driver doesn't have a whitelist for multithreading, instead it enables it on everything and performs some heuristics and disables it on the fly if performance is being affected.
I'm not sure it's "on the fly", I think it's more integrated profiles for specific games, as better explained here: https://www.quora.com/How-does-Nvidia-optimize-specific-games-via-driver-updates?share=1
That's outdated, it's now enabled by default in the driver and NVIDIA stop if it detects that it's reducing performance...apparently.

See this driver update: https://www.gamingonlinux.com/articles/nvidia-37809-beta-driver-released-adds-opengl-threaded-optimizations-by-default-and-more.8940
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just 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!
Livestreams & Videos
Community Livestreams
  • Friday Livestream with Samsai
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts