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
Camera Analysis
The 2X has a 1.3 MP front facing camera and 8 MP rear camera, unfortunately I haven’t been able to determine the camera source, but pixels on the rear camera are 1.4 µm square, and 1.75 µm on the front facing camera. That pixel size would make the 2X’s CMOS sensor most likely 1/3.2” in size.
The LG Optimus 2X's 8 MP rear facing camera
LG’s camera app is familiar territory coming from other LG Android phones. We’ve still got the LG Optimus One, which has almost the exact same layout and design camera application. Honestly, I think LG’s got the best menus I’ve seen yet for a smartphone. There are image size settings for 8 MP (3264x2488), 5 MP, 3 MP, 2 MP, 1 MP, VGA and QVGA, three compression settings (Super Fine, Fine, and Normal), some optional focus controls (Auto, Macro, Face Tracking, and Manual Focus), ISO (Auto, 100, 200, 400, 800), scene modes, effects, ability to disable the shutter sound, and the shot mode. There’s the option of recording images either on the “internal SD card” (which is really that eMMC) or an external SD card if you’ve got one inserted. I noticed that writing to internal storage enabled a bit faster cycling between images compared to my SD card. There's a full overview of all the camera and video capture settings in the gallery below.
Shot mode is interesting because under it is a setting called “continuous shot” which enables 6 photos to be captured in rapid succession, which you can see in action in our overview video. When switching to that mode, image size drops from 8 MP to a maximum of 2 MP, and a couple of other options grey out. Tapping the capture button immediately takes those 6 images in rapid-fire succession and saves them. It’s cool that you can take a bunch of images quickly, but what would be more useful is being able to mash the capture button in the normal shooting mode and capture as quickly as you would on a decent DSLR. That still isn’t possible, but we’re clearly getting there. NVIDIA advertises that its image signal processor (ISP) is capable of doing 12 MP at 11 FPS, and JPEG encoding at 80 MP/s, which would mean that (negating integration time on the camera sensor) 10 FPS shooting should be possible. That’s obviously a bit ambitious, and isn’t what we see here—maybe someday though.
The OSD LG has put together for the camera is again probably the best I’ve seen on any Android—heck smartphone in general—yet. Icons rotate between landscape and portrait orientation modes, up at the top are shots remaining, image size, and other iconography for modes that have been set elsewhere in settings. Tapping or waiting a few seconds eliminates everything save the live preview to give a less cluttered view for image composure. The 2X lacks tap to focus and expose, instead it’s always center-weighted. There’s also no dedicated capture button on the 2X, so the on-screen button is the only option.
Image quality from photos taken with the rear facing camera is actually pretty good. There’s a lot of spatial detail in our test images with surprisingly little noise. I’d say that the 2X actually takes some of the best 8 MP smartphone images I’ve seen to date. The problem, however, is saturation. Colors are almost universally under-saturated by default—compare almost any of the shots we took at our bench location to other devices, and it’s readily apparent. It’s still outclassed by phones like the Nokia N8, but not bad.
With the lights off, the 2X runs autofocus with the LED lit up, which is awesome. Unfortunately, the flash exposure over illuminates our test scene and creates a very overexposed image. Otherwise the LED flash is nice and powerful, yet more proof that having two isn’t necessarily better.
Interestingly enough the other strong suit of the 2X is that the preview image is one of the most fluid and high framerate we’ve come across. In situations with adequate light, the rear facing camera preview is easily higher framerate than the iPhone 4. Oddly enough, the front sensor preview framerate is quite low unless you’re imaging something extremely well-lit. The limitation on the front-facing camera framerate is one of integration time on the sensor rather than ISP bandwidth, however.
Tapping the top left button switches to the front facing camera. What’s odd however is that the front facing camera is actually rotated 90 degrees. That’s not to say that the image is rotated 90 degrees, but rather that the longer side of the sensor is parallel to the shorter axis of the phone. The result is that there are black bars on both sides of the preview. It’s as if the sensor was aligned with the intention of being used with the phone primarily in portrait—instead of orienting the sensor to match the aspect ratio of the phone. It’s just an odd choice considering all the other smartphones we’ve looked at thus far are the other way around.
The 1.3 MP front facing camera can capture at 1280x960, VGA, and QVGA resolution. Quality isn’t too good—there’s noticeable lack of detail and blurring in our test image. It’s likely more than enough quality for a video chat that’s going to crop and decimate image size to a much smaller size. The 2X also mirrors images horizontally on the front facing camera.
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