Release PCSX ReARMed r22 - now using the DSP


Question: does this DSP work transfer in some way to the OMAP5?
Yeah if it is not compiled for c64_tools, generic pthread implementation is used, so this should already work for libretro build, for example. For OMAP5 I should be able to move the rendering to separate thread too, as the other core will be able to run NEON code, unlike the DSP.
 
nice..how does the speedup compare with the (theoretical) max speed up (no sound)??
Not sure what you mean here.
I think he means that with some emulators, if you disable the sound, you're actually freeing additional CPU cycles (because you're no longer processing audio commands/emulating sound chips such as the C64 SID etc.), which would give the CPU/GPU cores more time to do their thing
 
This is awesome! Thanks a lot notaz! I don't know where we would be without you. Well, I am off to test some of my games again... later
 
Nice to see DSP finally implemented in such a useful way, especially since bsp spent a lot of time on it too. Great job Notaz.  
 
Last edited by a moderator:
Notaz, care to mention a couple of games worth testing to see any difference in performance ? I checked with about a dozen of them and I failed to see any difference with the DSP on (because they were already full speed even in high res, I guess).
 
Notaz, care to mention a couple of games worth testing to see any difference in performance ? I checked with about a dozen of them and I failed to see any difference with the DSP on (because they were already full speed even in high res, I guess).
I can't think of any, implementing this was more like "get an achievement" type of thing. You can either disable frameskip and underclock, or enable cpu usage display (advanced options), or use something like liveinfo and observe CPU usage counter.

Actually it should be noticeable on CC units when running with highres rendering, some games were not hitting fullspeed there.
 
Last edited by a moderator:
Thanks! I did the following test:

GT1 high res, frameskip off, speed hack on, DSP OFF, 1Ghz:

the game stutters once in a while and the CPU is between 70 and 100% Load while staying on average around 80_85% I feel.

GT1 high res, frameskip off, speed hack on, DSP ON, 1Ghz:

The game only stutters in extreme cases (once per circuit or something) and the CPU is between 60 and 80% most of the time.

Impressive, full speed high res without frameskip ! :)
 
Notaz, care to mention a couple of games worth testing to see any difference in performance ? I checked with about a dozen of them and I failed to see any difference with the DSP on (because they were already full speed even in high res, I guess).
I had slowdowns with "Star Wars - Episode 1".
 
That's incredible !!

Notaz you are simply amazing B)

Someone has to send a message to the user bsp.. ;) he deserve it
 
Forgot to mention that the 20% figure (which is rather optimistic, for most games it's lower, on some even 0%) was measured without hires rendering enabled. With hires the emulator's CPU usage is around 2x higher, so DSP's "help" becomes only 0-10% and the improvement is not that obvious.
 
Last edited by a moderator:
@notaz what debugger did you use whilst developing this (gdb?) and what development/debugging techniques did you use to identify and fix the cache line issues? I've had to fix very similar issues in the past (developing on PS2 and Wii) but I am not sure how I would have done it without the integrated debugging environments available for each console without a lot of pain and guesswork.

Oh and of course, thank you and wow, yet another amazing achievement - you continue to inspire lots of developers on this board. I have the feeling that if anyone else tries using the DSP for any non trivial work, you may have some questions being fired your way when things don't work right ;)
 
Mostly pain and guesswork, and printf on DSP side that bsp has kindly put in, which can be read out on ARM side. The cache issues would go away after sprinkling the code with unnecessary flushes/invalidates, also by removing all parallelism (waiting for DSP just after sending command). Adding/removing this extra code allowed narrowing down to something specific. I have PC's filesystem mounted on my pandora and can run the binary as soon it's compiled, so it's not too bad as things can be tested quickly.
 
I don't know what DSP is, but whatever you did fixed the sound on Oshaberi Parodius.  Game works perfect now.  Thanks for what you do!
 
This long standing bug cited below is still affecting PCSX as of r21.

It is a serious bug, just may has not been considered, as not many people launch PCSX via Pandafe,

or other launchers which use command line arguments to pass a certain ROM filepath to PCSX.

Would very much appreciate a fix of it! Thanks for the great work!

Bug report: Controls are messed if PCSX is called externally (start PCSX with specific rom filepath)
Starting PCSX alone —> Controls work as expected
Starting PCSX via Pandafe —> Controls work only very partial, most assigned keys are missing!

My initial guess:

Pandafe may launch PCSX with corrupted environment variables or with an alternative appdata directory or without a certain necessary pre-run script, or PCSX may has a bug if launched with rom arguments, instead of being launched standalone and then launching the rom itself.

Further investigation (if PCSX is launched from Pandafe):

From the gpio-keys only up/down/left/right work, all others are mysteriously missing: A/B/X/Y, L & R, Start, Select.
Plus my USB devices (Logitech Cordless Rumblepad, one for each player 1 & 2) have wrong keys assigned (those from the gpio-keys!).

I made a backup of appdata/pcsx_rearmed/.pcsx/pcsx.cfg and also after the bug occurence, pcsx.cfg has still the same modification date and content (diff == null) as the backup. So the config was not messed with. It must be a bug from PCSX treating controls different if called externally, or PANDAFE calling PCSX somehow wrong.

My config file for bug reproduction:

attachicon.gif
 pcsx.txt

(pcsx.cfg renamed to .txt due to forum software restrictions)
 
Last edited by a moderator:
You should be able to eliminate the possibility of it due to a bad environment or missing pre-run scripts by mounting the PND then running PCSX from a terminal both with and without a ROM path. You can also work out if any pre-run scripts or anything are being invoked by looking at the PXML.
 
This long standing bug cited below is still affecting PCSX as of r21.

It is a serious bug, just may has not been considered, as not many people launch PCSX via Pandafe,
I remember not being able to reproduce this. Maybe you have some customizations in Pandafe or something else.

I'll try again..
 
I don't have any heavy modifications I'm aware of!

1) In Pandafe for the Playstation platform I added "bin" to the recognized ROM filetypes.

2) My ROM file structure is as follows, derived from this my own hint.

path/to/roms/psx/

  genre1/

     game1.cue

     game1.bin

     game1.whateverelse

     game2.bin

     game3.whateverelse

  genre2/

     game4.cue

     game4.bin

     game5.whateverelse

3) For test reasons I reset PCSX ReARMed to a blank profile, and the bug was not reproducible, neither if launched from XFCE nor Pandafe!

My buggy appdata folder is as follows:

.pcsx/cfg/ is empty

.pcsx/cheats/ is empty

.pcsx/memcards/ contains some .mcd files

.pcsx/patches/ is empty

.pcsx/plugins/cfg/ is empty

.pcsx/sstates/ contains some .NNN files

bios/ contains some .bin files and ps1-models.rtf and ps1-models.txt (which btw are both mentioned as "bad BIOS file:" in /tmp/pndrun_pcsx_rearmed.out, which then continues "found skin.txt" and "input: bad key: <KeyName>", <KeyName> being LeftControl, RightShift, LeftAlt, RightCtrl, Home, PageUp, End, PageDown, Menu.

pcsx.cfg contains some diffs to a default profile, check attachment

pcsx-<oldconfig-remark>.cfg files

lastcdimg.txt contains /media/volumeName/roms/ps1/Genre-Name/Game Name (YYYY).bin

pcsx.txt
 

Attachments

  • pcsx.txt
    2.7 KB · Views: 1,011
Last edited by a moderator:
Back
Top