New LLE RSP Plugin (accurate, fast but untested?)

[ReyVGM]

The links on the OP are dead, btw.

[the_randomizer]

Yep, OP links are dead, they should probably be fixed ASAP, but that's just me Or possibly a different site like Dropbox where links never expire

[HatCat]

Nah that's alright, OP is a fag anyway.

The links aren't dead, just the entire frekkin' website is under maintenance.
http://filesend.net/

I was actually hoping the main site would be fixed soon, so that then the downloads would also come back up, but those people have a very slow development time budget I see.

Well, I didn't want to use Dropbox because then it's not possible for me to count downloads. I just think it's a neat little stat to see how many people download the plugin, although maybe I shouldn't care. Last I checked on FileSend, it was 1,000 something for the latest RSP 7-zip, but now I cannot check....

Originally Posted by the_randomizer

Yep, OP links are dead, they should probably be fixed ASAP, but that's just me

Yes, it is just you.
Or is it?

Do people actually care that my RSP plugin can no longer be downloaded (just atm :P), or is this all a bunch of hearsay he said; she said? I thought you said if there was anything about my RSP plugin I needed you to test, I should let you know. So if I did not let you know, why is the subject of this plugin only relevant now that the downloads are momentarily inaccessible?

Keep in mind this thread and its downloads have been up for over a year and a half. That's a lot of time to make sure everyone's downloaded my plugin.

[HatCat]

Originally Posted by RPGMaster

I do remember trying assembly through MSVC, since it had some MASM thing built in. I didn't know you could use that to mix with C code though.

I'm sure it just externally calls ML/ML64 for asm in MS Visual Studio and CL.EXE for C code. I wouldn't say it's "built-in" if Visual Studio ships with ML externally; that would be somewhat redundant.

Originally Posted by RPGMaster

Lol you know... I never found a convenient way to do stuff like *(int*)0x404040 = 24 in assembly lol.

...Wait...huh??

Wtf was that lol

I think you modify sp or something, idk. Absolute addressing is the last thing I played around with in asm.

Originally Posted by RPGMaster

I'd prefer doing things like *(__m128*)(var1) = *(__m128*)(var2); though, but it sometimes uses MOVUPS which is annoying because I made sure it's aligned.

Then I would just use the former.

In fact with MMX I think you have to say *(__m64 *)(dst) = *(__m64 *)src, as I'm not sure I ever found an intrinsic for that.

Originally Posted by RPGMaster

How do I do byteswap with intrinsics?

dk;dc

Originally Posted by RPGMaster

Then I could get rid of some inline assembly in pj64 that's messing up the functions they're in.

Byte-swapping is just about the only damn reason anybody should ever have to use inline assembly inside a C project. Things like rotates, byte-swaps, exchanging bytes...things that on the C level always require an extra variable or temporary pre-buffer to avoid losing data.

There are some intrinsics for byte-swapping, but which one you use depends on which compiler you use. MM wrote some shit about it, but I didn't bother remembering because not once have I ever needed a byteswap operation in all of my C programming. Even with N64 emulators on a little-endian PC, I've always found ways to get around the byte endian issues without having to byte swap. Should almost never need to byte-swap something.

unsigned short flip_word(unsigned short ax)
{
    register unsigned short ret_slot;
    const unsigned char ah = (ax >> 8) & 0xFF;
    const unsigned char al = (ax >> 0) & 0xFF;

    ret_slot = (al << 8) | (ah << 0);
    return (ret_slot);
}

... or maybe ...

unsigned short rotate_word(unsigned short ax)
{
    register unsigned short ret_slot;

    ret_slot  = ax << 8;
    ret_slot |= ax >> 8;
    return (ret_slot);
}

You really have to byte-swap something? I say just use one of those.
Unless it's necessary to force an emission of XCHG or w/e in something performance critical you're doing.

Originally Posted by RPGMaster

I want to get rid of FPU stuff in the recompiler for sure, since it converts MIPS floating point to x86 FPU code. I bet I could also speed up the interpreter core using manual SSE instead of auto generated lol.

I don't know much about COP1 (are MIPS floating-point registers 32-bit or 64-bit? or...both...actually, haven't looked at N64 floating-point opcodes since 2009, jesus), but if they're 32-bit floating-point opcodes then I imagine just SSE1 would be sufficient. Project64 is released with builds assuming SSE2 hardware support anyway, which is a pretty decent assumption considering that any 64-bit-capable home PC includes SSE2 support (and tl;dr naive joke here about using a 64-bit PC to emulate the Nintendo 64 ).

