Nvidia Tegra

Perf/watt isn't a metric you'll find readily available for SoCs unless you're prepared to measure it yourself. Raw graphics or CPU performance wise, it should be easy enough to line them up.
I'm mainly interested in real world performance. If you simply look at the specs (as supplied by the manufacturer and for as far as I know them) of the TI OMAP3 chipset as used in the Motorola Droid and the Qualcomm Snapdragon chipset as used in the Nexus One then you'd conclude that the GPU in the Snapdragon can process more triangles per second while the OMAP3 has a higher fill rate. Then I'd say that, for a smartphone, the Snapdragon will have higher performance.

The problem is though, that I've read a couple of comments claiming that the GPU in the Motorola Droid is faster and more capable than what's in the Nexus One and some of those comments come from people who've actually build a game engine for Android. This makes me wonder, how do the current higher end chipset really compare in real world workloads?
 
OK, guess it makes sense that SOC performance would be proprietary but you would think there are some PR numbers being thrown around to try to win business?

Or failing that we have to compare performance on finished products.
 
OK, guess it makes sense that SOC performance would be proprietary but you would think there are some PR numbers being thrown around to try to win business?
You would think so, but last time I tried to get some SoC power/performance numbers I was conveniently ignored. I've had way better success with obtaining such from pc chipset vendors. *shrug*

Or failing that we have to compare performance on finished products.
That's the only viable course of action, it seems. Preferably with devkits, where one has better control over what power goes in and what modules are online.
 
You have things like GLBenchmark, where the results are publicly available on shipping hardware. It depends on the measurements you're interested in, and obviously there's no concept of perf/watt in their tests, but it's something at least.

I agree that there's much less transparency in the embedded 3D market though, and generally most data is a closely guarded secret.
 
Perf/watt isn't a metric you'll find readily available for SoCs unless you're prepared to measure it yourself. Raw graphics or CPU performance wise, it should be easy enough to line them up.

I point you to my posting over on the "overclocked OMAP3" thread, that relates to a power usage spreadsheet from TI, giving some useful info for overall chip and sub-section power usage for omap3 processors.

States that SGX running @192Mhz @70% utilisation, draws around 75mWatts.

http://forum.beyond3d.com/showpost.php?p=1458135&postcount=10

Now all we need is a definition for utilisation :)
 
I point you to my posting over on the "overclocked OMAP3" thread, that relates to a power usage spreadsheet from TI, giving some useful info for overall chip and sub-section power usage for omap3 processors.

States that SGX running @192Mhz @70% utilisation, draws around 75mWatts.

http://forum.beyond3d.com/showpost.php?p=1458135&postcount=10

Now all we need is a definition for utilisation :)

Even if you scale that up by 1 / 0.7 for a number given in absolute pessimism you still get a fantastic figure, IMO.

Another number is the 0.5-1mW/MHz DMP gave for PICA200. Will be interesting to see how whatever is in 3DS ends up comparing to SGX530 in several ways, including power consumption.
 
Thanks for the tip fehu, I hadn't even heard of Eagle until now, not that surprising given how little ARM appears to have said about it.

I don't to dismiss everything said in the SA article entirely but it's a little hard to take Charlie seriously when he doesn't really cite sources, makes a few incredibly dubious claims, and seems to have something against nVidia (and to a lesser but non-imaginary extent ARM).

This statement is particularly culpable, bordering on offensive:

"On the technical side, the problem is simple, speed. ARM A9 CPUs are great for phone level applications, and can reach into the current tablet space, but hit a glass ceiling there. If Eagle doubles the performance per MHz and doubles performance per watt, it will basically be on par with the low end of the Atom-class CPUs, and woefully behind the Nano/Bobcat level of performance."

The claim that per-MHz Cortex-A9 offers half the performance per MHz and half the perf/watt (ie, given first claim, same watt/MHz, which is also false) is incredible and suggests a severe lack of understanding as to how at least one of the architectures works.

Then the very following sentence:

"On top of that, you strap a translation engine to change the x86 code to ARM instructions, and you lose more speed, add latency, and drop performance."

Which is an attempt to inundate a point by saying the same thing three times.

Comparing this to Transmeta's CPUs seems to be missing the point to me. Crusoe/Efficeon failed because they were for all intents and purposes inferior x86 CPUs, and the power advantage wasn't enough to win in the markets that mattered, notebooks, which at the time had other components which overshadowed the CPU power saving.

ARM is already a proven and highly successful architecture, and with its foray into tablets it's not unforeseeable that ARM can take share in netbooks too. It's highly unlikely that nVidia would push forward an ARM product with x86 compatibility boosting features in hardware but lock it down to x86 execution only via protected code like Transmeta's CPUs were - that'd be insane.

If nVidia is incorporating x86 support it's not in an attempt to beat Intel at their own game, because ARM does a good enough job for the markets it (and nVidia) target. It'd be to give it a competitive advantage against other ARM offerings.

