LG Optimus 2X & NVIDIA Tegra 2 Review: The First Dual-Core Smartphone
by Brian Klug & Anand Lal Shimpi on February 7, 2011 3:53 AM EST- Posted in
- Smartphones
- Tegra 2
- LG
- Optimus 2X
- Mobile
- NVIDIA
The 2X we received came in packaging that obviously isn't final, but that isn't what's important at this point. Included is a microHDMI type D to full size HDMI type A cable about 6 feet in length, USB power adapter with type C AC plug, microUSB cable, and of course the smartphone itself with included battery. There's no microSD card provided, but that's admittedly somewhat mitigated by the presence of 8 GB of internal storage which looks just like an SD card to Android.
Hardware feel is just how we left it at CES. The 2X's back is a brown soft touch material with a metallic strip running along the center. The "with Google" text is engraved into the strip, which has a gentle slope leading to the camera bulge.
The camera area is raised a few mm above the rest of the device—it's reminiscent of the Droid X's camera bulge but not nearly as dramatic. The 2X's battery cover is removed by jamming your thumb in a slot at the bottom and tearing it off—plastic snaps around the edge hold it in place.
The 2X puts the battery cover in-between the last vertex of the camera and object space, one of the things we've complained about the Nexus One and other devices doing which basically provides an additional two more surfaces for fingerprints and grime to happen and add glare. The odd part is that the LED flash port on the battery cover is literally just a hole—this is a perfect place for dirt and pocket lint to get under and inside the battery cover.
With the battery cover off you can see the 2X's 5.6 watt-hour battery, SIM slot, and microSD card slot. The microSD position means that you can take the SD card out with the device turned on, and the slot is of the click-to-eject sort. There's no obvious port for a rear microphone, so there's likely no dual-microphone noise rejection for calling on the 2X.
The 2X is ringed by a silvery metallic plastic, in fact all of the 2X exterior is plastic. The right side of the 2X is home to the volume up and down buttons, which are discrete, clicky, and otherwise perfect.
At the bottom is the microUSB port, and two meshed ports which are reminiscent of the iPhone's design language. The left port is the microphone, right side is the speaker port.
Up top is the power and lock button, in-between is the microHDMI port for HDMI mirroring. There's a snap-off door held on by another piece of plastic which lets the door come off and swivel without totally detaching. To the right is the 1/8" headset jack. The rear of the jack is at a bit of an angle, so some of the connector shows through, but it's not a big deal and the jack works fine.
The front of the 2X is one continuous glass surface. The left and right sides of the display are curved gently in one axis, but nonetheless a noticeable amount. The majority of the display surface used for actual display and interaction is actually flat. Only at the extreme edges is there curvature. It's a bit reminiscent of the Dell Venue Pro, but nowhere near as extreme or pronounced.
The curvature, while attractive, has a downside. That downside is that the surface of the display is essentially defined by the two ridges formed right at the curvy parts—already vertical scratches have been accumulating right at those places. Obviously this is only a problem if you set the phone front-down.
The 2X's front facing camera is up at the top right. On the left, faintly visible are the two proximity sensor and ambient light sensors. At the top extreme is the main earpiece.
There are no status LEDs on the front of the device or tucked away under the speaker grille on the front like the EVO.
Unlike the Korean version, the P990 model has all capacitive buttons below the display. They're in the same order as the Galaxy S Fascinate, but a different order from everything else except other LG phones. They're all backlit, and there's no light leakage around the icons. There's a generous amount of space above and below the buttons, almost too much extra space. Either LG is leaving room for a carrier logo silkscreen, or else just making things easier for people with gigantic fingers.
Bottom to top: Nexus One, myTouch 4G, Galaxy S Fascinate, EVO 4G, iPhone 4, LG Optimus 2X
The 2X is dimensioned appropriately for the class of 4-inch screened displays it fits in. Thickness is just shy of 11 mm, which is essentially identical to the Nexus S we just reviewed. It's still thicker than the iPhone 4, but not dramatically so. The camera bulge is really what contributes to thickness—the vast majority of the 2X is a millimeter thinner. Weight is specced at 139 grams, we measured it at a slightly heavier 144 grams. It isn't unnervingly light like the Galaxy S series of phones (sans the Epic) were, but rather just right. In-hand feel is actually excellent—I found that the phone naturally sat in the hand so that my index finger rested on the curved ridge just below the camera, balance also was just fine in the palm.
The 2X's build is quite good, there's no flexing or creaking, no rattling when SMSes come in and the phone vibrates, either. It doesn't feel fragile, but it still lacks that hand-on-metal solidness that phones like the Nexus One misgive.
Facebook
Twitter
RSS
75 Comments
View All Comments
GoodRevrnd - Tuesday, February 8, 2011 - link
TV link would be awesome, but why would you need the phone to bridge the TV and network??aegisofrime - Monday, February 7, 2011 - link
May I suggest x264 encoding as a test of the CPU power? There's a version of x264 available for ARM chips, along with NEON optimizations. Should be interesting!Shadowmaster625 - Monday, February 7, 2011 - link
What is the point in having a high performance video processor when you cannot do the two things that actually make use of it? Those two things are: 1. Watch any movie in your collection without transcoding? (FAIL) 2. Play games. No actual buttons = FAIL. If you think otherwise then you dont actually play games. Just stick with facebook flash trash.TareX - Wednesday, February 9, 2011 - link
The only reason I'd pay for a dual core phone is smooth flash-enabled web browsing, not gaming.zorxd - Monday, February 7, 2011 - link
Stock Android has it too. There is also E for EDGE and G for GPRS.Exophase - Monday, February 7, 2011 - link
Hey Anand/Brian,There are some issues I've found with some information in this article:
1) You mention that Cortex-A8 is available in a multicore configuration. I'm pretty sure there's no such thing; you might be thinking of ARM11MPCore.
2) The floating point latencies table is just way off for NEON. You can find latencies here:
http://infocenter.arm.com/help/index.jsp?topic=/co...
It's the same in Cortex-A9. The table is a little hard to read; you have to look at the result and writeback stages to determine the latency (it's easier to read the A9 version). Here's the breakdown:
FADD/FSUB/FMUL: 5 cycles
FMAC: 9 cycles (note that this is because the result of the FMUL pipeline is then threaded through the FADD pipeline)
The table also implies Cortex-A9 adds divide and sqrt instructions to NEON. In actuality, both support reciprocal approximation instructions in SIMD and full versions in scalar. The approximation instructions have both initial approximation with ~9 bits of precision and Newton Rhapson step instructions. The step instructions function like FMACs and have similar latencies. This kind of begs the question of where the A9 NEON DIV and SQRT numbers came from.
The other issue I have with these numbers is that it only mentions latency and not throughput. The main issue is that the non-pipelined Cortex-A8 FPU has throughput almost as bad as its latency, while all of the other implementations have single cycle throughput for 2x 64-bit operations. Maybe throughput is what you mean by "minimum latency", however this would imply that Cortex-A9 VFP can't issue every cycle, which isn't the case.
3) It's obvious from the GLBenchmark 2.0 Pro screenshot that there are some serious color limitations from Tegra 2 (look at the woman's face). This is probably due to using 16-bit. IMG has a major advantage in this area since it renders at full 32-bit (or better) precision internally and can dither the result to 16-bit to the framebuffer, which looks surprisingly similar in quality to non-dithered 32-bit. This makes a 16-bit vs 16-bit framebuffer comparison between the two very unbalanced - it's far more fair to just do both at 32-bit, but it doesn't look like the benchmark has any option for it. Furthermore, Tegra 2 is limited to 16-bit (optionally non-linear) depth buffers, while IMG utilizes 32-bit floating point depth internally. This is always going to be a disadvantage for Tegra 2 and is definitely worth mentioning in any comparison.
Finally I feel like ranting a little bit about your use of the Android Linpack test. Anyone with a little common sense can tell that a native implementation of Linpack on these devices will yield several dozen times more than 40MFLOPS (should be closer to 1-4 FLOP/CPU cycle). What you see here is a blatant example of Dalvik's extreme inability to perform with floating point code that extends well beyond an inability to perform SIMD vectorization.
metafor - Monday, February 7, 2011 - link
According to the developer of Linpack on Android:http://www.greenecomputing.com/category/android/
It is mostly FP64 calculations done on Dalvik. While this may not be the fastest way to go about doing linear algebra, it is a fairly good representation of relative FP64 performance (which only exist in VFP).
And let's face it, few app developers are going to dig into Android's NDK and write NEON optimized code.
Exophase - Monday, February 7, 2011 - link
Then let's ask this instead: who really cares about FP64 performance on a smartphone? I'd also argue that it is not even a good representation of relative FP64 performance since that's being obscured so much by the quality of the JITed code. Hence why you see Scorpion and A9 perform a little over twice as fast as A8 (per-clock) instead of several times faster. VFP is still in-order on Cortex-A9, competent scheduling matters.Maybe a lot of developers won't write NEON code on Android, but where it's written it could very well matter. For one thing, in Android itself. And theoretically one day Dalvik could actually be generating NEON competently.. so some synthetic tests of NEON could be a good look at what could be.
metafor - Monday, February 7, 2011 - link
Well, few people really :)Linpack as it currently exists on Android probably doesn't tell very much at all. But if you're just going to slap together an FP heavy app (pocket scientific computing anyone?) and aren't a professional programmer, this likely represents the result you see.
I wouldn't mind seeing SpecFP ported natively to Android and running NEON. But alas, we'd need someone to roll up their sleeves and do that.
I did do a native compile of Linpack using gcc to test on my Evo, though. It's still not SIMD code, of course, but native results using VFP were around the 70-80MFLOPS mark. Of course, it's scheduling for the A8's FPU and not Scorpion's.
Anand Lal Shimpi - Monday, February 7, 2011 - link
Thanks for your comment :)1) You're very right, I was thinking about the ARM11 - fixed :)
2) Make that 2 for 2. You're right on the NEON values, I mistakenly grabbed the values from the cycles column and not the result column. The DIV/SQRT columns were also incorrect, I removed them from the article.
I mentioned the lack of pipelining in the A8 FPU earlier in the article but I reiterated it underneath the table to hammer the point home. I agree that the lack of pipelining is the major reason for the A8's poor FP performance.
3) Those screenshots were actually taken on IMG hardware. IMG has some pretty serious rendering issues running GLBenchmark 2.0.
4) I'm not happy with the current state of Android benchmarks - Linpack included. Right now we're simply including everything we can get our hands on, but over the next 24 months I think you'll see us narrow the list and introduce more benchmarks that are representative of real world performance as well as contribute to meaningful architecture analysis.
Take care,
Anand