Originally Posted by RPGMaster

Lol for the neg instruction in the interpreter I explicitly xor'd the sign bit and or'd the sign bit for ABS.

-(ax) is the same as (ax ^ ~0) - ~0 on 2's compliment, or just ~ax + 1.

Originally Posted by RPGMaster

It would be interesting to see how much faster your graphics plugin would run with a recompiler RSP.

Probably not all that much faster.
Not saying a recompiler version of my RSP would be slower than my interpreter, but the speed difference wouldn't be normal. My interpreter loop is mostly optimized. It is free from *some*, but not all, of the performance constraints of the constant fetch-decode-execute pattern of an interpreter cycle.

It does still branch at least twice for every RSP instruction though, so there's no doubt a recompiler version of my plugin would fundamentally be able to exceed the interpreter in speed.

Originally Posted by RPGMaster

If I never get a full understanding of how recompilers work, I'd rather look at your RSP plugin, since it's more accurate and the interpreter is waaay faster xD. I wonder how fast 2.1's RSP interpreter is though. I should test that.

I think maybe you shouldn't XD?

Might have mentioned something like this before, but Project64 2.1's RSP was not intended for speed. Well the recompiler was, but it doesn't quite outperform the SSSE3 build of my interpreter plugin, which is sometimes even faster than their recompiler in my observation.

Originally Posted by RPGMaster

Also, for 1964 0.85, I'm getting a constant 61.0 VI/s. Is there a way to fix it and set it to 60?

That's weird as shit. I only get 60. Sure you didn't activate the +/- speed limit adjust feature 1964 has or something?

[RPGMaster]

That example I posted "*(int*)0x404040 = 24" was just a way to assign the value of 24, to the address of 0x404040. I'm not sure if the syntax I posted was exactly correct, but using addresses can be useful. I did that for read process memory since I didn't feel like initializing a variable, just to give it the address of a another variable.

Lol for byte swapping, MSVC does a terrible job with compiling the xor swap method, which Zilmar does sometimes use. I'm really confused why he did assembly for a byte swap in a few parts, then C for byte swapping in other parts of his code. If I can't efficiently byte swap in C, then I'll just leave his asm code there lol. One of the major things that need byte swapping, is roms.

LOL I agree with you about the download count. I shouldn't use dropbox anymore .

Now I need to learn more about SSE. For things like convert float to int for his core interpreter, he used inline assembly to do things like
_asm fld var
_asm fistp var
So I'm wondering if theres a faster way to do stuff like that in sse . Man I was looking at the recompiler code and got lost .

For 1964 0.8.5, the only options I see if Counter Factor and Video Speed Sync. When I use jabo's video plugin, I get around 61 VI's . Oh well, if I can't fix it, then hopefully I can implement some of its pro's to another emulator.

[HatCat]

What the hell is fistp? Can't any of these FP mnemonics not be sexual

Originally Posted by RPGMaster

LOL I agree with you about the download count. I shouldn't use dropbox anymore .

Oh I use DropBox all the time really. I just couldn't think of a way to track download counts other than a) attaching them to OP of this thread b) using FileSend.net or something.

Originally Posted by RPGMaster

Now I need to learn more about SSE. For things like convert float to int for his core interpreter, he used inline assembly to do things like <poop>

_mm_cvt something.
Check the xmmintrin.h header file for a list of conversion intrinsics. Some of those will handle converting between XMM float and XMM int or XMM float to scalar register int etc. if that's what you were wondering. The names are all funky though, so I don't remember any of them.

[RPGMaster]

FPU stuff makes no sense. Fistp stores the rounded to integer value of st(0) into a variable and pops the FPU stack. The irony is, it's faster to do fld var, fistp var, rather than using the FRNDINT instruction (which rounds st(0) to the nearest integer). I practiced FPU in assembly, months back .

