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. Article taken from GamingOnLinux.com.
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: STiATThey 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.I completely agree. I was referring to Vulkan because of the same feeling that "Vulkan will save us all" but for threaded GL.
To be perfectly clear, I never said threaded GL is a bad idea. It's a very good idea in fact. But it won't have the effect on performances that most of the forum users here seem to hope.
A game engine that only use 1 cpu has a lot more problems than Vulkan or threaded GL!
Last edited by Creak on 10 February 2017 at 3:32 pm UTC
0 Likes
Quoting: liamdaweThat's outdated, it's now enabled by default in the driver and NVIDIA stop if it detects that it's reducing performance...apparently.Be careful here, they're just talking about the threaded GL optimization. My link is about all the other tweaks that are done in the NVIDIA drivers and are game specific.
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
Quoting: CreakAh you're right, wires crossed :)Quoting: liamdaweThat's outdated, it's now enabled by default in the driver and NVIDIA stop if it detects that it's reducing performance...apparently.Be careful here, they're just talking about the threaded GL optimization. My link is about all the other tweaks that are done in the NVIDIA drivers and are game specific.
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
I know that I won't change the mind of all the users in this forum, but if I can convince you @liamdawe that GL threaded is good, but not "that good", and that the game engines can be multi-threaded even without the GL threaded feature. Then maybe you would post new articles that won't get the hopes too high for your users.
As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"
On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.
As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"
On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.
4 Likes, Who?
Mblackwell Feb 10, 2017
I was talking about whitelists as it pertains to multithreading GL, which is what the discussion in Mesa is. Nvidia doesn't bother with a list, they just do it on the fly.
That doesn't mean they don't "fast path" certain calls for specific games.
Last edited by Mblackwell on 10 February 2017 at 4:30 pm UTC
That doesn't mean they don't "fast path" certain calls for specific games.
Last edited by Mblackwell on 10 February 2017 at 4:30 pm UTC
0 Likes
I perfectly understand why they don't want to merge bad/broken code. And not, that is not the same as 'unfinished code'. In case of unfinished code (like Vulkan when it was merged) most things that don't work are well understood (known to be unfinished) in this case we have an 'optimization' patch set, which fixes things in some cases, but causes crashes and other random behaviour in other.
The authors, instead of insisting on merging that as is right now, should make sure the code, when enabled, at least passes the Mesa standard test suite. Some tests may be skipped or ignored when they are known to be broken by some missing functionality, but ignoring failing tests 'because someone can fix that later' or 'it is ok, this is not a problem for the games it work with' is a very bad idea.
Unexplained test failure means some undefined behaviour with some unknown trigger. It may start affect games that work now when something changes anywhere in the build or runtime environment. Imagine: steam upgrade and game starts to crash, just because it was on the 'whitelist' and used the bad code, which just happened to work earlier. Steam developers, Mesa developers and game developers (provided they still care) won't be very happy with the bug reports coming.
The authors, instead of insisting on merging that as is right now, should make sure the code, when enabled, at least passes the Mesa standard test suite. Some tests may be skipped or ignored when they are known to be broken by some missing functionality, but ignoring failing tests 'because someone can fix that later' or 'it is ok, this is not a problem for the games it work with' is a very bad idea.
Unexplained test failure means some undefined behaviour with some unknown trigger. It may start affect games that work now when something changes anywhere in the build or runtime environment. Imagine: steam upgrade and game starts to crash, just because it was on the 'whitelist' and used the bad code, which just happened to work earlier. Steam developers, Mesa developers and game developers (provided they still care) won't be very happy with the bug reports coming.
1 Likes, Who?
Quoting: CreakI know that I won't change the mind of all the users in this forum, but if I can convince you @liamdawe that GL threaded is good, but not "that good", and that the game engines can be multi-threaded even without the GL threaded feature. Then maybe you would post new articles that won't get the hopes too high for your users.I'm well aware of the upsides and downsides to it all, as you say I have contacts in many studios and they all complain about OpenGL, especially the multi-threading. An engine being multi-threaded is different to OpenGL, that's obvious I don't think I ever said the are one and the same, so not really sure what you're getting at there.
As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"
On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.
0 Likes
Quoting: CreakI know that I won't change the mind of all the users in this forum, but if I can convince you @liamdawe that GL threaded is good, but not "that good", and that the game engines can be multi-threaded even without the GL threaded feature. Then maybe you would post new articles that won't get the hopes too high for your users.
As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"
On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.
Completely agree :)
The IT world in general is far too much about marketing BS, and the gaming world is sometimes part of that. The fact the Mantle/Vulkan/D3D12 exist is testament to the fact that there are issues to be resolved, but there are generally no silver bullets in coding. Threading APIs may be a convenience for developers, but the underlying implementation then has to do GENERIC work to deal with the threading in place of the developer doing SPECIFIC work for their threading needs; it will not always be a good idea.
0 Likes
Patreon
PayPal
See more from me