Final Words

NVIDIA’s challenge with Tegra has always been getting design wins. In the past NVIDIA offered quirky alternatives to Qualcomm, most of the time at a more attractive price point. With Tegra K1, NVIDIA offers a substantial feature and performance advantage thanks to its mobile Kepler GPU. I still don’t anticipate broad adoption in the phone space. If NVIDIA sees even some traction among Android tablets that’s enough to get to the next phase, which is trying to get some previous generation console titles ported over to the platform.

NVIDIA finally has the hardware necessary to give me what I’ve wanted ever since SoC vendors first started focusing on improving GPU performance: the ability to run Xbox 360 class titles in mobile. With Tegra K1 the problem goes from being a user interface, hardware and business problem to mostly a business problem. Android support for game controllers is reasonable enough, and K1 more or less fixes the hardware limitations, leaving only the question of how do game developers make enough money to justify the effort of porting. I suspect if we’re talking about moving over a library of existing titles that have already been substantially monetized, there doesn’t need to be all that much convincing. NVIDIA claims it’s already engaged with many game developers on this front, but I do believe it’ll still be an uphill battle.

If I were in Microsoft’s shoes, I’d view Tegra K1 as an opportunity to revolutionize my mobile strategy. Give users the ability to run games like Grand Theft Auto V on a mobile device in the not too distant future and you’ve now made your devices more interesting to a large group of users. I don’t anticipate many wanting to struggle to play console games on a 5-inch touchscreen, but with a good controller dock (or tablet with a kickstand + wireless controller) the interface problem goes away.

For the first time I’m really excited about an NVIDIA SoC. It took the company five generations to get here, but we finally have an example of NVIDIA doing what it’s really good at (making high performance GPUs) in mobile. NVIDIA will surely update its Tegra Note 7 to a Tegra K1 version (most of its demos were run in a Tegra Note 7 chassis), but even if that and Shield are the best we get the impact on the rest of the market will be huge. With Tegra K1, NVIDIA really raised the bar on the GPU performance.

The CPU side, at least for the Cortex A15 version is less interesting to me. ARM’s Cortex A15, particularly at high clocks, has proven to be a decent fit for tablets. I am curious to see how the Denver version of Tegra K1 turns out. If the rumors are true, Denver could very well be one of the biggest risks we’ve seen taken in pursuit of building a low power mobile CPU. I am eager to see how this one plays out.


Finally: two big cores instead of a silly number of tiny cores

NVIDIA hasn’t had the best track record of meeting shipping goals on previous Tegra designs. I really hope we see Tegra K1, particularly the Denver version, ship on time (although I'm highly doubtful this will happen - new custom CPU core, GPU and process all at the same time?). I’m very eager not only for an install base of mobile devices with console-class GPUs to start building, but also to see what Denver can do. I suspect we’ll find out more at GTC about the latter. It’s things like Tegra K1 that really make covering the mobile space exciting.

Tegra K1 ISP & Video
Comments Locked

88 Comments

View All Comments

  • blanarahul - Monday, January 6, 2014 - link

    Quick question: Is it possible to build a 32-bit ARMv8 CPU core i.e. a ARMv8 core capable of running a 32-bit OS without using a hypervisor? That would really ease the transition to 64-bit for Android.
  • blanarahul - Monday, January 6, 2014 - link

    Anand, where do you find information about the revisions of Cortex cores??
  • blanarahul - Monday, January 6, 2014 - link

    Found it: http://infocenter.arm.com/help/index.jsp?topic=/co...
  • klmx - Monday, January 6, 2014 - link

    The real-time version of ARMv8 (ARMv8-R) is still 32-bit, and is capable of running a rich OS like Android, but I guess that's not the solution you had in mind
  • droopaloop - Monday, January 6, 2014 - link

    ARMv8 supports 2 different instruction sets; AArch32, and AArch64. AArch32 is basically the ARMv7 instruction set (read: 32bit). It is possible to run Android in AArch32. It is also possible to run the kernel in AArch64, and have AArch32 apps running on top which should help ease the transition to 64bit.
  • Krysto - Monday, January 6, 2014 - link

    How would using a 32-bit-only CPU ease the transition to 64-bit? ARMv8 supports both 32-bit and 64-bit modes by default (you can make it 64-bit-only later, though), so that's what needed for the "transition to be easier" - OEMs to just jump to ARMv8, even if the OS remains 32-bit.
  • phoenix_rizzen - Monday, January 6, 2014 - link

    This is exactly what Apple did with their A7 SoC. It's an ARMv8 CPU. It can run either a 64-bit or 32-bit version of iOS. If running the 64-bit version, it can run either 32-bit or 64-bit apps.
  • Krysto - Monday, January 6, 2014 - link

    That's what everyone will do. That's what I'm saying. It's the default. OEMs just need to switch to ARMv8, and that's it. It's up to Google to make Android 64-bit, and then to app devs to make their apps 64-bit, but neither is "necessary" for the transition to 64-bit CPUs.
  • BMNify - Tuesday, January 7, 2014 - link

    remember The Cortex-A15 and above also introduced full hardware accelerated virtualization so you could also run several versions of an OS concurrently too if you so wished and skillful enough to code your apps base libraries with good generic and fast inter process communications (xcore style)
  • deltatux - Thursday, January 9, 2014 - link

    Why would you need to build a 32-bit ARMv8 core? Android is highly portable, just recompile the entire thing to the aarch64 instruction set and you're good to go. Nearly all apps are written in Dalvik anyways which means you won't have to recompile those apps and ARMv8 in itself is backwards compatible with 32-bit just like how x86-64 is backwards compatible with the original 32-bit x86. So even if there are 32-bit native apps, they can easily run on 64-bit Android.

    NVIDIA has shown off Android 4.4 running on Denver in 64-bit mode, so 64-bit Android does exist and works out of the gate.

Log in

Don't have an account? Sign up now