Nintendo DS 3d performance

[Panajev2001a]

Re: ...

The FPU appears few MFLOPS short of the N64 FPU

I expect the sustained number of ARM9-VFPU to be be higher than R4300i because

1. It is a newer design.
2. It has dedicated vector instructions, while R4300i relied on scalar float loops.

I agree with you on the issue ( the ARM site confirms the fact it has dedicated Vector Instructions ): I also expect the RAM to do the system more justice than what the RAMBUS RAM did in the N64.

You are forgetting about the RSP which was used for T&L and more by some developers.

RSP never supported 4-byte floats, it was strictly for a 8-slot vector of 2-byte integers.

I should do more research on the RSP, from what I used to know I thought it was usable as a fixed-point VU for T&L ( it was not designed to be a GTE killer though ) as well as I remember some developers talking about how they did use it to help in 3D calculations.

 

[V3]

The 4 BGs and 128 OBJs ( Sprites ) are quite explicit to peopel who have coded for the GBA.

No, they would not vary even if the CPU is clocked at 2x the frequency as they are both Hardware limited: the OAM ( Object Attribute Memory ) for example only supports 128 entries.

The chances of GBA compatibility is pretty good then. Its only upto Nintendo

BTW is there possibility that the 120k poly/s and 30M pixel/s works like tile base renderer ?

 

[Megadrive1988]

120,000 polygon/sec rendering is a bit less than Nintendo 64, is it not?

iirc, Nintendo 64 could do around 150,000 ~ 160,000 polygons/sec


