NVIDIA Tegra Architecture

[A1xLLcqAgt0qc2RyMz0y]

Transcript, audio or video on Hot Chips 2014 Nvidia Denver Presentation

Does anyone have a link to a transcript, audio or video on Hot Chips 2014 Nvidia Denver Presentation that this Nvidia Denver Slide Deck came from?

https://drive.google.com/file/d/0B8m...it?usp=sharing

I sure would love to hear the actual talk that went with these slides.

EDIT: Bummer, it looks like the videos are password protected but will be available to all for free in December.

In December 2014 all conference slide presentations and videos will be made available to the public at no charge.

http://www.hotchips.org/post-conference-access/

 

[Exophase]

I would also like to know.

Since the IPC starts out at 0.6 using the ARM HW Decoder and then doubles to 1.2 using the Optimized ucode I take that to mean that the IPC mentioned in the slides is the ARMv8 instruction set and not the Nvidia ucode instructions.

Does anyone have the IPC for SpecInt:Crafty Execution on Cortex A15's or any preliminary IPC data for the Cortex A57?

A program IPC comparison between A15 and Denver is pointless because they're not even running the same instruction set. Unless Denver was running 32-bit code which I very strongly doubt. Crafty in particular likely executes in much fewer instructions when compiled for AArch64.

I also doubt that IPC was AArch64 instructions in the first place, because how would they even measure that? The recompiled code has extensive optimizations, there isn't a simple correlation to how many original ARM instructions it would have been. And even if it were I doubt that the Denver core would attempt to track this as a performance metric because it's a bunch of overhead for nothing. Unless nVidia was using simulators all along, in which case their results are already skewed unless their simulators are perfect (they almost never are)

Sadly, you have to pay for SPEC, even SPEC2k which was retired years ago. You have to actually mail SPEC asking them to sell it to you, meaning they'll probably want to know why you want it and could deny the sale, and who knows how much they charge (SPEC2006 is $800)

Crafty is open source, but I have no idea what exact version SPEC used. And even if we had it, I don't know what compiler version and options nVidia used. So it's hard to synthesize a relevant comparison.

 

[3dilettante]

I also doubt that IPC was AArch64 instructions in the first place, because how would they even measure that? The recompiled code has extensive optimizations, there isn't a simple correlation to how many original ARM instructions it would have been. And even if it were I doubt that the Denver core would attempt to track this as a performance metric because it's a bunch of overhead for nothing. Unless nVidia was using simulators all along, in which case their results are already skewed unless their simulators are perfect (they almost never are)

If it's just a rough approximation, they could get an IPC estimate from a trace running solely on the ARM front end, then run it again with the dynamically compiled version.
It would be an estimate of "effective" IPC, which seems flexible enough for marketing purposes.

One possible use for tracking the number of native instructions during compiled mode might be if the optimizer detects it's in an Icache-constrained situation. That might not matter so much until there's a multithreaded scenario.

 

[ams]

iFixit Google Project Tango tablet teardown (with quad-core A15 Tegra K1 variant, 4GB RAM, 128GB flash mem, and with an NVIDIA multi-mode RF transceiver and NVIDIA Icera LTE modem):

https://www.ifixit.com/Teardown/Project+Tango+Tablet+Teardown/28148

 

[ams]

HTC tablet codenamed "Flounder" is confirmed with Android "L" operating system, 2.4GHz and 5GHz switchable WiFi frequency bands, WiFi certified for a, b, g, n, ac, and with WiFi Direct connectivity: http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA54709

 

[Exophase]

HTC tablet codenamed "Flounder" is confirmed with Android "L" operating system, 2.4GHz and 5GHz switchable WiFi frequency bands, WiFi certified for a, b, g, n, ac, and with WiFi Direct connectivity: http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA54709

What does it have to do with nVidia? You don't think all Android L devices will use nVidia SoCs, do you..?

 

[ams]

What does it have to do with nVidia? You don't think all Android L devices will use nVidia SoCs, do you..?

HTC "Flounder" is one tablet that is rumored to be powered by the 64-bit version of Tegra K1. Even the Android Open Source Project change log makes reference to it: https://android-review.googlesource.com/#/c/81232/

 

[Ailuros]

Excuse the OT, but what the heck have Quadros with Android to do? http://gfxbench.com/device.jsp?benc...i=gl&D=NVIDIA+Quadro+K1100M&testgroup=overall

 

[Deleted member 13524]

Excuse the OT, but what the heck have Quadros with Android to do? http://gfxbench.com/device.jsp?benc...i=gl&D=NVIDIA+Quadro+K1100M&testgroup=overall

Someone with a Quadro who decided to install Android or an Android VM just for the lulz?
I take it that porting a regular Linux driver to Android shouldn't be too hard.

 

[Nebuchadnezzar]

I take it that porting a regular Linux driver to Android shouldn't be too hard.

Actually it is, the userspace stuff has nothing in common. However the link Ailuros posted seems to filter for Windows as OS?

 

