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

[HatCat]

Just cmpeq is fine actually, shouldn't have to risk saying set1_epi16(~0x0000).

Maybe it just needs to be round = _mm_set1_epi16(round, round); instead or something, I can look at it later. But we're talking about a GCC bug there, not malpractice of either inline assembly or intrinsics.

Originally Posted by RPGMaster

If you want to improve your VMULF, the sign clamp algorithm can be improved.

Doubt it. You have to be very careful when making these kinds of changes.

VMULF started out a lot faster than how it ended up when I was done stabilizing it.

[RPGMaster]

Originally Posted by HatCat

Just cmpeq is fine actually, shouldn't have to risk saying set1_epi16(~0x0000).

Maybe it just needs to be round = _mm_set1_epi16(round, round); instead or something, I can look at it later. But we're talking about a GCC bug there, not malpractice of either inline assembly or intrinsics.

You're not the first person to dislike set1_epi16(~0x0000). Out of curiosity, what's wrong with using that? GCC isn't the only compiler with a bug in _mm_cmpeq_epi16.

Originally Posted by HatCat

Doubt it. You have to be very careful when making these kinds of changes.

VMULF started out a lot faster than how it ended up when I was done stabilizing it.

Lol dude, I'm very careful. Especially since it's easy to test.

[HatCat]

It's so easy to test, that those code pastes you just edited out of your post were in fact incomplete, or broken, and showed no conceptual understanding of the ultimate clamping process. It is more complicated than that. Doesn't matter how many games you tested, doesn't make it easy to test. I had to revise VMULF many times to fix more than just [non-]MusyX regressions, even before writing a separate C program to loop all combinations of VS and VT, multiply and compare them like you started testing. Even the old code before testing intrinsics in it probably had it wrong.

[RPGMaster]

Originally Posted by HatCat

It's so easy to test, that those code pastes you just edited out of your post were in fact incomplete, or broken, and showed no conceptual understanding of the ultimate clamping process. It is more complicated than that.

I editted because I realize it was a bad example. I jumped to conclusions and thought the difference in efficiency was due to the sign clamping algorithm, but unsure what caused the difference now. I sometimes read too fast. My point is still valid, that it could be more optimized. I just tried to give an example of code you're familiar with, but you're even unsure about the accuracy of your old code.

Originally Posted by HatCat

Doesn't matter how many games you tested, doesn't make it easy to test. I had to revise VMULF many times to fix more than just [non-]MusyX regressions, even before writing a separate C program to loop all combinations of VS and VT, multiply and compare them like you started testing. Even the old code before testing intrinsics in it probably had it wrong.

I don't test games as extensively as I used to. Imo, it's much more time efficient to just test & analyze algorithms. I don't see how an algorithm that produces the exact same results for every single combination is inaccurate .

[HatCat]

>I don't see how an algorithm...

I don't see an algorithm period in your posts; I just see repeated references being made that the function is somehow supposed to become more optimized, through methods with little detail being given over.

Even before editing you weren't actually quoting the clamping algorithm itself anyway, just a part of it. Running loops and comparing results isn't everything. The entire function had parts of different things being solved, scattered over the function, and special RSP element restrictions applied to it that made the RSP opcode bug-free, even where results might not necessarily match. (I remember MarathonMan finding a "bug" in my VMADN opcode...it was caused by a huge, nearly prime number product, which could never be reached by 2 16-bit integers.) You have to understand the objective, what is being solved, and the algorithm...just pasting code that I have done in the past doesn't mean it's pasting a sign-clamp algorithm. VMULF just happens to be easier to avoid doing a clamp and weeding out a single corner case.

The only truly accurate signed clamping algorithm is more like this:

i16 signed_clamp(i32 product)
{
    if (product < INT16_MIN)
        return INT16_MIN;
    if (product > INT16_MAX)
        return INT16_MAX;
    return ((i16)product);
}

Anything else I've done is just so that it gets vectorized...at quite a heavy price of readability. No matter how many tests you do, a lot of the source can be open to interpretation, and isn't always void of C strict behavior regulations either.

[RPGMaster]

I see what you're saying. I could have worded it better. What I really meant to say is just optimizing the corner case handling. I basically do just enough to get the correct result, rather than implementing the complete algorithm when I don't have to.

So I was testing BattleTanx(U) (LLE audio & LLE gfx) with PJ64's RSP and got an error message saying "SP_DRAM_ADDR_REG not in RDRam space". So I put that same error check in your RSP and it also triggered. Kinda odd ;/ .

[HatCat]

I might remove the corner-case handling anyway.

All VMULF is doing is signed-clamping. I just happen to only care about the corner case of -32768 * -32768 because it's the only possible way to overflow or underflow in mulf's particular case (confirmed also by zilmar's success at reverse-engineering the algorithm, but also just a mathematically inducible thing). So better to use the same signed-clamp method for all the functions. This way, if I break signed clamp function, it affects VMULF as well as everything else and makes games easier to test.

Originally Posted by RPGMaster

So I was testing BattleTanx(U) (LLE audio & LLE gfx) with PJ64's RSP and got an error message saying "SP_DRAM_ADDR_REG not in RDRam space". So I put that same error check in your RSP and it also triggered. Kinda odd ;/ .

I don't have an error message for SP DMA in my plugin, so by "triggered" I guess you mean that the same CP0 inputs for DMA are in my plugin as the ones resulting from the PJ64 RSP interpreter.

This is either an interpreter bug in PJ64's RSP plugin, or you're getting said SP DRAM address boundary errors as artifacts from using the recompiler and should just try testing using the CPU interpreter core instead.

[RPGMaster]

I was testing Battle for Naboo with your latest RSP + cpu interpreter + modified pj64. I get "LLV Odd addr." when I get close to a certain enemy and start shooting. I'm curious whether there's a problem with the emulator or if the game actually does it intentionally. I know it's from gfx task, since I also got the message when HLE audio was enabled.

I was testing out the code exhalatio posted. The graphics look fine after the change. Maybe I'll try testing your rsp with old zilmar spec M64p.

[HatCat]

Originally Posted by RPGMaster

I was testing Battle for Naboo with your latest RSP + cpu interpreter + modified pj64. I get "LLV Odd addr." when I get close to a certain enemy and start shooting. I'm curious whether there's a problem with the emulator or if the game actually does it intentionally.

If it was a problem with the main CPU emulator, then most likely other parts of the ICACHE would get corrupted, not just that one single instruction to be unaligned or illegal LLV. So it most likely was intended on the RSP.

Would always help to be able to test for sure with a saved state though so that I could have it implemented on my own end.

[RPGMaster]

Originally Posted by HatCat

If it was a problem with the main CPU emulator, then most likely other parts of the ICACHE would get corrupted, not just that one single instruction to be unaligned or illegal LLV. So it most likely was intended on the RSP.

Would always help to be able to test for sure with a saved state though so that I could have it implemented on my own end.

Ok, made a save state. All you have to do is keep shooting lasers (just hold B) and it eventually pops up.

https://www.dropbox.com/s/em4mutzttd...29.pj.zip?dl=0