N64 Anyone?

[mali]

Sorry but that makes no sense, something's very wrong here

That makes no sense in the sense of there might be missing some info about the devices/CPUs the benchmarks have been run on but not in the sense that the numbers are far off reality.

The regions should be right, I don't know enough about different steppings or changes in the designs between different versions.

Here are more results:
http://www.tux.org/~mayer/linux/results2.html

Edit:
Hotcooler beat me to it

 

[ldesnogu]

That makes no sense in the sense of there might be missing some info about the devices/CPUs the benchmarks have been run on but not in the sense that the numbers are far off reality.

The regions should be right, I don't know enough about different steppings or changes in the designs between different versions.

Well these variations are what makes me think we should not bother getting results out of the web without knowing more. I have even seen people quoting results compiled with gcc -O0
OTOH I trust MWeston results.

EDIT: I found other results for Celeron M 900 MHz
CODE
MEMORY INDEX : 5.295
INTEGER INDEX : 5.658
FLOATING-POINT INDEX: 9.391

Ref slide 10 of http://www.ucc.asn.au/~mccabedj/eeepc/Eeepc.ppt
That still is not as bad as my previous claim of it being 2x faster than C-A8 @600 MHz but it certainly looks different from what you showed

 

[midna25]

*Imagines playing paper mario on the bus and cries*

 

[Hotcooler]

But I'd like to see some new benchmarks on new kernel... OGL stuff to... would be nice... and the numbers may be higher this time

 

[mali]

The numbers are high enough IMO. We should get together some NEON ASM tutorials
Or cram in a Cortex A9 :lol:

That still is not as bad as my previous claim of it being 2x faster than C-A8 @600 MHz but it certainly looks different from what you showed

I just took what google gave me :lol:
It's still roughly Pentium III, Atom, Cortex are in the same performance frame(except Cortex missing a reasonable FPU) But some hardware FPU is better than none

 

[Happy]

I suppose my aspirations for an emulator are reaching fairly high, but I really want it to handle anything the original hardware supported on the software side. I feel it would be incomplete otherwise.

But to elaborate on my original thoughts the rough work division of the emulator would be as follows:

