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

[marek]

I created the wiki here:

https://www.gamingonlinux.com/wiki/Performance_impact_of_Mesa_glthread

Hopefully people will contribute. Too bad this thread has been spammed with little-to-no-value comments.

Thanks. Here is additional information about testing:
- Setting the environment variable "mesa_glthread=true" will enable glthread. It has the same effect as enabling glthread in drirc.
- You can measure FPS manually by setting GALLIUM_HUD=fps, going to an (ideally static) game location and observing the FPS on the screen.
- You can observe how glthread is performing by adding 3 more HUD charts: GALLIUM_HUD=fps,API-thread-offloaded-slots+API-thread-direct-slots+API-thread-num-syncs
- The API charts on the HUD show glthread counters. If they are 0, glthread is disabled. Even if you enable glthread, Mesa can still decide to disable it for compatibility. In order to have a good chance of having higher performance, API-thread-offloaded-slots must be 2x or higher than API-thread-direct-slots.
- It's recommended to have a slower CPU compared to the GPU.

Would you add this to the Wiki page. Thanks.

[shmerl]

So if it did not hurt performance for anybody, I strongly recommend putting The Whitcher 2 on that list.

I'll run some more tests. Possibly my fps was capped there and I was always getting 60fps. Did you specifically uncap it somewhere in the game settings?

[shmerl]

This is confusing as hell, if I understand it right, it colides with wine D3D-CSMT implementation that is already included in wine-staging, but what about gallium nine internal multithreading (csmt_force=1, it should be enabled by default since Mesa 13.2 or 17.0), if I understand it right, in case of gallium nine, this option have no influence and does not colide?

Not sure. I don't find Gallium Nine too useful for me. More modern games use DX11 already, and those which use DX9 work pretty well with regular Wine and its CSMT.

[duby229]

I'm not sure I understand the question.
OpenGL's problem is that even with rules in place, devs like to implement their own paths. Vulkan does away with rules and says "here's a lower level API, do whatever you want". I'm having a hard time seeing how that's not going to lead to games optimized half-way or even for one of the major players. Professional software (which is where Vulkan can do the most good) will probably be treated better, but games? I think they'll just get the short stick.

Fwiw, I don't have a problem with Vulkan. Between OpebGL and Vulkan, I think now is a great time for open rendering frameworks. It's just that I don't agree with those that see Vulkan taking the world by storm and changing how we do rendering from the ground up.

well, that's unfortunate imo.

[M@GOid]

The Witcher 2 doesn't benefit much from it really. I tested it and didn't notice any significant difference.

The Witcher 3 in Wine on the other hand seems to benefit from it somewhat.

At last in my setup (i7 3770k/RX470) it have a very good gain. For the sake of simplifying things and reproducibility, I did a easy test. Going to the Arena match, after you talk with the armless guy, do a slow 360 with a joypad. After a few ones, I observed ~ 51-97 FPS without gl_thread and ~73-108 with it. In other parts of the game, were before I observed well south of 60 FPS, now it stays close of it.

So if it did not hurt performance for anybody, I strongly recommend putting The Whitcher 2 on that list.

[bug77]

But, isn't that exactly what made OpenGL hard to implement and hard to support? What would make you think taking Vulkan down that path would be a good thing?

I'm not sure I understand the question.
OpenGL's problem is that even with rules in place, devs like to implement their own paths. Vulkan does away with rules and says "here's a lower level API, do whatever you want". I'm having a hard time seeing how that's not going to lead to games optimized half-way or even for one of the major players. Professional software (which is where Vulkan can do the most good) will probably be treated better, but games? I think they'll just get the short stick.

Fwiw, I don't have a problem with Vulkan. Between OpebGL and Vulkan, I think now is a great time for open rendering frameworks. It's just that I don't agree with those that see Vulkan taking the world by storm and changing how we do rendering from the ground up.

[moilami]

Oh man, now I should switch from Debian to something else so I can test and report.

[torsionbar28]

AMD has been trying to catch up to Nvidia for a while, yet that doesn't stop AMD from making sales. People are slowly transitioning to AMD on Linux due to the overall better user experience and complacency with Linux. People were doing this despite the Mesa drivers performing overall worse than the Windows drivers. Only very recently have the drivers begun to be on-par with Windows, with some exceptions that seem to have a correlation with detail level. I'm sure many people are willing to sacrifice 5-10FPS on a game that already exceeds 150FPS if it means games that struggle to reach 60FPS can go faster. But again, I don't know how severe the regressions are or what the cause is.

^ Truth. I was an Nvidia Linux user from ~2004 to 2017. A few months ago I replaced my GTX Titan with an Rx 480, and couldn't be happier. Currency mining Inventory shortages aside, 2017 is the year all Linux desktop folks should consider dropping Nvidia and switching to AMD. The drivers and performance have matured to such a state that it's an easy transition. Everything "just works" on this Rx 480 with Fedora 25, and performance is great in all the major game titles in my Steam library. Can't wait for Vega cards to land soon!

[duby229]

If your gripe is OpenGL put enough flexibility in developers' hands as to create inconsistencies, how does Vulkan, which put even more flexibility in the same hands, fixes the problem?

But, isn't that exactly what made OpenGL hard to implement and hard to support? What would make you think taking Vulkan down that path would be a good thing?

[bug77]

What this tells me is OpenGL is crap, but we knew that. The inconsistency that it has allowed developers/engines to create such hacks and a mess is why Vulkan must take over and soon, I just hope Vulkan forces developers/engine developers into conformance.

If your gripe is OpenGL put enough flexibility in developers' hands as to create inconsistencies, how does Vulkan, which put even more flexibility in the same hands, fixes the problem?