Mesa developer Marek is looking to finally sort out threaded GL dispatch

Quoting: GuestIsn't it a bit weird they are favouring compatibility with an emulator (which hasn't made much strides in supporting multi thread) instead of actual games? I mean i use that said emulator but still i think the priority should be on the finished product (the games) while ongoing development emulators could then adapt to the new circumstances.

They aren't favouring anything, it was a single reference pointed out that it needs improvement. Lower performance in anything is a regression and regressions aren't good. If something has a regression with it, you can be almost guaranteed something else has been affected too.

Gregory is the one of the authors of pcsx2. So actually, he isnt really a mesa dev.
But he stated somewhere in the pcsx2 forums, that the plugin GSDX would receive a major performance boost if MESA gets threaded support. I guess he just shared his experience based on test he made earlier.

Quoting: GuestIsn't it a bit weird they are favouring compatibility with an emulator (which hasn't made much strides in supporting multi thread) instead of actual games? I mean i use that said emulator but still i think the priority should be on the finished product (the games) while ongoing development emulators could then adapt to the new circumstances.

Nvidia had their threaded optimizations disabled by default for a good while too before they were confident enough in shipping that as a default feature (which I think they did some time ago, but I might be wrong). It makes sense that this would be disabled until people can properly optimize it and evaluate its effects in various scenarios. I also read that it can be enabled with an environmental variable, just like Nvidia's thing, so people who want to try and squeeze some performance out of games can do so without it needing to be enabled always.

I love MESA, it's nice to feel that it is just getting better and better.

Quoting: SamsaiNvidia had their threaded optimizations disabled by default for a good while too before they were confident enough in shipping that as a default feature (which I think they did some time ago, but I might be wrong). It makes sense that this would be disabled until people can properly optimize it and evaluate its effects in various scenarios. I also read that it can be enabled with an environmental variable, just like Nvidia's thing, so people who want to try and squeeze some performance out of games can do so without it needing to be enabled always.

nvidia enabled it quite recently with 378.09 and from my testing it doesnt seem to work well. It said to be enabled automatically if it gains performance and it disables itself when theres no perf gain but i cant see that happening.

running ARK without it yields 25-40 fps and that nvidia "automatic glthreaded" doesnt seem to turn on. when i foce it with __GL_THREADED_OPTIMIZATIONS=1 i get 40-80fps in ARK

Well, that will help. Or will not help (a lot). As somebody of Feral in example replied there - they do gl treading in their, how may i call it ... "porting layer"? I'd guess most games and engines which have bigger performance requirements already did some kind of their own threaded gl.

Good! And it indeed should be disabled by default. Extra threading can hurt rather than improve performance in some scenarios.

QuoteI talked a bit with Marek. The implementation is far from optimal. There is potential but it isn't for today.

thread off => 67 fps
thead on => 51 fps
thread on + hack to remove a bad sync => 86 fps

Link

Hello,

QuoteGregory Hainaut, a developer of PCSX2 replied saying that it causes performance issues with PCSX2 claiming it's not yet optimal, but it has potential.

Yes it is me ;) I didn't post any benchmark as I think it isn't relevant yet. But as you can see on the previous post (did a single testcase), we can transform a -25% to a +25%. It just needs some small fixes. Someone is working to improve the code. So hopefully it will get better in the coming weeks.

QuoteIsn't it a bit weird they are favouring compatibility with an emulator (which hasn't made much strides in supporting multi thread) instead of actual games?

PCSX2 already requires a 3-4 core CPU (1 thread for EE, 1 thread for GS, 1 thread for VU, 1 thread for driver). Not all problems can be multi-threaded efficiently. The market is 2/4 cores so let's be honest, we aren't too bad on the multi-thread optimizations.

QuoteI mean i use that said emulator but still i think the priority should be on the finished product (the games) while ongoing development emulators could then adapt to the new circumstances.

Your reasoning is wrong. PCSX2 is an open source product. It will be finished when the project is dead. Would you accept a game vendor saying that they don't support Mesa because it isn't finished. Likely no. You can see that your logic is broken.

So the point wasn't to favouring my project but to share some feedbacks on the current code. For me it is the main point of an open-source driver. I can post patches/comments on potential improvements. This way it improves the experience for PCSX2 but also any program that uses openGL.

QuoteGregory is the one of the authors of pcsx2. So actually, he isnt really a mesa dev.

Author is bit too much IMHO, I'm a big contributor. Yes I'm not a Mesa dev, but I did several patches (You can lookup my name in the git history). My contributions are small but I'm sure it is better than nothing ;)