x64 version of PCSX2?

[Rezard]

I dont know if the Gamecube had more call for 64bit operations, but PS2 ones are generally either 128bit or 32bit, with a few 64bit ones thrown in, but they are less used.

So, does that mean the 128bit operations are done by 32bit? Wouldn't 64bit do that faster? Sorry if this sounds stupid, I don't honestly know how this works.

[Squall Leonhart]

128bit instructions can be executed on modern cpu's using SSE2+

---

There are no guarentees of speed boosts implementing 64bit.

There is only a few places i can think of where 64bit registers would be useful in PCSX2, currently SSE is more than ample for what we need.

I dont know if the Gamecube had more call for 64bit operations, but PS2 ones are generally either 128bit or 32bit, with a few 64bit ones thrown in, but they are less used.

While i don't doubt there would be a performance increase, for the amount of work involved, it wouldnt be worth it.

http://en.wikipedia.org/wiki/Gekko_%28microprocessor%29

[refraction]

hmmm, so gekko has double precision fpu instructions, that could benifit a lot from 64bit, we only use single precision on ours as that's all the ps2 had.

Rezard: As Squall said, SSE opterations do 4x32bit every time per cycle, so 64bit would be to no advantage.

[Rezard]

Ah, I see. Makes sense then, 64bit clearly has no real place in PS2 emulation (in particular). Thanks, guys.

[rama]

X64 memory ops are more expensive (I heard, I'm not pro enough to know the details ).
It also offers double the registers though (both, x86 and SSE). With these we could make
the recompilers cache more and better.
In the end it prolly evens out, with some games performing better than now, some maybe worse.

[Squall Leonhart]

hmmm, so gekko has double precision fpu instructions, that could benifit a lot from 64bit, we only use single precision on ours as that's all the ps2 had.

Rezard: As Squall said, SSE opterations do 4x32bit every time per cycle, so 64bit would be to no advantage.

the CPU to GPU bus is also 64bit on the GC (apparently)

---

cotton says the fpu clamping wouldn't benefit with x64 as well :\
alas tidus's hair will remain splotchy forever.

[Squall Leonhart]

X64 memory ops are more expensive (I heard, I'm not pro enough to know the details ).

http://bmagic.sourceforge.net/bm64opt.html

might be related, but i question why x64 would be much more expensive than x86 when using DMA.
This might of course come back to early x64 processors.

though if you are not aligning the memory boundary properly, there will be a execution hit when the cpu does it itself (in theory, the proposed cases do not apply to current intel cpu's, AMD's are affected however)

x86 and x86-64

While the x86 architecture originally did not require aligned memory access and still works without it, SSE2 instructions on x86 CPUs do require the data to be 128-bit (16-byte) aligned and there can be substantial performance advantages from using aligned data on these architectures. However, there are also instructions for unaligned access such as MOVDQU.

the CRC check dolphin uses on cached textures has a pretty bit performance hit on AMD processors compared to non SSE4 capable Intel processors, as the technique does not align the bytes.

PCSX2 AFAIK aligns the data, to get the most out of SSE2, so there shouldn't be that much of a hit going to x64.
Its just a matter of undertaking the task.... i don't think complicating the source further would be worth it at the end of the day though.

Personally, i would see more of a gain in dumping MSVC and using ICC for release builds (where performance is concerned) since the ICC compiler provides up to 1.25x gains over MSVC (application dependant)

[Shadow Lady]

cotton says the fpu clamping wouldn't benefit with x64 as well :\
alas tidus's hair will remain splotchy forever.

uh... what's wrong with tidus's hair? Looks like in the PS2?

[Squall Leonhart]

Im pretty sure this problem has been addressed,but for some reason I didnt find it in my search on the forum.Anyways whats up with the FFX black pieces of hair on tidus? also the graphical glitch on the back of the ronso(cant remember his name atm) in the opening credits??

I thought I had these problems fixed before but I havent tried to play the game since I reformatted awhile ago.Anyways system specs and settings are as followed if this problem can be fixed Id liked to know it drives me crazy thanx.

[12:12] Squall-Le: so whats with the black patches in tidus's hair when using the VU Recs
[12:13] Squall-Le: more accurately, VU1 Rec
[12:21] JakeWork: clamping differences.
[12:22] pseudonym: ...which are fun to explain but cotton made a good blog post about it so there's no call for that any more
[12:24] JakeWork: hehe
[12:26] Squall-Le: lol, none of the clamping settings change so i figure its outside of the current VU capabilities
[12:26] Squall-Le: change it*
[12:39] JakeWork: there are fundamental differences in how interps do clamping
[12:39] JakeWork: it's impossible for the recs to mimic tem
[12:40] JakeWork: least not without being much slower than they are currently.
[12:41] Squall-Le: well if its even possible to get a little more accurate, its worth adding as an option somewhere. As long as it doesn't cause cotton a stroke that is lol.
[12:50] pseudonym: The last attempt to make them more accurate made them less accurate
[12:51] Dwarg: Which makes it more likely the next attempt will make them more accurate
[12:51] Dwarg: Unless the last attempt was reverted

[refraction]

do you mean back ages ago when the hair had massive bits of hair which were obviously different from the rest of the hair? cos that bug was fixed ages ago! (altho after 0.9.6 i think)

Edit: here we go http://code.google.com/p/pcsx2/source/detail?r=2818