PCSX2 development plan,thoughts,contributions
#41
I've split the thread and moved it to developer discussion. I put in some general title (dunno if you all people agree with it, tried summing it up as best I could).

I'll also probably delete some off-topic posts like the above chatter of refraction and SmakAndBaxter for cleanness sake.
[Image: newsig.jpg]
Reply

Sponsored links

#42
A lot already came out of it. The dev channel on IRC is filled with people and there's lively chatter on what to do Smile
Reply
#43
It's not much different than real life, where the harshest conflicts often give birth to remarkable change.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#44
(07-07-2014, 03:30 PM)Blyss Sarania Wrote: It's not much different than real life, where the harshest conflicts often give birth to remarkable change.

In this case I hope it leads to bug fixes, and accuracy improvements.

I don't expect this to be like the days where two certain devs were working like hell. Sadly a certain Company has taken them both out of the equation.

Oh well, I'll redownload visual studio 2013 later today. That way I can maybe try to make some small changes. I'm awful at C++, but I want a challenge.
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply
#45
If you don't mind working in Linux then Gregory already has a list of tasks that are accomplishable even if you aren't a C++ whiz. Here is the link, and the tasks I'm referring to specifically are cleaning the GCC flags and cleaning GCC warnings.

I've been working on getting PCSX2 to compile and run with Clang for the past week or so and have managed to succeed, but only on development builds without any optimizations on. PCSX2 is very sensitive to compile time optimization flags, which is why it's not using generic -O0, -O1, and -O2 (no optimization, some optimization, and full optimization, respectively) flags, and instead maintains a list of about 30 individual optimization flags that are turned on for release builds (and off for development builds). This is very not good, especially for the clang port I've been working on. The GCC individual optimization flags aren't recognized by clang so I can't use them as a starting point. Moreover, any bump in optimization (from -O0 to -O1 in my case) causes clang built PCSX2 to crash (and probably GCC built PCSX2 to crash as well, but I haven't had the chance to test this).

So what needs to be done is the following:
  1. Determine what individual optimization flags break PCSX2
  2. Determine exactly where in the compiled code the offending flags actually break pcsx2
  3. send both compiled executables to a developer, and (if you know how) a diff of the disassembly at the point that PCSX2 breaks
  4. Have the developer fix the offending code.
  5. Test the fix and make sure it doesn't break anything else
  6. Celebrate and have a beer because this is an important fix

Unfortunately, this only works if an individual optimization breaks PCSX2. If, for example, -SpecificOptimization1 and -SpecificOptimization2 don't break PCSX2 when enabled individually, but do break PCSX2 when both are enabled together, then there's not a whole lot to be done, mostly because determining that this is the case is impossible (Clang sets 39 flags for -O1 optimization. That means there are 39! (39 factorial) combinations of flags that could potentially break PCSX2. Assuming a 5 minute build/deploy/test cycle, you would experience the heat death of the universe before you enumerated every bad combination of optimization flags).

In order to fix that, the only thing that can be done is code cleanup.

Anyway, if anyone wants to do something, that's a great starting point. It shouldn't take more than basic C++, linux, and git skills. I'm happy to help out anyone with the task (especially if you work on my Clang fork and clean up clang flags). My fork is here, by the way. If you want to help out but don't have too much experience then my fork might be an easier place to start. I've updated the old Code::Blocks IDE project files that were removed a few months ago and they work well as far as I can tell, so you won't have to worry about cmake and stuff. Plus developing in an IDE is usually easier for beginners.
Reply
#46
Sadly I know nothing about the Linux side of things
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply
#47
Honestly, there's less of a learning curve between learning a bit about linux (you can even just install it in a virtual machine, that's fine) and working on the task I outlined (and that goes for a fair amount of the linux tasks gregory outlined) than working on some generic issues (like code cleanup, refactoring, serious edits to the entire codebase, etc).
Reply
#48
PCSX2 (include utilil/x86emitter) might need those flags:
-fno-omit-frame-pointer
-fno-strict-aliasing

GSdx:
-fno-strict-aliasing
-mpreferred-stack-boundary=2
-fno-operator-names

My advice is to first try a single clang built plugin with others part built by gcc. (see it can be useful to have plugin Tongue2 ). Do it for each pluging and then the core.
Reply
#49
Can you specify optimizations for single files? It's possible with Visual Studio.
This should help finding the problem area.
Reply
#50
anybody ever thought about doing a harsh look ahead algorithm for several wait lag or precaching issues. i'm not really into trying but i thought about this when i ran thru the dolphin mess and their shader compiler multithreader days ago. i just remembered that. o_O
Reply




Users browsing this thread: 1 Guest(s)