Showing posts with label PICA200. Show all posts
Showing posts with label PICA200. Show all posts

Friday, 24 September 2010

Tech Report: Nintendo 3DS Hardware Analysis

We first took a look at how powerful we thought the 3DS might be right here, and then again here, just after we learned which GPU would be powering the system. Now it’s time to do this once again, as a few days ago IGN appeared to accurately reveal the complete 3DS spec sheet, with information encompassing everything from CPU type and final GPU clock speed, to the amount of memory on board, both for system and graphics use. In short, the complete picture has been unravelled right before our eyes.


The full specs list for the 3DS is as follows: the machine is powered by two ARM11 CPUs running at 266MHz, and a DMP PICA200 GPU clocked at 133MHz. It features 4MB of VRAM dedicated to graphics (textures, framebuffer, effects? That’s not clear yet), 64MBs of RAM, and 1.5GBs of flash memory for storage.

Looking at the above, we can see that the 3DS appears initially to be rather underpowered. The GPU speed is incredibly low for a modern handheld device, and the ARM11 CPU was last featured in the original iPhone and iPod touch, and certainly more than a fair bit weaker than the A4 Cortex powering the new iPhone 4. However, when looking closer at the hardware itself, the resolution it runs at, and just what graphical features will be running, and how they will be implemented, it is also clear that the hardware isn’t quite as stillborn as you might expect.

Current game demos like Resident Evil Revelations, and Metal Gear Solid 3 both showcase the machines strong graphical capabilities despite the on paper limitations. And it is also important to point out that Nintendo’s hardware, unlike that of the iPhone and other multimedia / general handheld devices, the 3DS isn’t likely to feature a performance sapping OS powering it, or a restrictive high-level API limiting what you can do graphically. Nope, it’s almost certain that with the 3DS it will be possible for developers to code directly to metal, thus ensuring that they get ever last drop of juice from what the hardware is capable of.



Taking into account the small screen size, and small screen resolution itself (800x240), then you find that the system’s overall performance is perfectly suited to this type of environment. There’s no point for example, in rendering dozens of millions of textured, layered, and complexly shaded polygons per-second on a small screen in which at such a low resolution - most of that will almost certainly go to waste. Instead, like we have said before Nintendo seems to have taken a balanced, economical approach to their next-gen handheld hardware. And this looks to be the right choice. Cost/performance wise, it looks set to get the job done comfortably, and when looking at the individual make up of the system’s internals we can see why.

The CPU for example, an ARM11 running at 266MHz, is unlikely to be doing any complex physics calculations, or highly advanced AI routines – these aren’t really needed for small doses of on the go gaming, so appears to be low spec, but entirely adequate for the task in hand. Of course we can expect basic physics, and the illusion of advanced AI with the chip – seeing as it is rated roughly in line with an Intel 486 CPU, then scripted AI events, and arcade-like physics are more than possible, and satisfactory.

Looking at what was achieved on the original iPhone, and the fact that developers were still hindered by Apple’s domineering software API, then you can easily expect a substantial improvement when coding direct to metal, or much closer with a less restrictive development environment. Better collision routines, AI etc. All that is possible when taking into account the chip in context of how the 3DS works in comparison.

The decision to downclock the GPU is a rather interesting factor, not least of all because the standard PICA 200 running at 200MHz is very low spec by today’s standard – trailing way behind the iPhone 4’s SGX535, but also because it’s unlikely to be that much less cost effective. Instead, like in our original assumptions, we assume that this downgrade was done in order to preserve battery life, whilst also providing a small, but altogether beneficial decrease in overall system cost.

Even with GPU’s downclocking to 133MHz, it still packs plenty of punch. The original PICA-200 running at 200MHz can push around a maximum of around 15.3 million polygons per-second in a best case scenario, although that is unlikely to be in a real-world game environment (30 or 60fps with full effects etc).


In the 3DS, where the clock speed has been lowered to 133MHz we can expect a further drop in performance. From what we can see with current game demos, is that the systems peak polygon performance (on first-gen software at least) looks to be around the 3 to 6 million mark per-second – just over that of the PSP, and equalling the mid-range table of what the PS2 can do. Of course this is assuming optimised conditions, seeing as none of the software looks like it pushing anything more than around 4, maybe five million polys per-second.

However, such low geometry counts seldom makes a big difference these days, especially where advanced shaders, and multiple texture layers are concerned. And this is where the 3DS shows us its trump card. With the addition of advanced fixed-function effects which simulate the use of programmable shaders, along with actual vertex shader capabilities, Nintendo’s handheld can do a lot more with less, polygon wise, thus negating what can be seen as a lack of overall polygon pushing power. Also on such a small screen, huge amounts of geometry is always going to be less beneficial than a string of useful visual effects.


