PCSX2 Linux Development

[gregory]

No. You need to edit GSdx/CMakeLists.txt file.

[krysto]

Ugh... it's already November almost and I haven't made too much progress on this. You may want to give this to someone else for now. I don't want to hold things up.

[LookAtTheWall]

I just read through the subject and just one thing strikes me. Correct me if I'm wrong, but std::thread is just hiding pthread no? I mean pthread is just a syscall library, with more or less fancy ways to present threads to you and make it posix compliant, std::thread uses kernel threads too, so it uses exactly the same syscalls, as a matter of fact you can even use pthread_mutex with std::thread(ugly though, not portable at all) so they probably just use pthread under the hood I guess... Anyway, otherwise it would be userspace threads and it could not use multiple cores...

[gregory]

@krysto, feel free to post your current work.

@LookAtTheWall,
std::thread uses whatever it want On linux current implementation is based on pthread. What is the issue? It won't be a revolution but it help to have a portable code as much as possible. My number of arms is rather limited

[LookAtTheWall]

Not an issue in fact. It's quite good actually... Means we know what to expect from it. But then it means that just switching to it will not enhance performances, that was more my point. However, it also means that it should not decrease it. In other words, just matching one to one with the current implantation should work no? Functions are relatively the same it seems to me. Yes, portability is a must. That one is true... I would gladly help, however I am more afraid to break something on windows if I try to implemt for it. .. I have absolutely no knowledge about it, and I don't have one that I can use to try on.

Indeed haha. It would be cool to have more than two. However for me unless I mange to clone myself, more arms would not help .Moving around all the time seems....

[gregory]

Having portable code will help to compare linux/windows performance. But yes I don't expect a speed boost for free. By the way, before fixing performance issue, performance measure need to be fixed.
For example GSdx internal FPS counter is based on the CPU time on the main thread and in *ALL* child threads. It means FPS doesn't depends on the number of thread...

[LookAtTheWall]

I have a base implementation of std::thread, fully functional, but just a few things I am not sure for optimization. However, it does seem to work as good as before, which is coherent, I made a very brutal translation after all. I use recursive mutex to avoid potential deadlocks(it's default behaviour in c/pthread if my memory is OK).
It is on the same repo as previous one, I will make pull request so that you can review easily.(github pseudo is 3kinox, same as yesterday).

To make it faster, I see two solutions:
+ Go for lock free algorithms
+ Configure scheduler if it can be defined as a cause for performance reduction

[Lorena]

Before I am learning funda nexus 5 how to use the GNU debugger, it's absolutely wonderful! So easy to locate funda bumper nexus 6 the entry point and step through everything.

[LookAtTheWall]

I have a "camera ready" version on pull request. Someone already commented on the style and I rectified, I had the occasion to test(and have it tested) a bit, it runs fine on linux(It should not have broken windows but I can not test so...)
It seems to have actually given a slight improvement. When using too many threads on my core i7-2600k, performance just goes down like crazy on the "old" implementation. However, if using std::thread, it still goes down but not as much(no explanation for now as to why though).

[gregory]

How do you measure performance?