I also think Charlie is overestimating the amount of silicon and especially power consumption needed to aid in some kind of useful translation acceleration. A few very simple techniques can go a tremendous way in enhancing recompilation. Transmeta's CPUs provided a lot of hardware infrastructure because they were doing support for system level emulators. nVidia wouldn't benefit from this, and would actually be foolish to push it, because they don't want people to run Windows - they want people to run environments which can fully leverage the great wealth of say, Android code already out there, while being able to run Windows programs too (ie, qemu on WINE). With some intelligently picked acceleration features exposed in the ISA performance can be brought to a decent level, probably to least 50% native (see Godson 3 for example, which claims 70% with quite modest enhancements - much more could be done). Things can be taken to levels where say, 2GHz Eagles could beat 1.6GHz Atoms. Of course, I say this while knowing nothing about the micro-architectural improvements Eagle makes. I'm just assuming it's not nothing, or something largely throw-away for this like a move to 64-bit.

The market has proven that 1.6GHz Atoms are very successful, and Intel apparently thinks there's also market demand at half the speed. x86 has added value, even at under the speed of current Atoms. You could argue that even pure software emulation is desirable, but I think part of the problem is there has been too little attention given to x86 on high end ARM (especially from corporations). If nVidia pushes x86 features in hardware they'll spark interest in this, especially if they develop their own software to this end, which I fully expect. There'll also be a marketing advantage just by claiming anything to do with x86.

Anyway, this is all assuming nVidia is really going for this. But if they are there's no point wondering how they'll pull the chip off, when IMO the translation would only be one aspect of it and it not being stellar wouldn't necessarily tank the product.

EDIT: However, nVidia can't extend the ARM ISA to include x86 emulation without getting an architectural license and developing their own CPU (ie, no Eagle). It might be possible that ARM is collaborating with them to allow them to do an x86 acceleration coprocessor, but I think that for it to really be effective it has to share the same register file. If Eagle is really an architecture revision then it's possible that ARM themselves are offering variants with enhancements that lend themselves well to emulation. Before anyone says it, these would hardly necessarily be infringing upon x86 - some of the most useful accelerations for emulation are not even remotely x86 specific.
 
Last edited by a moderator:

Either LG just flipped processors in the last month, or the Press Releases are refering to members of the optimus family instead of the entire family, because only 1 month earlier they stated Optimus One would use Omap3630, that they would be a low level Optimus "chic", and also an Optimus tablet.

http://www.boygeniusreport.com/2010/07/05/lg-android-tablet/

Edit...Actually, when I look at it again, the PR DOESN'T mention Omap, its the BGR piece that states OMAP as being a fact.
 
Either LG just flipped processors in the last month, or the Press Releases are refering to members of the optimus family instead of the entire family, because only 1 month earlier they stated Optimus One would use Omap3630, that they would be a low level Optimus "chic", and also an Optimus tablet.
It obviously relates to members rather than the entire family; they announced those two devices back then, and they expect to announce 10 before the end of the year. It'd be quite incredible if all of them used the same chips despite being aimed at different market segments! The beauty of Android, in a way, is that you can have a top-to-bottom range based on the same SW. It's fairly obvious that both Tegra2 and OMAP3 will be used in more than one Android device at LG, although maybe not this year.
 

Thanks, that review kinda sums up what I was getting at. Lots of focus on interface, form factor etc and yet:

While the SGX 540 could be responsible for the Epic 4G’s smoother than expected UI, it’s mostly a waste of hardware today. Clearly you don’t need this powerful of a GPU to make scrolling through menus smooth.
 
While the SGX 540 could be responsible for the Epic 4G’s smoother than expected UI, it’s mostly a waste of hardware today. Clearly you don’t need this powerful of a GPU to make scrolling through menus smooth.
Whether a block of hardware is a waste or not should be the result of an equation like how often the block gets utilized times die area consumed and what not. Does the author know how big the 540 really is or how often it actually gets used in real-time? I don't personally; which makes me think that his conclusion has been grasped out of thin air.

Under the same reasoning we won't need any dual-core CPUs in smart-phones either or any other hw advancement in the future. I wouldn't suggest that neither die-area nor in extension power consumption poses a problem on SoCs like that. There's a lot "worse" out there for those latter two out there ya know ;)
 
Dual-core A9 is actually quite cheap, the 1MB L2 is more expensive. In Tegra2's case, the main costs are probably the GPU and the video encoder, as well as the peripheral section if you take it as a whole rather than single blocks (i.e. HDMI, 1xUSB PHY, 2xUSB ULPI, 2xMIPI-CSI for bandwidth to camera sensor for 1080p, 32-bit of both LPDDR2 and DDR2 seemingly separate for dubious engineering or power reasons although I could be wrong, etc.)

It's nice to see LG confirm that Tegra2 will be used in a series of phones rather than a single one - which reminds me I still don't know if Tegra2's smaller brother ever taped-out or not.
 
Back
Top