Mesa OpenGL Threading Now Ready For Community Testing, Can Bring Big Wins

[theriddick]

I tried to get glthreading working with warthunder and my furyx but it resulted in crashing on startup. Seems other people with different hardware got it working, could just be some Oibaf driver issue at the time.

[SaucyJack]

Even if I were to give you the benefit of the doubt that you actually are enough of an elitist where 90FPS is your bare minimum (I know of people with G-sync displays who are perfectly satisfied with 75FPS), where did I say anything about a specific framerate being playable? More importantly, how does your comment have anything to do with the snippet you quoted? Are you not aware that most AMD hardware on Linux does not regularly reach 90FPS on modern AAA titles?

If anything here is a joke, it's your level of comprehension. I'm trying to focus on improving everyone's experience in the most efficient way possible, so go troll somewhere else.

The only person here with a comprehension issue is you. You are apparently ok with shafting the performance of most games for the benefit of a few. And it's ok as long as it's "playable". Talk about fps communism.

[schmidtbag]

The wide range of hardware, games, settings, and how people define playable means that almost any loss at all is probably going to take some game from playable to non-playable for someone. The only question is at what resolution and for what card.

Right - I get that. That's besides my point. My point is maybe nobody has to deal with a regression if this is strictly a CPU resources problem.

Also, if a game speeds up with increasing core counts, that doesn't mean this wouldn't help it. It's all about allowing the game to continue doing work rather than stalling out while transferring assets into memory or blocking on some other operation. That can help even if you only have a single-core cpu.

This speculation is currently meaningless if the regressions haven't been tested on a more capable CPU, or, perhaps a less capable GPU. The only proof I'm aware of is from 4-threaded CPUs.

It's simple math... if you have a game that utilizes 4 threads on a quad core CPU and it performs WORSE when you add more threads to mesa, is it really that unreasonable to suspect that maybe the CPU is the problem and not necessarily GL threading?

The only person here with a comprehension issue is you. You are apparently ok with shafting the performance of most games for the benefit of a few. And it's ok as long as it's "playable". Talk about fps communism.

Uh... I was referring to 150FPS, where you're not going to see a difference unless you start flailing the mouse erratically. So it's hardly "shafting performance". As for "communism", you do realize we're talking about a community-oriented driver on a community-oriented OS, right? Are you not aware that the vast majority of gamers do not have hardware capable of playing the latest AAA titles above 60FPS (that includes a compatible display)? Are you so self-centered that you are ignoring people who prefer 4K displays, of which are lucky to see 90FPS? Stop making this about you, because you're the minority and it is up to hardware devs to please the greatest amount of people. Most people would rather have a higher resolution than a higher framerate.

BTW, you might want to read up on Amdahl's Law - the more threads you add, the lower your potential maximum performance will be. In other words, as hardware continues to improve, GL threading has the potential to lower peak performance. In what may today run better because of it could regress on new hardware a couple years from now. This is why testing the regressions on various CPUs is important. Thats the only point I'm trying to make, and all you want to do is moan about "me me me".

[PadreAdamo]

Does this affect wine titles at all?

[smitty3268]

It's simple math... if you have a game that utilizes 4 threads on a quad core CPU and it performs WORSE when you add more threads to mesa, is it really that unreasonable to suspect that maybe the CPU is the problem and not necessarily GL threading?

I'm not clear what you're even asking. You're saying that making synchronous api calls asynchronous could slow things down just because your cpu is too slow? No, it's because of the resource contention and the synchronization that has to happen, depending on the pattern of API calls that the game makes.

Or you're saying that making the calls async won't help because your cpu is too slow? Again no - it allows bypassing all kinds of stalls no matter how slow your cpu is, as long as the game is making API calls that allow it to do so.

It all depends on what calls the game is making and in what order. Some workloads will be helped, some won't.

If you're just saying that results may depend on your hardware, then we can agree on that much. But honestly a lot of it is going to be based on the game and the pattern of API calls it makes - I'd say the hardware is more likely just going to emphasize or de-emphasize the gains or losses you experience, rather than changing them entirely. The main thing is that if you have a workload that the GPU is struggling on, it may not be waiting for the CPU much and therefore these gains (and losses) would disappear, so the more powerful your gpu and the less powerful your cpu the more likely you will see large changes in performance.

