PCSX2 Linux Development

[gregory]

Code:

9:51 gregory package/pcsx2.snapshot-5883/plugins/GSdx % which gr

gr: aliased to egrep -iIrs --color=auto --exclude="tags"

Code:

9:51 gregory package/pcsx2.snapshot-5883/plugins/GSdx % gr GSCritSec .

./GSRenderer.h: GSCritSec m_pGSsetTitle_Crit;
./GSCapture.h:class GSCapture : protected GSCritSec
./GSThread.h:class GSCritSec : public IGSLock
./GSThread.h: GSCritSec() {InitializeCriticalSection(&m_cs);}
./GSThread.h: ~GSCritSec() {DeleteCriticalSection(&m_cs);}
./GSThread.h:class GSCritSec : public IGSLock
./GSThread.h: GSCritSec(bool recursive = true)
./GSThread.h: ~GSCritSec()
./GSThread.h:class GSCondVarLock : public GSCritSec
./GSThread.h: GSCondVarLock() : GSCritSec(false)
./GSThread.h: m_lock = new GSCritSec();

[gregory]

Any news?

[krysto]

Still here, trying to understand how everything works. What I still don't understand is where the threads are launched. The GSThread.cpp file contains all the definitions for the thread classes, right? But where does everything actually get launched from? What is the general flow of the program?

I have a solid knowledge of c++, but diving into a huge undocumented codebase is difficult
Are there any resources on the subject you could recommend?

[gregory]

Here the end of the flow. It is a bit tricky, but Gabest code is magical Don't try to understand everythings.

Create a new object that inherit of GSThread

Code:

./GSThread.h:template<class T> class GSJobQueue : private GSThread

Then it create a GSWorker based on a shared_ptr of previous object.

Code:

class GSRasterizerList : public IRasterizer
{
protected:
    class GSWorker : public GSJobQueue<shared_ptr<GSRasterizerData> >
    {
        GSRasterizer* m_r;

    public:
        GSWorker(GSRasterizer* r);
        virtual ~GSWorker();

        int GetPixels(bool reset);

        // GSJobQueue

        void Process(shared_ptr<GSRasterizerData>& item);
    };

    GSPerfMon* m_perfmon;
    vector<GSWorker*> m_workers;
    uint8* m_scanline;

    GSRasterizerList(int threads, GSPerfMon* perfmon);
....

So you just to push GSRasterizerList::GSWorker into a list of task. I let's you continue (grep is your best friend )

Easy (and brilliant) isn't it


On what topic exactly do you want ressources?

[krysto]

I meant any general tips/books etc on tracing undocumented code. But I guess you already sort of answered my question just grep your way around the maze until you finally start to see the big picture!

[gregory]

Well I'm very efficient with grep, not sure it suit well everybody. Besides I got massive training at work. People develop piles and piles of script, and I often need to ack in the middle. Besides I often change of clients so

Just concentrate with one feature at the time. Otherwise use the debugger to see the flow (use watchpoint and breakpoint)

[krysto]

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

Though I have this weird glitch when debugging pcsx2 that I can no longer hold down a key on my keyboard to keep typing a letter. Have you ever encountered this before?

[gregory]

Well with GDB I got everything (even computer hardlock). The only trick is this one to disable segmentation fault (only if you use full PCSX2).

Code:

handle SIGSEGV noprint

[mac1202]

Valve Publishes The Source Code For Their VOGL OpenGL Debugger -> Could this help to improve the performance of the linux version of pcsx2 ?

[gregory]

Yes and no. Yes because it would allow to use to get some trick. No because I need to code it, and I seriouly need a debugger. Yes they also release one but it is limited to gl3.3. Anyway the real limitation of GSdx ogl is my free time (or additional people to work it, everybody want an Android port but nobody to help on opengl...) I know a couple of trick that could improve performance (GL_buffer_storage, GL_shader_subroutine, fix threading issue for example).