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

[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!

[moilami]

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

[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.

[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.

[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.

[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.

[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?

[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.

[marek]

Quick question. This OpenGL Threadingb working on R600? I mean HD5850 or HD5650m? Should I try test it? marek

Yes. It's supported by all Mesa drivers. RadeonSI, R600, Nouveau, Intel, ...

[leipero]

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.

Most work quite well, but try to load some 20000+ blocks stadium map on TMNF (free) or TMUF, even on 24h competition maps limitations of Wine-D3D translation are quite obvious, in most cases gallium nine gives over twice the performance, especially with slower CPU, with superior input latency (even compared to Windows) that is important in such cases, you can try it yourself if you are on AMD GPU, on nvidia GPU, I've tested only on (very) low end GPU (with nouveau), and gallium-nine did hurt performance, but it was bad in both cases (with severe stutters on high cc maps). In such scenarios, that overhead of wine implementation goes to the unbarable levels, and gallium nine is great solution, I don't know for fast CPU's tho, you can try it.