Nintendo DS 3d performance

[Jaybird376]

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).

Actually, that makes a great deal of sense if the successor to the GBA is not in fact backwards compatible. The DS would then make sure that old gameboy games could still be played, and expand its library when the GBA 2 makes its appearance. While the successor to the GBA can start off on a new track. Potentially being backwards compatible with GCN games. I guess E3 will tell a lot, they are going to be showing the DS off aren't they?

 

[Sonic]

Something I'm not understanding here is the 4 million vertices/s comment and the 120K polys/s comment. Can someone please tell me if those 4 million vertices/s are going to waste if the machine can only display a limited number of polgyons? It's confusing to me because I'm thinking 4 million vertices per second should be good for at least 1 million polgyons per second, not 120 thousand polygons per second.

 

[Deadmeat]

...

Can someone please tell me if those 4 million vertices/s are going to waste if the machine can only display a limited number of polgyons?

Not if you do HSR before sending vertices to the GPU... HSR was not possible on 3rd gen consoles due to lack of CPU power. Now that the CPU-GPU power difference is sufficiently large enough, CPU side HSR can be used.

So even though an N64 class GPU is used, the polycount can be increased 2~3 fold over N64.

 

[Crazyace]

or maybe

The 4M verts/second may only occur if the CPU spends 100% of the time transforming verts ( with gameplay running on the slower cpu )
If lighting etc is also applied, the vert count will probally drop.
(This will probally hold with or without the arm9 vfpu - as there's a fast integer fmac )

transform is normally 9 fmacs, plus load/stores and divide ( There's no need for 4x4 transform for simple 3D ), and 3 fmuls for perspective - the bottleneck would be the 17 cycle divide ( 67/4 is close to 17! )

 

[Panajev2001a]

Of course if you cut W you will have some help, but it gets a little bit more complicated doing perspective correction, doesn't it ?

http://www.lysator.liu.se/~mikaelk/doc/perspectivetexture/

Do you think that they are doing all in software on the ARM9 CPU ? Is that why suposely bi-linear filtering and Z-buffering would bring us from 4 MVertices/s down to 120k vertices/s ?

 

[Clashman]

I find it hard to believe that an ARM 9 CPU could achieve those performance numbers at all on it's own. Maybe there is dedicated 3D Hardware, and there is the option to use one of the two CPU's as a dedicated TnL engine whilst the other carries out general purpose and AI tasks? Therefore, you could end up with widely different performance depending on if/how/which CPU's were assisting the graphics system? I'm probably wrong on that, but it's an idea.

 

[Guden Oden]

Software-based 3D rendering is inefficient both from a power-useage and speed perspective.

I doubt the DS does not have a hardware 3D renderer, silicon is so cheap these days it wouldn't be much of a point NOT including one.

 

[nobie]

Software-based 3D rendering is inefficient both from a power-useage and speed perspective.

If Nintendo included two CPUs and a GPU, power comsumption would go way up. Besides I don't think DS is supposed to be a machine for 3d, that will be GBA2.

 

[Evil_Cloud]

Just something in between: the document is completly fake.

 

[MfA]

If the CPUs have to do less work you can have them consume less power, that is hardly a valid arguement against a 3D chip. It better be meant to run mostly 2D games, otherwise it is just a bad design.

 

[Megadrive1988]

I expect the next generation Gameboy to be about as close to Gamecube as Nintendo DS is to Nintendo 64, in 3D.

 

[Guden Oden]

If Nintendo included two CPUs and a GPU, power comsumption would go way up.

Those two CPUs won't draw much power, and the 3D hardware wouldn't draw much power either. It's not exactly going to be a Radeon 9800XT they'll stick in that thing... If you look at the GPUs available for portable use now, they draw a couple hundred milliwatts.

Besides I don't think DS is supposed to be a machine for 3d, that will be GBA2.

I'd think it extremely unlikely for Nintendo to release yet another GBA, only real difference being two screens, wifi and possibly better sound. It'll do 3D I think, though just not on PSP level.

 

[Crazyace]

Hi Panajev,

I'm assuming some kind of 3D rasteriser is present. - but the transform figure matches what you might expect from the arm9 vfpu at that clock speed.

 

[Panajev2001a]

Hi Panajev,

I'm assuming some kind of 3D rasteriser is present. - but the transform figure matches what you might expect from the arm9 vfpu at that clock speed.

Hi Crazyace, always nice to hear from you ( you post so few and far in between, you must be wicked busy ) .

That VFPU seems a nice piece of Hardware, I agree.

How about using the double clocked GBA Hardware to do Texturing and Rasterization ?

Uhm, I wonder then what kind of rasterizer they have if they are not using the ARM7 chip to take such place.

 

[Clashman]

Maybe something like this???
http://www.ati.com/products/imageon2300/features.html

Anyone have any clue what kind of performance this thing gets? I haven't been able to find any indications. It does support 18 bit color, though.

 

[Edge]

> "At 67 MHz this would be close to 87.1 MFLOPS which is not bad."

No it would not, as that single cycle MAC on the ARM946E-S is not a floating point MAC, but an integer MAC. There is no floating point unit on the ARM946E-S!

There is a floating point unit for the ARM946E-S, but it's a seperate chip!

http://www.arm.com/products/CPUs/ARM946ES.html

 

[Panajev2001a]

> "At 67 MHz this would be close to 87.1 MFLOPS which is not bad."

No it would not, as that single cycle MAC on the ARM946E-S is not a floating point MAC, but an integer MAC. There is no floating point unit on the ARM946E-S!

There is a floating point unit for the ARM946E-S, but it's a seperate chip!

http://www.arm.com/products/CPUs/ARM946ES.html

Thanks, we have been talking about the "optional" and embeddable VFP9-S co-processor for almost the whole thread .

 

[Edge]

> "VFP9-S"

I see. I missed that at ARM's site. I re-read the thread, and from what I understand, the speculation is that it has this, because of the 4 million vertices spec?

Probably repeating things here, but my guess would be the 4 million vertices/sec rate, is what the transformation engine (VFP9-S?) can do, if it was doing nothing but that, but the 120K polygon rate, is what the rendering engine can do?

120K polygons/sec is not very much, as at 30 fps, that's a lowly 4000 polygons in the scene!

 

[Magnum PI]

why don't they use powervr mbx technology ? it's available with ARM processors...

 

[Guden Oden]

We don't know what they use... It might be MBX, it might be ATi's Acceleon or whatever their crap's called, etc.

Hopefully we won't have to wait until E3 in (late, unfortunately) may before they tell us what hardware is in that thing.