[SaucyJack]

Right - I get that. That's besides my point. My point is maybe nobody has to deal with a regression if this is strictly a CPU resources problem.


This speculation is currently meaningless if the regressions haven't been tested on a more capable CPU, or, perhaps a less capable GPU. The only proof I'm aware of is from 4-threaded CPUs.

It's simple math... if you have a game that utilizes 4 threads on a quad core CPU and it performs WORSE when you add more threads to mesa, is it really that unreasonable to suspect that maybe the CPU is the problem and not necessarily GL threading?



Uh... I was referring to 150FPS, where you're not going to see a difference unless you start flailing the mouse erratically. So it's hardly "shafting performance". As for "communism", you do realize we're talking about a community-oriented driver on a community-oriented OS, right? Are you not aware that the vast majority of gamers do not have hardware capable of playing the latest AAA titles above 60FPS (that includes a compatible display)? Are you so self-centered that you are ignoring people who prefer 4K displays, of which are lucky to see 90FPS? Stop making this about you, because you're the minority and it is up to hardware devs to please the greatest amount of people. Most people would rather have a higher resolution than a higher framerate.

BTW, you might want to read up on Amdahl's Law - the more threads you add, the lower your potential maximum performance will be. In other words, as hardware continues to improve, GL threading has the potential to lower peak performance. In what may today run better because of it could regress on new hardware a couple years from now. This is why testing the regressions on various CPUs is important. Thats the only point I'm trying to make, and all you want to do is moan about "me me me".

Try harder guy, you're not spinning enough.

[dungeon]

Does this affect wine titles at all?

Should potentionally affect whenever GL is used.

But i think Marek is interested at native GL apps exclusively at this time

[czz0]

Is the correct way to enable this globally by setting mesa_glthread=true in your ~/.bashrc? If so, how do I verify that it's actually enabled?

[schmidtbag]

I'm not clear what you're even asking. You're saying that making synchronous api calls asynchronous could slow things down just because your cpu is too slow? No, it's because of the resource contention and the synchronization that has to happen, depending on the pattern of API calls that the game makes.

No, I'm saying adding more threads on an already fully taxed CPU might slow things down. Synchronicity is not what I'm focusing on.

It all depends on what calls the game is making and in what order. Some workloads will be helped, some won't.

Right, I get that. But I'm not referring to those scenarios. Again - I'm referring to a very specific, but not uncommon scenario.

I'd say the hardware is more likely just going to emphasize or de-emphasize the gains or losses you experience, rather than changing them entirely. The main thing is that if you have a workload that the GPU is struggling on, it may not be waiting for the CPU much and therefore these gains (and losses) would disappear, so the more powerful your gpu and the less powerful your cpu the more likely you will see large changes in performance.

Understood, but think of it in this perspective:
We are told there are regressions for some games. What we don't know and what I'd like to have proven is if these regressions are because of the games themselves or because of the hardware combination. What this means is the regressions might not be universal. It seems to me Marek is blaming the regressions on the game, rather than the CPU, but, he claims to have only tested on one CPU. That means non-whitelisted titles could be missing out on more performance (hear that SaucyJack? Something that benefits you...). This also means some people could be reporting false information, where some hardware combinations could result in regressions on a whitelisted title.

So, I propose that GL threading be enabled or disabled based on both the title and hardware. For unlisted titles, it would default to a certain behavior (for example, anything less than 6 logical processors keeps GL threading disabled). To clarify, this is only if we prove using a more powerful CPU actually has an impact on regressions. It might not. I am not insisting I am right about this, I just feel there's a strong possibility.

[dungeon]

PS: These are games that I would whitelist, but I don't have them nor do I have their executable names: - Civilization 5 (need to test first, then need the executable name) - Borderlands: Pre-Sequel (need to test first, then need the executable name) - American Truck Simulator (tested with great results, only need the executable name) - Euro Truck Simulator 2 (tested with great results, only need the executable name)

Civilization 5 is Civ5XP
Borderlands: Pre-Sequel is BorderlandsPreSequel
Euro Truck Simulator 2 is eurotrucks2
American Truck Simulator is amtrucks
etc...

You have names on https://steamdb.info/ somewhat complicated to search but OK better user to test together with posting name