Posts: 80
Threads: 2
Joined: Feb 2014
Reputation:
2
Location: New York, NY
05-13-2014, 03:42 PM
(This post was last modified: 05-13-2014, 04:26 PM by krysto.)
(05-13-2014, 09:23 AM)gregory Wrote: Hum, there is always surprise Let's take it easy and forget event (sema on linux) for the moment. But do we need GSevent actually? A quick grep seems to show that GSevents are only use on GSJobQueue. Condvar will replace them, correct? or did I miss somethings ?
Don't forget that even if we throw out GSEvent and just use std::condition_variable we still need access to the mutex that lies inside IGSLock! This will get really ugly as we need to do something like
Code:
class IGSLock
{
public:
#ifdef ENABLE_STD_THREAD
std::mutex m_mutex;
#endif
virtual void Lock() = 0;
virtual bool TryLock() = 0;
virtual void Unlock() = 0;
virtual ~IGSLock() {}
};
In my opinion we will drive ourselves crazy trying to support all three threading API's on the same branch
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Posts: 80
Threads: 2
Joined: Feb 2014
Reputation:
2
Location: New York, NY
05-13-2014, 09:50 PM
(This post was last modified: 05-13-2014, 09:50 PM by krysto.)
Or else I will need to do a std-specific implementation of the GSWorker like in my original patch.
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
Gsevent was used to emulate the condition variable on windows. So it can be trashed.
IGSLock (and other IGS*) is only a base class that provide same method name (aka interface) for all objects. So GSJobQueue is same for both OS.
You don't need to change it. As far as I understand, GSCondVarLock is used to access the mutex of the condvar. Anyway I'm fine that you replace most of the GSThread.h file (add a new one like GSThreadC11.h). However you need
1/ to keep same external interface.
2/ keep all strange stuff that nobody understand like m_count etc...
Posts: 243
Threads: 57
Joined: Feb 2014
Reputation:
0
i'd prefer using const typehere blah; instead, because it's hard for me to read through this source.
i was going to ask this, but is there a ps2 diagram?
Specifications:
AMD Sempron 3850 @ 1.3GHz
Zotac Geforce GT 640 2GB
4GB RAM
Kubuntu Linux 14.10 STS
Posts: 80
Threads: 2
Joined: Feb 2014
Reputation:
2
Location: New York, NY
Still here, haha. Landed a great job and got accepted into university, so obviously those have to come first
But I will tell you what work I have done thus far and what is going on inside my head...
So inside config.h I have 3 macros
ENABLE_WIN_THREAD
ENABLE_POS_THREAD
ENABLE_STD_THREAD
Basically I have temporarily merged GSThread.cpp into GSThread.h to make it easier for me to read. I have also had to create 2 separate definitions of GSJobQueue because like I said before, I do not believe it is possible to wrap std::condition_variable inside of IGSEvent. So we have a POS/WIN version of GSJobQueue with IGSEvent and then a STD version of GSJobQueue without IGSEvent.
I've uploaded my most recent stuff to my github if you want to see, but my code is getting really messy/buggy trying to support all thread API's and I'm really not proud of myself. I would really prefer to do this porting on a separate branch instead of adding more code to the one branch, after all, we are trying to clean things up, correct?
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Posts: 80
Threads: 2
Joined: Feb 2014
Reputation:
2
Location: New York, NY
I hope I made myself clear enough in my last post!
Basically I was just trying to say that since we are trying to move toward elegance and simplicity then we should fully embrace the git experience and start branches for our new features instead of relying on macros too much. This just makes the code harder and harder to read when new people come on board!
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Posts: 80
Threads: 2
Joined: Feb 2014
Reputation:
2
Location: New York, NY
Also one other thing... the wiki system on github is somewhat limited, you cannot do regular pull requests like you would for code. It is my opinion that it would be better to have the documentation living inside our already existing contributor-friendly wiki instead of on a brand new one and introducing another layer of complexity. I have been doing some work on the main PCSX2 wiki, I have divided the table of contents into three sections:
For Users (Basic information, installation, troubleshooting, etc.)
For Testers (Game compatibility lists, how to report bugs)
For Developers (will contain PS2 Hardware documentation and PCSX2 source code documentation)
Any documentation that I find lying about github, the forums, and the website I will try and consolidate into the wiki!
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
Don't worry about the define it is a temporary solution. It would be easier to test. If you prefer you can create a new file that up to you. Once Win Xp support is dropped and std::thread is old enough, previous code will be dropped.
Yes you're right we get too much wiki. We're currently having discussion internally in order to find the best future wiki system. You contribution is more than welcome.