In terms of memory, the system is pretty much on par with the PSP. The 3DS has 64MB of main memory, and 4MB of video RAM - basically the same as the PSP Slim & Lite (bar VRAM in which the PSP S&L has 8MB). Initially, the inclusion of only 64MB of memory for the overall system to use may seem limiting. However, when you consider that the 3DS is a cart-based system, and that large amounts of data can be streamed in real-time from the format, then 64MB appears to be a suitable amount given what’s expected of it.

The same could also be said of the system’s 4MB of video RAM. Although it does seem rather limiting at first - it’s not yet known whether it is simply being used as framebuffer memory, or to hold the entire rendered scene, complete with textures and fixed-function texture layers - it should be enough for most games given the overall make up of the system's architecture. Determining its impact on performance though, is somewhat guesswork at this point.

Saying that, assuming Nintendo has included an efficient texture compression system then 4MB should be more than enough to fit in both the framebuffer and graphics data as an all-in-one solution. At the 800x240 resolution games are rendering at, you’re not really going to need that much more space for decent image quality anyways.

Obviously we don’t know the bandwidth numbers for the system’s graphics memory, although current game demos clearly demonstrate performance beyond that of the PSP, and the PS2 with regards to visual effects. And that’s with pushing around a lot more through the graphics pipeline. The standard PICA-200 GPU running at 200MHz has a pixel fill-rate of around 800 million pixels per-second (more than the GCN but less than XB and Wii), so we can comfortably say that the downclocked 3DS revision features noticeably less that. Although by how much, we can’t really say.

Surprisingly, when looking at the raw numbers of the 3DS’s specifications, you can actually see that the machine isn’t all that much more powerful that Sony’s PSP, with the amount of memory being the same, and geometry counts being very similar, albeit a little closer to the low end, mid-range of the PS2. What gives the 3DS its visual edge it seems, is simply down to its GPU’s capacity for rendering loads of advanced fixed-function effects on screen in lieu of having proper pixel shaders. Per-pixel lighting is supported, as is bump-mapping, specular and diffuse reflections, refraction mapping, procedural texturing and soft shadowing.

All of these add serious clout to the final images the 3DS produces in its games, and is exactly why the likes of Resident Evil Revelations and Metal Gear Solid 3 looks so good. The former looking closer to current 360 and PS3 games than most titles on the original Xbox.

Lastly, the system also features 1.5GBs of flash memory, used primarily for user-based storage. We can expect this space to be occupied by downloadable content, and various music and media files the user has transferred onto the console. Interestingly, it appears that the system actually features a 2GB flash memory chip inside, leaving 512MB solely in the hands of the OS. It is likely that this will be used to upgrade the machine’s firmware further on down the line, adding new functionality to the unit and who knows what else.


With the final specifications of the 3DS revealed (minus the odd bit of info here and there) it is clear that the system is, at first glance, not blinding more powerful than the PSP as it originally appeared. Much of what makes the 3DS games graphically so impressive comes from cleaver implementation of layered texture effects, and some impressive texture compression. Obviously, stuff like total system bandwidth is still up in the air. Although we can see that Nintendo's machine is working smarter, rather than harder.

However, this just might be enough. From what we’ve seen of the software, the machine has no problems in overshadowing DC and PS2 games, even bettering some Wii and Xbox 1 titles, so the lacking nature of the machine’s raw specifications are certainly not the be all and end all of the story.

Like with the N64, GCN, NDS, Wii, and pretty much every games console they’ve ever done, Nintendo have always been clever in selecting cost-effective, but capable performing parts, ones which get the job done without needing as much raw grunt as its competitors. And this is exactly the case here with the 3DS. They could have gone with NVIDA’s Tegra 2 solution (and evidence points to the fact that they originally were going to), however, for what is likely to be either cost or power efficiency issues, decidedly to switch to the DMP PICA-200 chip instead.

The decision, however silly it might seem in the face of vastly superior smartphone tech, and the rumoured PSP2, makes sense when you consider that the main draw of their system is it’s ability of deliver a solid 3D experience without the need for the user to wear glasses, and at what is likely to be at a reasonable price. The fact that games for the system currently impress, despite paper limitations, is just another sign that the company has done the right thing, especially given the circumstances of the ever-increasing cost of having cutting edge hardware in the home.

Balancing impressive graphics hardware and a low entry price with mass-market adoption is usually not an easy task. But Nintendo has shown time and time again that it definitely knows what its doing in this sector. And the 3DS looks like being another shining example of just that.

Tuesday, 22 June 2010

Nintendo 3DS GPU Revealed

Yesterday Japanese firm DMP revealed the graphics processor contained within the Nintendo 3DS ending speculation as to where the GPU would come from, and how powerful it really is.

