PCSX2 Linux Development
#91
(05-13-2014, 09:23 AM)gregory Wrote: Hum, there is always surprise Smile 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 Wacko
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Reply

Sponsored links

#92
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
Reply
#93
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...
Reply
#94
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
Reply
#95
krysto, any news/issues? Don't hesitate to ask Smile

Oh by the way feel free to open a pull request for the wiki.

PS2 diagram => google
Reply
#96
Still here, haha. Landed a great job and got accepted into university, so obviously those have to come first Biggrin

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? Smile
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Reply
#97
(06-16-2014, 08:58 AM)gregory Wrote: krysto, any news/issues? Don't hesitate to ask Smile

Oh by the way feel free to open a pull request for the wiki.

PS2 diagram => google
http://arstechnica.com/features/2000/04/ps2vspc/
This is quite cool too
Reply
#98
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! Wacko
"I know now why you cry... but it is something I can never do."
-Emotion Engine
Reply
#99
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
Reply
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.
Reply




Users browsing this thread: 1 Guest(s)