PCSX reARMed r8

[Marsu]

It's a huge shame that the OpenGLES plugin is currently useless (at least in terms of running anything at a playable speed) as everything looks a hell of a lot better with it, would utilisation of the DSP yield a significant performance boost here?

You could MAYBE implement a video filter which applies effects after rendering (like blurring) with a DSP, but that would be it.


3D is in the end mostly vector-math, so a DSP would not really be helpful, I think.


(please correct me if I am wrong)

 

[meandu229]

It's a huge shame that the OpenGLES plugin is currently useless (at least in terms of running anything at a playable speed) as everything looks a hell of a lot better with it, would utilisation of the DSP yield a significant performance boost here?

You could MAYBE implement a video filter which applies effects after rendering (like blurring) with a DSP, but that would be it.


3D is in the end mostly vector-math, so a DSP would not really be helpful, I think.


(please correct me if I am wrong)

Possibly put the sound track to the dsp? freeing up more cycles for 3d?

 

[Marsu]

Is there even a driver for the DSP-chip yet?

 

[Blue Protoman]

Not one for the kernel version we're on. We'd either have to change just the DSP driver, or change the kernel and everything else. Take your pick.

 

[Exophase]

You could MAYBE implement a video filter which applies effects after rendering (like blurring) with a DSP, but that would be it.
3D is in the end mostly vector-math, so a DSP would not really be helpful, I think.


(please correct me if I am wrong)

Possibly put the sound track to the dsp? freeing up more cycles for 3d?

There's no reason why the entire emulator couldn't run on the DSP (the C64x+, not the ARM9 or fixed function blocks), with the possible exception of some hardware/OS interfaces that'd have to be facilitated through the CPU. Whether or not you could get it full speed is another story..


It'd probably be relatively bad at emulating the CPU but relatively good at emulating the GPU, SPU, and MDEC. I think you could get it full speed while emulating both the GPU and SPU. But you probably don't really need to.

 

[notaz]

So, looking at the speed its a problem of the std - gfx plugin? That means it is not written the best way or does it mean it is slow because it renders in a higher definition than the pcsx4all plugin?

It was written for x86 and it can be considered not optimized too much in general.

I think the pcsx4all plugin was marginally better (maybe 1-2 fps) but that is just a gut-feeling.


If I remember correctly, GT2 came out very late in the life of the PS1, so maybe they squeezed the absolute maximum from the machine, which the Pandora cannot deliver. Or maybe its just badly programmed

Don't forget PSX games rarely run above 30fps natively, something like ~25fps is typical for 3d games. The emu could overclock the emulated PSX in attempt to get more but that would almost certainly break logic of many games - some would run too fast, some would plain crash because things happen faster then they expect..

Not one for the kernel version we're on. We'd either have to change just the DSP driver, or change the kernel and everything else. Take your pick.

I'm pretty sure DSPLink would run fine on our old kernel since it almost doesn't depend on kernel itself, there is just no one wanting to bring it up.

 

[Exophase]

So, looking at the speed its a problem of the std - gfx plugin? That means it is not written the best way or does it mean it is slow because it renders in a higher definition than the pcsx4all plugin?


In general, how near to the end of affordable optimisation are PCSXReARMed and Mupen64?

pcsx4all's GPU plugin was written by Una-i and has performance advantages because it:


a) Does some things a little generically faster than peops, like using reciprocal multipliers for gradients/edge rates instead of dividers and parameterizing out more of the per-pixel options


B) Has some inline ARM code, although I doubt it makes much of a difference in this case really, unless the compiler is pretty bad


c) Omits dithering, which peops has an option to permanently disable.. otherwise most games have it on most of the time and it can have a small to large performance impact depending on how it's implemented


d) Improves performance at the cost of accuracy in various ways, like using 15-bit interpolant steps and only using 5-bit inputs for modulation lighting.. these things may result in obvious bugs


It also uses LUTs for modulation instead of multiplication + clamping, which may have a small performance boost over doing parallel multiplies, but it'd be close.


peops itself does parallel (2x) multiply/blend where it can, which gives it an edge over Una-i's plugin. But it does some performance killing things too. Optimizing it at all would be really hard because the code doesn't use metaprogramming at all and has a ton of hand-specialization, also uses a lot of global variables... extremely difficult to read and maintain.


For Pandora GPU emulation using NEON is probably the fastest method. To really get the most out of it you have to change the entire approach to extract more data-parallelism, not just optimize parts of an existing GPU plugin.