Rofl I've been avoiding intrinsics just because I hate the ugly names xD. I'll look into it though. I wish I was better at programming . I'm trying to understand both the interpreter core and recompiler core, but it just blows my mind at this point lol. Plus it's harder to read c++ (I'm comparing 2.1 to 1.6).

Do you know anything that 1.6 is > 2.1 at? Now that I realized that 2.1's core is better, idk if I want to continue using 1.6 anymore. Seeing 1964's interpreter's speed has given me hope as well. Although I still couldn't get 60fps with both interpreter and Glide64.

Edit: Lol wth... At first, I was getting around 9-12% of the emulator's cpu usage to r3400i while I'm getting 61 VI/s on pj64 2.1 . Now the cpu is ~9-15% and 60 VI/s. Idk what's going on!

[HatCat]

Sure it's not some weird audio plugin you're using or something? I've never gotten 61.0 VI/s before as far as I recall.

[RPGMaster]

Ya i just found out, that it was the sync audio option in the sound plugin. I still dunno why that would mess up the emulator's cpu core though.

The problem is, when I leave sync audio and fixed audio timing both on, I get ~58-59 fps, so I uncheck those ;/ . When i disable sync audio in the audio plugin settings, I got 61 VI's again, but a more stable cpu usage.

[RPGMaster]

OMG I can't compile anything! I tried 2.1, rsp, etc. Nothin works. So I got bored and decided to compile your rsp plugin with msvc just for kicks. You will laugh at these results.

MSVC
RSP Vector Benchmarks Log

VMULF  :  1.676 s
VMACF  :  2.641 s
VMULU  :  1.590 s
VMACU  :  2.996 s
VMUDL  :  0.620 s
VMADL  :  2.628 s
VMUDM  :  1.011 s
VMADM  :  2.392 s
VMUDN  :  0.964 s
VMADN  :  2.946 s
VMUDH  :  1.871 s
VMADH  :  2.275 s
VADD   :  1.360 s
VSUB   :  1.351 s
VABS   :  1.250 s
VADDC  :  0.829 s
VSUBC  :  1.094 s
VSAW   :  0.157 s
VEQ    :  0.758 s
VNE    :  0.760 s
VLT    :  1.203 s
VGE    :  1.210 s
VCH    :  2.417 s
VCL    :  2.385 s
VCR    :  1.216 s
VMRG   :  0.714 s
VAND   :  0.607 s
VNAND  :  0.618 s
VOR    :  0.610 s
VNOR   :  0.627 s
VXOR   :  0.609 s
VNXOR  :  0.623 s
VRCPL  :  0.594 s
VRSQL  :  0.915 s
VRCPH  :  0.340 s
VRSQH  :  0.335 s
VMOV   :  0.344 s
VNOP   :  0.051 s
Total time spent:  46.587 s

Your original SSE2 build
RSP Vector Benchmarks Log

VMULF  :  0.355 s
VMACF  :  0.452 s
VMULU  :  0.428 s
VMACU  :  0.471 s
VMUDL  :  0.277 s
VMADL  :  0.449 s
VMUDM  :  0.314 s
VMADM  :  0.420 s
VMUDN  :  0.280 s
VMADN  :  0.446 s
VMUDH  :  0.241 s
VMADH  :  0.343 s
VADD   :  0.245 s
VSUB   :  0.290 s
VABS   :  0.345 s
VADDC  :  0.235 s
VSUBC  :  0.259 s
VSAW   :  0.180 s
VEQ    :  0.335 s
VNE    :  0.354 s
VLT    :  0.379 s
VGE    :  0.398 s
VCH    :  0.662 s
VCL    :  0.868 s
VCR    :  0.491 s
VMRG   :  0.142 s
VAND   :  0.118 s
VNAND  :  0.118 s
VOR    :  0.120 s
VNOR   :  0.121 s
VXOR   :  0.117 s
VNXOR  :  0.121 s
VRCPL  :  0.499 s
VRSQL  :  0.659 s
VRCPH  :  0.170 s
VRSQH  :  0.173 s
VMOV   :  0.219 s
VNOP   :  0.060 s
Total time spent:  12.154 s

To be fair, maybe the compiler messed with the timing, but there was a significant slowdown in game. I was getting around 26VI/s with your sse2 build, with MSVC I'm getting 16 lol.. Another strange thing was, i couldn't even load the plugin on my current 1.6 build or the original. I had to use an old intel build (dunno why it works on this one and not the others).

If someone could help me with compiling 2.1's source, I'd appreciate it. I want to at least try fixing the debugger, among other small things. Perhaps it can replace Nemu , although I must say Nemu has a really good sound plugin. My only complaint is that I think it makes you go below 60fps cuz of sync audio. If only it at least worked for pj64 & other emulators... It's the only sound plugin I've heard that plays SSB64's intro flawlessly.