..:: PCSX2 Forums ::..

Full Version: Q2 2016 progress report
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9
I wouldn't mind testing on linux again but I can never find a distro that suits me. That and the last time I tinkered with the various OS I would get all sorts of issues trying to move up to a recent kernel... but seems like every time I start to play I get fed up with all the compiling, recompiling, and dependency garbage. Then I say ahh screw it and go back to windows Tongue But umm. I've tried ubuntu, zorin, arch, mint... actually most of the common ones, I like ubuntu based linux flavors the best, but the 6 months and then upgrade kills me too... any suggestions on a flavor or am I going back to zorin Tongue
I can test in Linux, if it is possible to build a 64 bit version by now!
You can build a 64 bits version but it will be very slow (only interpreter will work)
I'd like to help out any way I can - programming, testing, whatever.

The most work I've done with the code so far was edit the CMake files to get LTO working (which reminds me, I meant to add that I think that LTO might help with GSdx SW more than HW), so I'll need to take some time to familiarize myself with it, but I can help out other ways as well.

I have a question about the recompiler: If I understand correctly, the recompiler translates the MIPS into x86 - is there any reason that you couldn't save the generated x86 code? If you could do so, it could potentially provide massive speed ups when the limiting factor is the recompiler, not the graphics - is it even possible to create an AOT recompiler? I know  branch logic might make it difficult, but I don't see why it wouldn't be possible.

Sorry for getting off topic.

Let me know if there is any way I can help.

I use an amd64 Debian unstable setup, with the i386 architecture (including g++-multilib) supported as well.
Code:
I have a question about the recompiler: If I understand correctly, the recompiler translates the MIPS into x86 - is there any reason that you couldn't save the generated x86 code? If you could do so, it could potentially provide massive speed ups when the limiting factor is the recompiler, not the graphics - is it even possible to create an AOT recompiler? I know  branch logic might make it difficult, but I don't see why it wouldn't be possible.
Hum save where ? In the disk or the ram ? So far the issue is not really the compilation but rather the execution. For example a basic float operation like "a + b" requires a lots (10+) of X86 instructions. PS2 float are tricky, for example a * b != b * a, or a * 1.0f != a ... EE/IOP integer opcodes are easier to emulate. A x64 port (+ better register alloc) will be enough to provide a speed boost on EE INT.
I think what he's referring to is static recompilation, which can be faster, or at least reduce stuttering slightly (wouldn't make much difference tbh) but is less reliable that dynamic recompilation like we use, plus most of the recompilation we don't know about until the game data has loaded.

If he's referring to dumping it to disc to run as an executable, that will never work, it's not possible. While it might generate valid x86 code, it's no use without the rest of the emulator.
I think what he's referring to is static recompilation, which can be faster, or at least reduce stuttering slightly (wouldn't make much difference tbh) but is less reliable that dynamic recompilation like we use, plus most of the recompilation we don't know about until the game data has loaded.

If he's referring to dumping it to disc to run as an executable, that will never work, it's not possible. While it might generate valid x86 code, it's no use without the rest of the emulator.


I was referring to dumping it to disk, but it's not impossible. "It's no use without the rest of the emulator." If you have the emulator, then it could work, right?

If the biggest problem is float operations, then this wouldn't make a difference?
if you have the emulator, there's no point in doing what you're suggesting. The floating point operations aren't the biggest problem, it's just the sheer amount of work and very little conversion is done during the recompilation, it's extremely literal.
(11-25-2016, 06:38 PM)refraction Wrote: [ -> ]if you have the emulator, there's no point in doing what you're suggesting.  The floating point operations aren't the biggest problem, it's just the sheer amount of work and very little conversion is done during the recompilation, it's extremely literal.

So what can be done to speed up the emulator?
Optimisation of code, fixing bugs, faster computers.

for now the easiest and quickest option for everybody is that you get a faster computer
Pages: 1 2 3 4 5 6 7 8 9