x86_64 bit port, experimental.
#1
Hi,

I began a port of pcsx2 to x86_64.
I mangaed to get interpreter to work with usual plugins(though GSdx only runs in hardware).
For now it works only with avx version of GSdx, though this does not depend on me.
Now, I will try to base myself on what I did and port or redo recompilers so as to get someting really working.
If you want to try it, it only runs at 2-3 fps for now, only on interpreters(recompilers crash, of course),
see here : https://github.com/3kinox/pcsx2/tree/64-bit-clean
For now, I don't know yet if I will port existing recompilers(I will try that first) or just redo a new one, potentially using qemu(that way no need to redo a backend just for pcsx2), though I would have to see how to integrate it nicely into existing code.
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply

Sponsored links

#2
Gregory looked in to possibly using QEMU and I think he decided it was more trouble than it was worth. (Edit: Oh, that was your thread, so you know what I'm talking about)

Nice job, though.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#3
Yep, it's probably quite some trouble, however, I already have some experience in Qemu(and I will need to have more whatever happens), though ya, it's not going to be done in 3 days. For optimization and all, Qemu is doing quite some progress now, so it's not sold yet that it is not as fast as a hand made optimization(if not faster). Plus the other advantages already mentioned(arm, mips and whatever other already existing backend compatibility). However, if I manage to port existing backend and things don't go boom everywhere, I will do that, I am not much of a masochist. In that case, I will try to see what's the state of optimization there and mess around with it to make it generic potentially. It will be useful for me also anyway. However, that too will not be done in 3 days, though potentially faster than rewriting from scratch, managing to have something at reasonable speed(maybe no speedup from the begining though) could potentially not be so long however, depends how everything was done, I only have some very rough ideas know, I just began to look into it, and as usual time is a precious ressource Smile
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#4
You might consider making some pull requests to our main GIT repo. We have been going for 64 bit compatibility anyway, so any changes you made that wouldn't break 32 bit in the process(and aren't QEMU related), you might make a PR for.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#5
OK, I already have a PR for the interpreter ready part, however, it seems that one of the fix could lead to problem with windows actually(#ifdef is our best friend if it is true), if someone could check though, would be nice, I don't have a windows(and don't even know how to build on it or anything). Anyway, it will not break anything 32bit related, only the 64bit windows part, which does not even work yet haha. I begin to look into porting now, I will add an ix86_64 folder anyway, it should not break stuff, I already spotted a few size computation problem for EE, will solve and iterate like that until it works or I see that it is really too broken. I just discovered a nice file full of x86 assembly though, will check that, where it is called an all, is it fully nescessary etc... However it does not seem to go boom yet. It seems to be only the utility functions in SSE so it may work like that or without too much modification, just may not be optimal I guess.
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#6
What is compilation issue or runtime issue? If it was the later, lots of string will break in random place.

By the way, search git history about a 64 bits port (arcum42 remove it form the db). I don't remember the status but it might worth to give it a look.
Reply
#7
The windows problem is the one you told about, wxwidget(2.8 & 3.0 btw). The problem may be formatting, will try to have a deeper look into it. It happens with some formating keys seem. You tried it on windows already?
OK, I will look into that, it may help to guide me into my modifications too. The more references I have, the best it is.
By the way, is there anyway to debug the generated code? What is inside the code dispatcher array? Is it assembly or some kind of generic intermediary representation?(I hope for the latter, don't break my dreams Smile ). Code is generated but it does not behave correctly, seems it refuses to give us back the hand and flies anywhere in memory before getting brutally killed by the kernel Smile. I still use 32 bits operands, of course, I will check calling conventions of x64 also. It might be the problem. I have just have an article to re read again first...
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#8
(11-24-2014, 03:14 PM)LookAtTheWall Wrote: What is inside the code dispatcher array? Is it assembly or some kind of generic intermediary representation?(I hope for the latter, don't break my dreams Smile ).

All of the recompiler code is under pcsx2/x86 and pcsx2/x86/ix86-32. The R5900 recompiler unfortunately doesn't have any sort of intermediate representation. I don't believe the R3000 recompiler does either. You could resurrect R3000Air (which was being worked on by Jake.Stine before he left the project). It has an intermediate representation (at least to some extent) and is beautifully commented. No idea about mVU. I think it has some internal representation stuff, but it has more to do with pipeline emulation, IIRC.

(11-24-2014, 03:14 PM)LookAtTheWall Wrote: Code is generated but it does not behave correctly, seems it refuses to give us back the hand and flies anywhere in memory before getting brutally killed by the kernel Smile. I still use 32 bits operands, of course, I will check calling conventions of x64 also. It might be the problem. I have just have an article to re read again first...

PCSX2 makes heavy usage of different calling conventions, especially __fastcall, which doesn't exist in x86-64. I wouldn't doubt that there are tons of problems with generated code jumping to a function marked as __fastcall. Luckily x86-64 has one calling convention (well two, actually. Windows and Linux have different calling conventions but they aren't terribly different and can maybe be solved with some macro magic).
Main Rig: i5 4670k, 16GB RAM, Nvidia 770 GTX, Windows 8.1/Arch
Main Laptop: Toshiba Kirabook. i5 4200U, 8 GB RAM, windows 8.1/Arch
Reply
#9
R3000Air? ok, could see, their was an equivalent for R5900 too? Comments, I really really really love comments Smile
For the moment i am on the R5900 code though.
I removed the fastcalls actually, it was not(yet) bugging. I suspect x64 compiler just ignores it. Hmm I will see for linux convention first haha, windows is a legacy system anyway Smile Hmm they change the management of stack also? I did not see anything on that but it may be source of one issue in fact.
Laptop: Arch Linux x86_64
CPU :Core i3-3217U @ 1.8Ghz
GPU: intel HD4000
4GO RAM DDR3-1600Mhz
Desktop: Arch Linux x86_64
CPU : Core i7 2600k @ 4.1Ghz
GPU : Nvidia GTX 770 OC Gigabyte
8GO Ram dual channel DDR3-1600 Mhz
Reply
#10
The link for R3000Air is here, under google code. You'll need SVN to check it out. It might also be a good idea to look through svn history over X86-64 related stuff, since there's developer commentary in the comment sections of commits that couldn't be carried to git. Unfortunately Google code doesn't have a good way to search commit history or commit comments. PCSX2 does do some stack alignment magic, but that's all I know about it.
Main Rig: i5 4670k, 16GB RAM, Nvidia 770 GTX, Windows 8.1/Arch
Main Laptop: Toshiba Kirabook. i5 4200U, 8 GB RAM, windows 8.1/Arch
Reply




Users browsing this thread: 1 Guest(s)