R4300 handled by ARM core, FP instructions with NEON
RSP/RDP handled by DSP
Video resizing/antialiasing by the SGX
Audio by ??? (I'm not certain if Pandora has direct access to an audio DAC)

I still need to review the NEON and DSP instruction sets in more detail to determine the expense of emulated opcodes (i.e. how close are the native instructions to the emulated instructions). Also need to determine expense of synchronizing the different cores. Which wouldn't be something to speculate about, but to just code something and see how it goes.

 

[hlidegp2x]

R4300 handled by ARM core, FP instructions with NEON
RSP/RDP handled by DSP
Video resizing/antialiasing by the SGX
Audio by ??? (I'm not certain if Pandora has direct access to an audio DAC)

R4300 uses 32 64-bit GPR and 32 64-bit FPR. So if a true 64-bit computation is involved, you need twice registers and twice or more instructions (dadd rd, rs, rt ==> ADD rd_0, rs0, rt0; ADC rd1, rs1, rt1). Hopefully, ARM is pretty good for doing 64-bit computations with 32-bit registers and instructions. On PSP where there is no 64-bit instructions, it takes much more registers and instructions to do them. I heard 64-bit float computation are rarely used in N64 so I guess VFP on 64-bit float can be used even if it is slow on Cortex-A8.

Note that you can also use neon for integer operations but dunno if it can be done in scalar form.

If I'm not wrong, RSP is kind of a MIPS with a vector set of instructions with its own register set. I don't see how DSP can be any use here. Unless you are speaking about HLE RSP, not about emulate all the RSP instructions or microcodes. What about the overhead to communicate data between ARM and DSP ?

 

[Happy]

As for 64-bit operations the N64 is reasonably explicit when they are needed in place of 32-bit (the R4300 is usually in 32-bit mode) You are definitely correct about using ADD, ADC for implementing the 64-bit add with only a 32-bit pipeline, but it should only require one extra register for the intermediate result (unless by double the registers you mean the operands require two 32-bit registers for storage . . . probably what you were referring to, in retrospect)

IN regards to the DSP, vector integer ops are vector integer ops, however you call them. I haven't looked closely enough at the DSP instruction set to know for certain that it is capable of doing the same calculations as the RSP, but it did seem quite versatile. To use the DSP, the main ARM processor would need to dynamically translate code for the RSP to something for the DSP and then tell the DSP to start executing the code. The batch processing nature of it seems common to DSP tasks. The synchronization overhead (even the mechanism) needs to still be evaluated. However, this is still just initial stages of design, I was figuring the DSP was there and it would be a shame to waste the computing power.

 

[ldesnogu]

The RSP has 32 128-bit registers organized as 8 x 16-bit (ref).
The good news is that it can only address 8 KB data and 8 KB instructions (or is it 2 x 4? The diagram and the text don't agree).

As far as ADDS/ADC pair goes, beware that it will prevent dual issuing

 

[hlidegp2x]

As far as ADDS/ADC pair goes, beware that it will prevent dual issuing

yes, 2 cycles unless the dynamic recompiler is smart enough to reorder some instructions to execute this pair within 1 cycle.

For instance, transforming this pair
CODE

1: DADDIU $t0, $t0, 1
2: ADDIU $t1, $t1, 1

into
CODE

1: ADDS $t0.lo, $t0.lo, #1 // $t0[31..0] += 1
1: ADD $t1.lo, $t1.lo, #1 // $t1[31..0] += 1
2: ADC $t0.hi, $t0.hi, #0 // $t0[63..32] += carry of $t0[31..0] += 1
2: MOV $t1.hi, $t1.lo, ASR #31 // $t1[63..32] = $t1[31] * 0xFFFFFFFF (0 or -1 according bit 31 of $t1)



of course, the fourth instruction can be totally delayed until we need to read $t1.hi.

 

[multiplex]

If I were coding an emulator, I'd also check out the MMU, which is an advantage the Cortex-A8 has over the PSP.
Daedalus is worth checking out no matter whether you're starting from scratch or not, though. There's very good blog posts both from StrmnNrmn and the DaedalusX64 people detailing various optimizations they've looked at.

 

[Happy]

I've followed StrmnNrmn's postings for a while and have been in private communication with MooglyGuy (mostly in regards to the RDP). Both are good sources of fresh ideas and conversation.

For reference, the RSP can address 4KB of instruction memory (1K of instructions at 4 Bytes/instruction) and 4KB of data memory. However, most microcode frequently runs out of room with only 1K of instructions and DMA's overlays in and out of the RSP instruction memory in situ. An example would be to start with instructions to calculate vertex lighting and then, trapping the command to process a triangle, DMA the instructions for slope calculations and interpolation into the same space of memory that just held the lighting instructions. Which means it would take a high degree of sophistication to give a static recompilation of the entire microcode (baring in mind that, in a sense, is what HLE does).

It's too early for me to tell if dual issuing will provide opportunities for performance or if the opportunities for its use are limited. I am still learning the intrinsics of the Cortex-A series. However, looking closer at the C64+ DSP, I hope that it can perform all the RSP's 8x16 bit vector calculations, albeit at only 2x16 in one instruction.

I am definitely enjoying the responses to this topic. If anyone is really prepared for the nitty-gritty details of how the RSP/RDP are utilized and their hardware implementations, I am prepared to answer questions.

 

[ldesnogu]

As Moogly wrote the RSP is really like the VU units of the PS2

Another word of caution: don't rely too much on intrinsics, the compiler is free to reorder them. I think assembly language is the way to go for the places where speed is really needed.

 

[kin]

I wanna play waverace64

 

[Exophase]

I doubt this is what MooglyGuy wants, but I don't think that LLE RDP/RSP, especially RDP in software instead of hardware (DSP or not) is a viable way to go, at least not at first. In other words, you'd have much more luck getting an emulator that's like the "typical" N64 emulator implementation to work: emulating the RSP microcode at a high level instead of properly. If you get this working then you could try to move to doing true emulation, but it would seem pretty hopelessly optimistic to expect Pandora to do this at a good speed when the only person doing this right now has an implementation that is way too slow for modern PC's. That's not to say that said implementation can't be much faster, but it'd be a massive undertaking (much, much more work than porting something like Daedalus would be)

 

[multiplex]

The numbers are high enough IMO. We should get together some NEON ASM tutorials
Or cram in a Cortex A9 :lol:

Hahah, got me thinking; "Emulate more systems than ever with the Pandora A9 expansion card!"
Or stuff a FPGA into a SD card case. "What, 2 64-bit graphics co-processors and a programmable DSP, you say? Yeah, sure, my Pandora can do that."

 

[cb88]

SDIO is a 1 or 4 bit 25Mhz (25-100Mbs) bus...probably not fast enough to be of use for most emulation although the pandora's implementation might be capable of more

 

[Pseudonym]

try usb Multiplex. USB is the way to go!

 

[Chip]

SDIO is a 1 or 4 bit 25Mhz (25-100Mbs) bus...probably not fast enough to be of use for most emulation although the pandora's implementation might be capable of more
It's at least another year or so before the A9 ships, so I don't think we need to worry about that just yet.

 

[cb88]

im not sure why you quoted me there... i wasn't even considering it the bus is too slow for that kind of thing