Release PCSX ReARMed r22 - now using the DSP

[Hồng Thất Công]

I notice scanline option behaves the following ways:

• No scanlines for most intro movies
• Scanlines are too big to be able to read anything for games like Asteroids and Battle Arena Toshinden 4.
• No scanlines when  Enhance Resolution is set to OFF.

Not sure if these are by design or not.

 

[larry]

Lovely!  And happy new year!

FWIW the minor graphics glitch I reported in Spyro 3 isn't fixed:

http://boards.openpandora.org/topic/6546-pcsx-rearmed-with-a-new-gpu/?p=349112

It's totally not a big deal.  It's visual only, doesn't impact playing the game.  I just thought I'd remind you of its existence.

 

[notaz]

r21 on the repo.

This time I've set myself a goal to make use of pandora's DSP, and did it by moving SPU processing on it.

This was actually quite hard to do without breaking many games and not using excessive copying, as the emulator wasn't designed for parallelism, so I had to rework how audio is emulated internally. Even after restructuring the code in a way I thought was thread safe and what worked fine on dualcore PC, there were many problems to take care of in DSP version, most of which were related to syncing the caches between ARM and DSP. One problem was neighbor data getting overwritten with old data by the DSP writing to unrelated data, because it would get caught on the same cacheline. Another was race condition between ARM writing new commands and DSP evicting cachelines at the same memory location (I was invalidating before reading new commands but it was too late). It was time consuming, but I'm glad I've fully understood the issues and was able to fix them. After this it's now clear that programming for "normal" multicore processors (which is considered hard) is actually a blessing because hardware takes care of cache coherency there, something you don't get programming asymmetric processors like C64x DSP on OMAP.

The result is something like 0-20% overall performance improvement (measured while hires rendering is off), depending on how the game uses PSX SPU. If the game only streams audio from CD, there will be no improvement; while if the game uses tracker music with lots of samples, there will be upto 20% improvement. You should be able to see lower CPU usage if you enable CPU usage display or something like live sysinfo.

As usual, it's on the repo:
http://repo.openpandora.org/?page=detail&app=package.pcsx_rearmed.notaz
(needs recent enough firmware, I forget which one added the DSP, 1.60 I think?)

 

[notaz]

I notice scanline option behaves the following ways:

• No scanlines for most intro movies
• Scanlines are too big to be able to read anything for games like Asteroids and Battle Arena Toshinden 4.
• No scanlines when  Enhance Resolution is set to OFF.

Not sure if these are by design or not.

Yeah the scanline implementation is rather limited, it won't work on FMVs and if other filters are used (scale2x/eagle2x). As for too big scanlines, I've changed it a bit, try the latest version.

FWIW the minor graphics glitch I reported in Spyro 3 isn't fixed:

Yeah there are quite a few such glitches in various games. It may look fixable but actually those small details take the most time, it would take several months of fulltime work to debug and fix them. Maybe someday..

 

[edgex004]

Amazing. Thank you for all your hard work. Since CD audio doesn't gain from this, Reicast probably would not benefit, but I bet Mupen would find this useful if anyone was brave enpugh to try. Hopefully this continues to bear fruit. Thank you again!

 

[Hồng Thất Công]

Thank you so very much notaz. Finally Pandora DSP gets some real usage.


You and other devs are godsends here

 

[Hồng Thất Công]

A little test run and this runs great.  Before, I had to enable auto frameskip to have no sound stutter/slow down in R-Type Delta.  Now with no framskiping, RType - Delta runs 60/60 with perfect sound even with SPU Tempo off.   DSP can do great things! 

 

[ekianjo]

This time I've set myself a goal to make use of pandora's DSP, and did it by moving SPU processing on it.

Thanks Notaz for continuously improving PCSXReARMed!  

Just a question, was there a reason why you chose to focus on the SPU for the DSP usage ? Could it have been used for anything else, or was it simply the most straightforward implementation ? 

 

[elwing]

Generating sounds is a perfect job for a DSP...

 

[Michoko]

Thank you so much Notaz! Can't wait to try this new version!

 

[milkshake]

Brilliant

 

[ptitSeb]

Wow. Impressive achivement!

Source code is your git?

 

[ElPoco]

Wow, you're really good!

 

[sepulep]

nice..how does the speedup compare with the (theoretical) max speed up (no sound)??

 

[ingoreis]

Genious Work,wow...


Can we that use in any Way for other Emulators like Reicast and PPSSPP too?


Will try it soon with my favour PSX Rpgs,thx for your hard Work

 

[ekianjo]

Can we that use in any Way for other Emulators like Reicast and PPSSPP too?

For Reicast and PPSSPP even if you get up to 20% more speed you are still far from full speed anyway... better wait for the Pyra  

 

[PokeParadox]

Thanks for your efforts Notaz!

 

[mcobit]

Brilliant as always


This might be the best optimized emulator for the Pandora by now.

 

[notaz]

Amazing. Thank you for all your hard work. Since CD audio doesn't gain from this, Reicast probably would not benefit, but I bet Mupen would find this useful if anyone was brave enpugh to try. Hopefully this continues to bear fruit. Thank you again!

Actually I've been first looking at moving mupen's RSP handling to the DSP, but unfortunately that code is tied up too much in the emulator and it would be nightmare to synchronize. In other words this concept would probably work on a specially designed emulator, but not with mupen64plus.

Thanks Notaz for continuously improving PCSXReARMed!  

Just a question, was there a reason why you chose to focus on the SPU for the DSP usage ? Could it have been used for anything else, or was it simply the most straightforward implementation ? 

It most likely could, but it's difficult. In the real PSX SPU is rather autonomous and has it's own RAM that main CPU can't access (only SPU can), which kind of allows moving it's emulation to separate thread or processor, but it's still problematic as the SPU can interrupt main CPU any time, so I had to use tricks to handle it, like predicting interrupts in advance. The DSP could also handle graphics, if optimized enough, but I really doubt it could beat Exophase's NEON GPU. It would also be hell lot of work..

Wow. Impressive achivement!

Source code is your git?

Yes, see "spu: start offload code to TI C64x DSP" and "spu: finish offload code to TI C64x DSP" commits, although they are not clean and mixed with emulation rework code..

If you want to mess with DSP, I suggest you start with minimal tests like making the DSP multiply numbers, maybe based on sample code in c64_tools zip.

nice..how does the speedup compare with the (theoretical) max speed up (no sound)??

Not sure what you mean here.

Can we that use in any Way for other Emulators like Reicast and PPSSPP too?


Will try it soon with my favour PSX Rpgs,thx for your hard Work

Probably, but would it be worth spending a month of work to get like 20% speedup?

Those things are probably dominated by SGX driver anyway..

 

[_wb_]

Incredible and very impressive how notaz always finds a way to significantly improve something that was already pure perfection!

Question: does this DSP work transfer in some way to the OMAP5? Maybe not by using the OMAP5's DSP, but still, having a threaded implementation would help there too, right? Not that performance will really be an issue on the OMAP5, except maybe if we would want to try rendering in triple resolution and/or with fancy filters? Still, performance improvement also means battery life improvement even if fullspeed is easy to obtain, so it's always worth it.