edit: anyway, I don't care much about DS / Nitro's 3D performance (I'll care about that for the next gen Gameboy) I want to know how much of an improvement over GBA it is in 2D sprite power
(I'd like NeoGeo MVS/AES level or better)

 

[Deadmeat]

120,000 polygon/sec rendering is a bit less than Nintendo 64, is it not?

About the same. This is why I suspected that Nintendo recycled the N64 GPU design...

Since you are looking at it through a GBA resolution screen, I don't think you will complain too much.

 

[Panajev2001a]

120,000 polygon/sec rendering is a bit less than Nintendo 64, is it not?

About the same. This is why I suspected that Nintendo recycled the N64 GPU design...

Since you are looking at it through a GBA resolution screen, I don't think you will complain too much.

I do not think we will complain too much.

 

[Panajev2001a]

120,000 polygon/sec rendering is a bit less than Nintendo 64, is it not?

iirc, Nintendo 64 could do around 150,000 ~ 160,000 polygons/sec


edit: anyway, I don't care much about DS / Nitro's 3D performance (I'll care about that for the next gen Gameboy) I want to know how much of an improvement over GBA it is in 2D sprite power
(I'd like NeoGeo MVS/AES level or better)

It supports the same number of sprites and BGs, but it should flicker less if you use lots of big sprites and do lots of background updating of tile and map data: it is running at 2x the frequency after-all.

 

[ERP]

Just to correct some of the N64 comparisons

The RSP was 8x8bit integer vector ops, it was used for all the 3D vertex operations, programming it made VU programming look easy, especially since you had to do triangle setup aswell as transforms on it. Nintendo didn't give many developers a chance to play with it.

No N64 ever did any where near 100MFlops, the CPU took 5 cycle to do an fp multiply (you work it out).

The actual maximum triangle rate on N64 is way over 120K, probably closer to about 500K (I've never tested the RDP setup rate limit) you need to write uCode to get anywhere near this. Nintendo did at one point release a uCode called turbo3D which pushed PS quality polygons at about this rate.
For the most part though N64 games were fill limited, so it's not really an issue.

 

[moichi]

Main Processor: ARM946E-S(67MHz)
Instruction Cache 8Kbytes
Data Cache 4Kbytes
TCM(?): Instruction 32Kbytes, Data 16Kbytes

Sub Processor: ARM7TDMI(33MHz)

Main Memory: 4Mbytes (8Mbytes for debug version)
ARM9/ARM7 Common Memory: 32Kbytes(16Kbytes x 2)
Internal Work RAM for ARM7: 64Kbytes
VRAM: 656Kbytes

LCD:
Size: 256x192xRGBx2screen
Color: 262,144color(R:G:B=6:6:6)

2D Graphics Engine(A,B)
BG: max 4planes
OBJ: max 128planes

3D Graphics Engine:
Transform: 4Mvert/s(max)
Polygon: 120Kpoly/s(max)
Pixel Fill: 30Mpixel/s(max)

Sound:
16ch ADPCM/PCM (can allocate to PSG up to 8ch)
Microphone(!)

Wireless Communication:
IEEE 802.11 based original protocol

Input Devices:
Touch Panel(!)
Button: Cross(+), A, B, R, L, START, SELECT (yet undecided whether support X and Y button)

Power Control:
Sleep Mode Suport(Wakeup on specified time or when recieve some messages via wireless network)
Power contorol for 2D Engine, Rendering Engine, Geometry Engine(!) and LCD

 

[Megadrive1988]

Color: 262,144color(R:G:B=6:6:6)

nice color ! 8)

 

[Panajev2001a]

Just to correct some of the N64 comparisons

The RSP was 8x8bit integer vector ops, it was used for all the 3D vertex operations, programming it made VU programming look easy, especially since you had to do triangle setup aswell as transforms on it. Nintendo didn't give many developers a chance to play with it.

No N64 ever did any where near 100MFlops, the CPU took 5 cycle to do an fp multiply (you work it out).

The actual maximum triangle rate on N64 is way over 120K, probably closer to about 500K (I've never tested the RDP setup rate limit) you need to write uCode to get anywhere near this. Nintendo did at one point release a uCode called turbo3D which pushed PS quality polygons at about this rate.
For the most part though N64 games were fill limited, so it's not really an issue.

Thank you.

 

[Panajev2001a]

ERP, I remember that they did advertise the FPU having a theoretical peak of ~100 MFLOPS: it might have been obtained under weird FP workloads ( specific series of instructions ) and far from what you could sustain, but that is what they used to rate the FPU IIRC.

 

[Guden Oden]

Pana,
The R4300i didn't really have an FPU per se. It ran FPU instructions through the same pipeline as integer ops, though with longer instruction latency (seven stages as opposed to five, or something like that, was too damn long ago since I read about that chip).

It was a pretty damn el-cheapo design overall...

 

[mboeller]

Pana,
The R4300i didn't really have an FPU per se. It ran FPU instructions through the same pipeline as integer ops, though with longer instruction latency (seven stages as opposed to five, or something like that, was too damn long ago since I read about that chip).

It was a pretty damn el-cheapo design overall...

You can find informations about the R4300i here :
http://futuretech.mirror.vuurwerk.net/prod_overview_book.html

I think the R4300i in the N64 worked at 93,75MHz (1.5x the external clock of 62.5MHz which was 1/4 the clock of the RDRAM) and theoretically had 121.875Mips or 93.75MFlops but not both together. So in the end the real Mips and Mflops would be only 50% of the theoretical value or most likely even lower without even taking into account the latency problems with the RDRAM the N64 had according to different sources.

 

[Panajev2001a]

Pana,
The R4300i didn't really have an FPU per se. It ran FPU instructions through the same pipeline as integer ops, though with longer instruction latency (seven stages as opposed to five, or something like that, was too damn long ago since I read about that chip).

It was a pretty damn el-cheapo design overall...

You can find informations about the R4300i here :
http://futuretech.mirror.vuurwerk.net/prod_overview_book.html

I think the R4300i in the N64 worked at 93,75MHz (1.5x the external clock of 62.5MHz which was 1/4 the clock of the RDRAM) and theoretically had 121.875Mips or 93.75MFlops but not both together. So in the end the real Mips and Mflops would be only 50% of the theoretical value or most likely even lower without even taking into account the latency problems with the RDRAM the N64 had according to different sources.

http://mips.com/content/Products/Cores/32-BitCores

The situation is more interesting: no FPU for the R4K family, but think about the PSP and the R4000i that has an FPU and a VFPU attached to its co-processor pipes ( or maybe the FPU is the VFPU sort of like the SH-4's SIMD FPU ).

Normally then R4K cores do not come with an FPU, but you can add one to a co-processor pipe.

Is the R4300i single issue ( non superscalar ) ? It is IIRC: in this case what you said makes sense as the CPU cannot issue two instructions per cycle to the execution unit and keep feeding each with instructions each cycle therefore achieving at best ~50% of both peaks if the code is a good mix of integer and FP calculations.

 

[Panajev2001a]

No N64 ever did any where near 100MFlops, the CPU took 5 cycle to do an fp multiply (you work it out).

No pipelined FP ops ?

 

[gurgi]

Why would there be a section on a "2D Engine" if this thing has a N64-quality GPU? In that case 2D + 3D would both be handled similiarly (as they are on Playstation where "sprite" is just a special case of "triangle"). Then such things as "number of backgrounds" would be arbitrary - in fact that metric only makes sense if "Nitro" was to have an old-school scanline sprite engine instaed of a 3D GPU. That's very fishy.

Because you have 2 screens. One that display 2D all the time (the touchscreen) and one that will display either 2D or 3D? Just a guess.

 

[Guden Oden]

Is the R4300i single issue ( non superscalar ) ?

Yes; it's a scalar (single-issue) CPU...

It was compared to pentium chips back when the N64 was still about to be released, but in reality the chip is more a 486-class processor.

 

[nobie]

Why would there be a section on a "2D Engine" if this thing has a N64-quality GPU? In that case 2D + 3D would both be handled similiarly (as they are on Playstation where "sprite" is just a special case of "triangle"). Then such things as "number of backgrounds" would be arbitrary - in fact that metric only makes sense if "Nitro" was to have an old-school scanline sprite engine instaed of a 3D GPU. That's very fishy.

Because you have 2 screens. One that display 2D all the time (the touchscreen) and one that will display either 2D or 3D? Just a guess.

I doubt there is a N64 style GPU at all, 3d is probably still done in software. It's probably more like a Saturn than an N64. Actually I'm thinking an SNES with a SuperFX cart (two CPUs, primitive 3d).

 

[gurgi]

I wasn't making cpu comparisons, but guessing why there are 2D and 3D figures.. because you will need both at the same time.

 

[cthellis42]

The chances of GBA compatibility is pretty good then. Its only upto Nintendo

From a technical standpoint, it's always been seen as a substantial possibility. Comments like this, however-- Nintendo can and will still change the hardware up to the system's release, and the games will and "MUST" be different than on other consoles or portables.--make me stick to my original expectation of them specifically NOT doing so (at least from launch) so as to not confuse the DS with their other projects, and not affect development of what they hope to be notably different gaming experiences from the device.

They could safely maintain a way to play GBA games on the DS (say a cartridge adaptor) and release it when they feel the time is right (say, when they're wanting to phase the GBA out, or feel the DS has established its uniqueness enough and want to add to its sales).