A few days ago we assessed the capabilities of Nintendo’s new handheld based on seeing a handful of high-performance games and comparing them to titles on other platforms. It was a rough guestimate on how powerful we thought the machine to be, with a potential re-assessment upon having concrete new information. That re-assessment this is not, instead what follows is a look at the actual GPU that is powering the hardware and how the specs released ties into what we’ve seen of the 3DS’s capabilities so far.


First things first. The GPU powering the 3DS is the DMP PICA200 graphics core, a 2006 chip designed solely for portable device applications – everything from mobile phones to games consoles is mentioned in the specs document – and which actually packs quite a reasonable punch for cheap and efficient graphics rendering in a handheld device. With the design of the chip being complete in 2005 and released into market the following year, it isn’t in the same league as the GPU powering the iPhone, although it does fit squarely in between the GameCube and the Xbox in terms of overall ability.

According to DMP the chip is rated at 15.3 million polygons per-second (pps), with a pixel fill-rate of 800 million pixels per-second (more than the GCN but less than XB and Wii), all running at relatively fast 200mhz. Interestingly the numbers here are actually real-world figures in terms of the chip being used as a GPU solution in custom hardware. However, the demos and games shown for the 3DS don’t add up visually with the numbers given above, with the most complex titles pushing no more than 4, maybe 5 million polygons per-second at best.

So how can this be explained? Could it simply be a case of early development hardware, or a lack of optimisation with first-generation games? Well, this is particularly unlikely seeing as some of the software shown at Nintendo’s press event was highly polished and running at a brisk 60fps – not something un-optimised titles tend to do this early on in the hardware life cycle.

You could also argue then that the use of 3D, and having to render each frame twice could be having a considerable impact on the system’s graphics performance, if only were not for the fact that the 3DS renders one 800x240 image and splits the horizontal resolution down to 400 for each eye. At this low resolution, such a heavy performance hit isn’t very plausible seeing as you are basically rendering 800x240 as a total single screen resolution with 60fps equating to 60fps, and not 30fps as it would be for rendering for display using regular stereoscopic 3D images.

This resolution is hardly GPU busting compared to what the iPhone is doing – its basically little more than a expanded version of the Saturn or PSone’s low resolution mode.

Instead all signs point to Nintendo downgrading the chip in some way. The most likely scenario is the same one Sony took when launching the PSP, downcloking the GPU in order to save on battery life at the expense on overall performance. This lowering of the clock speed would indeed have the undesired effect of lower polygon throughput, thus resulting in the lower geometry counts we are seeing in the first batch of 3DS games.

The other area is memory. Even if the chip is capable of delivering somewhere in the region of 15.3 million polys per-second, the 3DS might not have enough graphics RAM in order to hold more than 4-6 million textured, lit and fully shaded polygons on screen, in which case the full power of the GPU is largely irrelevant with the exception of the extra grunt being used to obtain a stable 60fps in ‘most case’ scenarios.

Either way, without actually seeing the entire specification set of the machine we can’t really make any more assessments on how powerful it is, or how much of the above GPU performance is obtainable in real-world scenarios in 3DS games.

More interesting though, is the GPU’s lack of any programmable pixel shaders. We estimated that the 3DS might in fact have pixel and vertex shaders in our initial assessment of its capabilities last week due to seeing what looked blatantly like shader-based effects being visible. As it turns out this is only half the story.

The 3DS is basically an Open OpenGL ES 1.1 compatible chip with some customised fixed-function effects and vertex shading capabilities, but no pixel shader support of any kind. It has the ability to perform advanced effects such as per-pixel lighting, refraction mapping, procedural texturing, soft shadows, and gaseous object rendering. All of which are carried out using fixed hardware routines, and not as hinted at by Nintendo, shaders themselves. However, like we mentioned in our original article many of the effects created through the use of shaders can also be duplicated using fixed-function hardware. And in this case DMP have bumped things up considerably, with more advanced extensions than most previous fixed-function T&L GPU’s tended to have.

The fact that many, myself included, saw evidence of pixel shaders at work proves that using a cheaper, older fixed-function design was the correct way to go. Many of the custom extensions are much more powerful than the ones available on either the Wii or the GCN, and in most cases perfectly replicate the look of programmable pixel effects.

For such a low-resolution screen, and the kind of handheld Nintendo makes, the above solution seems like a good fit. For one we can expect the 3DS to be much cheaper than competing platforms with similar 3D LCD screen technology, and at the same time still have some pretty impressive visuals for the price.

Once again it has to be said that Nintendo definitely have been very thoughtful, and indeed economical in its part selection for the 3DS, using old and outdated hardware to good effect. It’s something that seems to have worked for them in the past with both the NDS and the Wii, and will no doubt work for them again with the 3DS as well.