[Ailuros]

Actually it is, the userspace stuff has nothing in common. However the link Ailuros posted seems to filter for Windows as OS?

It's gone now; I don't recall seeing for what OS it was, however when it was still active it showed up on top of the Gfxbench3.0 list which is at the moment still for Android only.

 

[xpea]

first leaked CPU-Z screenshot of Nexus 9 on Youtube:
http://youtu.be/7W_utZdw5RY

dual Denver 64bit at 2.5GHz

 

[Exophase]

first leaked CPU-Z screenshot of Nexus 9 on Youtube:
http://youtu.be/7W_utZdw5RY

dual Denver 64bit at 2.5GHz

And the Denver cores are r3p3, which just happens to be the same as the A15 cores in K1-32? And since when does CPU-Z use commas for decimal breaks instead of periods? Here's what CPU-Z looks like for Tegra K1-32:

http://www.iopanel.net/p12058/

I smell a fake.

 

[xpea]

And the Denver cores are r3p3, which just happens to be the same as the A15 cores in K1-32? And since when does CPU-Z use commas for decimal breaks instead of periods? Here's what CPU-Z looks like for Tegra K1-32:

http://www.iopanel.net/p12058/

I smell a fake.

hmmm you're right, should be fake. sorry I did not check carefully before posting.

Hopefully, next news is real :

http://www.anandtech.com/show/8435/nvidia-vmware-preview-vgpu-chromebook-support

Good move to sell more Tegra Chromebooks in corporates

 

[Exophase]

Nice, an nVidia Chromebook could make a much better ARM Linux laptop than the Exynos ones. Hopefully nVidia will even put up official Linux distro images. Even if they don't, just by starting with the dev board images you should get something a lot less hacked and broken, with proper OpenGL drivers.

 

[Blazkowicz]

I think it's up to Ubuntu, Debian, Fedora et alia to provide these.
Eventually most of the ARM server world will support UEFI, for instance (I think) so generic linux images for ARM would be a possibilty ; a same .iso or such would be usable on several brands of servers and also on a Tegra computer, the same way it's done in the x86 world.

I forgot that Chromebooks have their own particular bootloader though so you'll still have to use things like "Crouton" and "ChrUbuntu".

 

[A1xLLcqAgt0qc2RyMz0y]

And the Denver cores are r3p3, which just happens to be the same as the A15 cores in K1-32? And since when does CPU-Z use commas for decimal breaks instead of periods? Here's what CPU-Z looks like for Tegra K1-32:

http://www.iopanel.net/p12058/

I smell a fake.

I am now having doubts that the Nexus 9 will even have a Nvidia SOC.

With the HTC Desire 510 containing the "Qualcomm’s first 64-bit chip – the 1.2GHz Snapdragon 410" why would HTC ditch Qualcomm for the Nexus 9. Why not just use the Snapdragon 810.

http://www.forbes.com/sites/gordonkelly/2014/08/27/iphone-6-ipad-nexus-android-rival

The whole premise that Nvidia was going to win the Nexus 9 was that it was going to be an ARM 64bit SOC and many thought that only Nvidia would have a 64bit ARM SOC available in the time frame. It now looks like Qualcomm is also going to be available.

 

[xpea]

The whole premise that Nvidia was going to win the Nexus 9 was that it was going to be an ARM 64bit SOC and many thought that only Nvidia would have a 64bit ARM SOC available in the time frame. It now looks like Qualcomm is also going to be available.

well between QC ARM A53 Snapdragon 410 with Adreno 306 GPU and 64bit TK1 with Denver + Kepler, performance is night and day. Not sure the mid range Snapdragon will give justice to Goggle's tablet and the rumored high DPI display...

 

[A1xLLcqAgt0qc2RyMz0y]

well between QC ARM A53 Snapdragon 410 with Adreno 306 GPU and 64bit TK1 with Denver + Kepler, performance is night and day. Not sure the mid range Snapdragon will give justice to Goggle's tablet and the rumored high DPI display...

I was talking about the Snapdragon 810 not the 410.

 

[Exophase]

I think it's up to Ubuntu, Debian, Fedora et alia to provide these.

They can but they don't have to, and when it comes to SoC specific stuff they generally don't.

Eventually most of the ARM server world will support UEFI, for instance (I think) so generic linux images for ARM would be a possibilty ; a same .iso or such would be usable on several brands of servers and also on a Tegra computer, the same way it's done in the x86 world.

Having a common boot platform isn't enough. The other thing that makes this work is that all of the unique hardware (outside of whatever base legacy PC definition remains) is behind some modular bus like PCIe or USB, that enables some kind of peripheral discovery. SoCs don't work like this, they generally have peripherals hanging directly off their physical address space at fixed locations. So you end up with a different set of drivers loaded or built into the kernel in a fixed sort of way.

This could perhaps be abstracted away too, with some reliable SoCs identification process, but there are so many different SoCs with different peripheral combinations...