I don't know about the SPU plugin, I imagine it can be made faster too.. but the CPU part is extremely well optimized. The GTE emulation is pretty fast too, courtesy of notaz's NEON code, and further optimization here wouldn't benefit much. GPU is really the biggest sticking point right now.

 

[lomaxx]

I think there is some confusion going on, which is not THAT important, but i still want to mention it:


cdrdao actually creates the "table of content" in the .toc-format not the .cue-format. See the man-page of it. Of course you can save the file as .cue, but the format will still be like in a .toc-file. However it can digest the cue-format when burning bin/cue-images. And also pcsx doesn't seem to care much about whether it gets a .toc- or .cue-file. So from the aspect of running games it doesn't matter.


I compared the content of what cdrdao creates with what the command "cue2toc" does to cue-files and also compared cue-files i found on the net.


CUE-files have a format like this:

FILE "name.bin" BINARY

  TRACK 01 MODE2/2352

    INDEX 01 00:00:00

  TRACK 02 AUDIO

    PREGAP 00:02:00

    INDEX 01 18:26:72

while TOC-files look like this:

CD_ROM_XA



// Track 1

TRACK MODE2_RAW RW_RAW

NO COPY

DATAFILE "name.bin" 16:42:12 // length in bytes: 270004608



// Track 2

TRACK AUDIO RW_RAW

NO COPY

NO PRE_EMPHASIS

TWO_CHANNEL_AUDIO

ZERO AUDIO RW_RAW 00:02:00

DATAFILE "name.bin" #270004608 11:42:12 // length in bytes: 58722624

START 00:02:00

It maybe would be a good idea to change the wiki with the cdrdao-rip-command-line to save the files as .toc and not .cue. But i am not 100% sure if i am right with my researches. I tried around a lot with sorting out cdda-problems with ridgeracer and tombraider and might be confused.

 

[Bramrash]

Just a couple of problems i've found:


Crash Bandicoot 1 ntsc bin/cue - Worked fine until fist level of the third island (called machines something i think), brown bars appear over the word loading and it crashes back to the desktop trying to load the level.


Resident Evil 2 ntsc bin/cue - Man in the gun shop says "Who are you" then waves his gun around for the rest of all eternity. Can still get back to the emulator menu.


Crash team racing - crashes when entering a race


All using version 8 with 1001 bios. Fantastic emulator. sorry for bad spelling and grammer, not used to typing on the pandora yet...

 

[Wootson]

http://www.youtube.com/watch?v=bTUrcECoSk0

 

[CFWhitman]

I think there is some confusion going on, which is not THAT important, but i still want to mention it:


cdrdao actually creates the "table of content" in the .toc-format not the .cue-format. See the man-page of it. Of course you can save the file as .cue, but the format will still be like in a .toc-file. However it can digest the cue-format when burning bin/cue-images. And also pcsx doesn't seem to care much about whether it gets a .toc- or .cue-file. So from the aspect of running games it doesn't matter.


I compared the content of what cdrdao creates with what the command "cue2toc" does to cue-files and also compared cue-files i found on the net.


CUE-files have a format like this:

FILE "name.bin" BINARY

  TRACK 01 MODE2/2352

    INDEX 01 00:00:00

  TRACK 02 AUDIO

    PREGAP 00:02:00

    INDEX 01 18:26:72

while TOC-files look like this:

CD_ROM_XA



// Track 1

TRACK MODE2_RAW RW_RAW

NO COPY

DATAFILE "name.bin" 16:42:12 // length in bytes: 270004608



// Track 2

TRACK AUDIO RW_RAW

NO COPY

NO PRE_EMPHASIS

TWO_CHANNEL_AUDIO

ZERO AUDIO RW_RAW 00:02:00

DATAFILE "name.bin" #270004608 11:42:12 // length in bytes: 58722624

START 00:02:00

It maybe would be a good idea to change the wiki with the cdrdao-rip-command-line to save the files as .toc and not .cue. But i am not 100% sure if i am right with my researches. I tried around a lot with sorting out cdda-problems with ridgeracer and tombraider and might be confused.

Yeah, I've had to use the command toc2cue after ripping a disc with cdrdao in order to make it play on PCSX reARMed r8. It didn't seem to like the .toc file that was created by the program, but ran fine after I converted it to .cue.

 

[Nintendo]

{WipeOut vid}

That looks awesome on Pandora. Thanks for sharing.