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:
However, Eric Anholt was keen to point out they often merge-in code that's not even close to being done:
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:
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.
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.
Some you may have missed, popular articles from the last month:
If SteamOS does adopt a whitelist for this, it really could become a "best distro for gaming" out of the box.
2 Likes, Who?
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..
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..
1 Likes, Who?
Quoting: CreakOh "whitelist"... I don't like where this is going...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.
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..
0 Likes
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 on 10 February 2017 at 2:51 pm UTC
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 on 10 February 2017 at 2:51 pm UTC
1 Likes, Who?
Quoting: 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
0 Likes
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
0 Likes
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.
0 Likes
Quoting: 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
0 Likes
@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:
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.
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.
1 Likes, Who?
Quoting: CreakThat's outdated, it's now enabled by default in the driver and NVIDIA stop if it detects that it's reducing performance...apparently.Quoting: 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
See this driver update: https://www.gamingonlinux.com/articles/nvidia-37809-beta-driver-released-adds-opengl-threaded-optimizations-by-default-and-more.8940
0 Likes
See more from me