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

[RPGMaster]

Originally Posted by Frank74

Aha!

Must have a touch of dyslexia, reading SSSE3 as SSE3.

Hopefully I'll be getting a new PC end of the year.

Lol I don't blame you for getting mixed up. Even I used to be confused about it. Lucky you! I could use a new PC ;/ .

[oddMLan]

Originally Posted by RPGMaster

rsp.dll actually requires SSSE3. It needs it for instructions like pshufb.

Lies, it actually requires SSJ3 to execute over nine thousand instructions per second.

[HatCat]

Originally Posted by Frank74

Wondering why rsp.dll crashes with an exception, but rsp_sse2.dll works fine.

My processor is supposed to support sse3.

I myself have only SSE3 support on this 1.90 GHz machine but have never really been able to test the SSSE3 implementation myself...actually once when I had Windows installed on MarathonMan's laptop. Past that, I've never had access to SSE4 or SSSE3 h/w.

Don't really need SSE3 or later though; everything the N64 RSP does can be directly mapped to SSE2 which is why I'm hoping there won't even be a reason to have a SSSE3 version of the plugin.

[V1del]

FWIW i never had any issues with the SSSE3 variant, but I wasn't really doing much specific testing so maybe some quirkass RSP usage in some game that has an issue with SSSE3 exists :P

[RPGMaster]

Originally Posted by HatCat

Don't really need SSE3 or later though; everything the N64 RSP does can be directly mapped to SSE2 which is why I'm hoping there won't even be a reason to have a SSSE3 version of the plugin.

Probably not. The gap seems to be smaller, with this current source. Although I'm using Intel since I am unable to compile with GCC. It's giving me trouble, saying 'there's conflicting types for DllMain".

[HatCat]

Oh I'm sure that would have to have been a bug with the GNU C compiler.

All the vector stuff was optimized 95% or more on the C level; any responsibility beyond that went to the compiler (which actually did a poor job with the multiply packs). It's a little more under my control and less the compiler's these days since some inline-assembly-ish intrinsics are being used (inflexible and unportable code ftw? ), but the SSSE3 code was all the shuffle method MarathonMan suggested and, automatic code generated by the compiler in some of the clips/merge stuff. So if you guys found a bug with the SSSE3 build, that didn't happen with the SSE2 build, that would imply a compiler bug with GCC's code generation, rather than a bug in my code.

[HatCat]

Originally Posted by RPGMaster

unable to compile with GCC. It's giving me trouble, saying 'there's conflicting types for DllMain".

ld --shared --entry _DllMain@12 -o ../rsp/bin/rsp.dll ../rsp/obj/module.o ../rsp/obj/su.o ../rsp/obj/vu.o ../rsp/obj/multiply.o ../rsp/obj/add.o ../rsp/obj/select.o ../rsp/obj/logical.o ../rsp/obj/divide.o -lkernel32

[RPGMaster]

Originally Posted by HatCat

It's a little more under my control and less the compiler's these days since some inline-assembly-ish intrinsics are being used (inflexible and unportable code ftw? )

I would prefer multiplying the performance .

Originally Posted by HatCat

ld --shared --entry _DllMain@12 -o ../rsp/bin/rsp.dll ../rsp/obj/module.o ../rsp/obj/su.o ../rsp/obj/vu.o ../rsp/obj/multiply.o ../rsp/obj/add.o ../rsp/obj/select.o ../rsp/obj/logical.o ../rsp/obj/divide.o -lkernel32

thnx

[HatCat]

There is no change in performance, just in method of expressing the algorithm.
It can however be said that the binary itself has "multiplied performance".

The algorithm is adjusted to fixate itself to present-day compiler limitations for Intel SSE2. I'm sure the native C version of the algorithm would beat out the inline-assembly-ish intrinsics for many other operations.

[uyjulian]

Originally Posted by RPGMaster

rsp.dll actually requires SSSE3. It needs it for instructions like pshufb.

Yep, that extra S.

Ugh these confusing names