HDMI Mirroring

One of Tegra 2’s most interesting features is support for multiple displays—HDMI 1.3 at 1080p mirroring is supported. The implementation on the 2X is how other Android phones with HDMI ports should have worked, you plug the HDMI cable in, and everything on the phone is instantly mirrored on the connected display. Android isn’t suddenly rendered at higher resolution, it’s just scaled up to whatever resolution of HDMI device you connect to, but that looks surprisingly good.

In portrait mode, there are black bars at the left and right, but rotate to landscape and the WVGA Android screen fills 1080P displays. WVGA (800x480) isn’t exactly 16:9, but it’s close, so there’s a little stretching in landscape but nothing noticeable.

The result is that you can use the 2X to play angry birds on a 55” TV without waiting for the console version, browse the web, give a PDF or PPT presentation, or do anything you’d do on the phone on a different screen. I put together a reasonably comprehensive video showing off HDMI mirroring.

There’s a tiny bit of input lag. In the video I shot showing off HDMI mirroring, it’s entirely possible some of that is just the result of my Onkyo TX-SR608 A/V receiver which seems to add a consistent 100ms of lag to almost everything, even in game mode. The supplied microHDMI cable is just long enough to stretch from the receiver to my couch, I could use a few more feet to be comfortable however.

You can also play videos over the HDMI connection, while doing so the 2X shows a "showing on second display" message:

HDMI mirroring works shockingly well, and sends all audio over HDMI. It’s a bit difficult to look at the TV and interact with the phone’s touchscreen, but not impossible. WebOS and others have drawn circles on the screen to show where fingers are. The tradeoff there is that it’s one more element to clutter display.

Video Playback

The big question is how well the X2 (or any Tegra 2 smartphone) could work as a mini-HTPC. NVIDIA advertises a big long list of codecs that Tegra 2 can decode:

LG’s own spec list (what's below is actually for the Korean version, but the video codec support is the same) is much closer to the truth for the X2 because of Android’s player framework and other limitations.

You can play back H.264 1080p30 content, but it has to be Baseline profile—no B frames, two reference frames. I used handbrake and messed around with a variety of other encode profiles and eventually settled on a bitrate of around 10 Mbps. That puts a 2 hour movie at around 8 GB total, which is too big to fit on a FAT32 microSD card. If you’re going to fit 2 hours of video on that SD card and stay under 4 GB, bitrate should be around 4 Mbps. Tegra 2 can decode H.264 1080P baseline at a maximum of 20 Mbps.

Interestingly enough, I tried the iPhone 4 preset in handbrake which is H.264 960x400 High profile and noticed some stuttering and dropped frames. Media playback on Tegra 2 as it stands definitely works best with H.264 baseline, it’s just a matter of having gobs of storage to park video on.

The 2X didn’t do very well in our media streamer test suite. Some of that is because the software lacks the ability to open mkvs and a huge number of our files. The two that did open and playback successfully were test 3, an 8 Mbps 1080p WMV9 video with 5.1 WMA audio, and file 19, a simple m4v container test. Unfortunately we’re still not at the point where you can dump just about anything you’d stick on an HTPC on your mobile device without a transcode in-between, it’s no pirate phone.

Software Preload and Constant Crashing Battery Life and Final Thoughts
POST A COMMENT

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?? Reply
  • 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! Reply
  • 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. Reply
  • 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. Reply
  • zorxd - Monday, February 7, 2011 - link

    Stock Android has it too. There is also E for EDGE and G for GPRS. Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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
    Reply

Log in

Don't have an account? Sign up now