Blazkowicz
Legend
We all like to claim that Apple is form without substance and it is easy to troll about them, then we're now forced to remember they are a hardware company afterall.
NVIDIA Tegra Architecture
- Thread starter french toast
- Start date
-
- Tags
- nvidia
1. They obviously didn't mind several times so far.
2. It's only a true octacore when global task scheduling works even for marketing droids.
3. Since Parker most likely will bounce back to Denver how will they explain to marketing droids the loss of 6 cores exactly?
Between lines I more than once suggested that ARM should license CYCLONE from Apple back (not possible, but the sarcasm is obvious). That should also mean that I still have a ton of question marks considering Denver and my so far gut feeling tells me that in real time Cyclone still wins big time against it.
Thought exercise then. Have a look at that one: http://www.ondaforum.com/topic/859-onda-v989-cpu-configuration/ and particularly on the "speed mode". Now it doesn't really operate as a pure quad A15 config only as the author implies it probably just gives priority to the A15 cluster and uses only the A7 cluster if needed. Would you suggest that in the latter case it never uses the A7 quad and how big would you think is the power difference for the two use cases? (normal mode vs. speed mode, watch also the minimum frequencies).
Last edited:
Read the Anandtech article for more info on their automotive platforms, DRIVE CX and DRIVE PX. But in short..yes Nvidia is introducing a self-driving car platform.
Actually I was kinda wondering the same thing..despite all the talk from Nvidia that it was for time to market reasons..I suspect that it was due to the fact that Denver was simply not competitive enough. Of course you wouldn't expect them to say that hence the spin on time to market. Anyway it seems all but confirmed that they are working on a Parker SoC with Denver cores on 16FF. Presumably these would be updated cores compared to TK1.
Yes I saw that PR statement too..but as Nebu said and others have been discussing..it does not appear that it will be beneficial for this generation.
Yep..the claims do seem rather tall. From the AT Article - "NVIDIA claims that Tegra X1 significantly outperforms Samsung System LSI’s Exynos 5433 in performance per watt with 1.4x more performance at the same amount of power or half the power for the same performance on the CPU".
I read your post that 5433 is a bad implementation so this could account for a part of the difference. But my question is..what workload are they referring to here..any idea?
Having an integrated modem/LTE is not the holy grail. I think people overestimate the importance of it. Look at Samsung and the international versions of their Galaxy S and Galaxy Note lines over the years. And comparing it to Mediatek is apples and oranges..they simply do not compete with this class of chip. AFAIK Mediatek do have an A57 design in the works but it is on 28nm. And Mediatek's graphics implementations are woefully underpowered.
I think that goes without saying..it had to be without DRAM intervention..if not, it would be extremely power inefficient wouldn't it? Btw do we have any idea if there is large L3 cache like Apple has?
How much of a process advantage does TSMC 20nm have over Samsung 20nm? Sounds interesting..looking forward to reading that Article! (This year please?
) And yes..given that A57 is supposed to be more power efficient than A15..it is quite bad if the A15's in 5430 beat it. I get the same impression. And I had the same response as Alexko..why didn't they just use CCI-400 then. The strange part is they elected to put in a lot of engineering investment to design their own interconnect..which appears to be inferior to one already available from ARM ¯\_(ツ)_/¯
Krait called..it wants its Mojo back. Seriously..Krait 300 and 400 have proven dominant over the past few years and you claim Qualcomm dosen't have a great reputation for CPU design? And arguably their DVFS has resulted in Snapdragon 800 being the most power efficient platform on the market, and big.LITTLE, despite all the marketing hype..hasn't been able to beat it.
Apple do not use big.LITTLE..they just use fewer..very wide cores. However, I would be surprised if they did not use asynchronous DVFS.
1. Exactly..Nvidia have used standard ARM cores for years now..nothing new or surprising that they've gone for A57. Qualcomm have also done the same, despite having been in the custom CPU game for a lot longer.
2. Marketing will spin it as it best suits them. Samsung also claimed "Octa-core" for the cluster migration 5410.
3. Good question..though my speculation is that it will be a loss of 4 cores and not 6. Qualcomm will face the same problem with their next custom core.
Denver is huge. It's like a truck... the kind that's big enough to carry another truck when it has broken down, and leave room for a private jet with swimming pool on top.
But *if* Denver had higher performance than A57 and equal or better power efficiency, then I think that's not really a problem TBH. The mobile world doesn't need a large number of high IPC cores; what you really want is ~2 extremely fast cores then a large number of smaller cores for parallel workloads. Think of CELL but massively faster and hilariously easier to program (i.e. transparent if you want it to be).
If I was NVIDIA, I would do the following:
- 16FF process
- 2 x Denver (2.5GHz+ with revisions)
- 4 x A53 (2GHz+ - optimised for speed)
- 4 x A53 (1.2GHz+ - optimised for power)
- All cores can be used at the same time...
That gives you a 10-core (yay marketing!) processor with incredibly high single-threaded *and* multi-threaded performance. The *really* hard part is getting all cores to work at the same time - I don't think a 3-cluster system makes any sense otherwise. And NVIDIA apparently already can't do this with a standard A57+A53 config, then it becomes even slightly harder with Denver because of the different internal ISA (probably not too bad as long as Denver has similar IPC to A53 on ARM ISA code pre-transcoding).
One possible advantages of simultaneous Denver+A53 is that you could keep more stuff on the A53s and reduce instruction cache pressure on the Denver. Another is that you could use the A53s for the transcoding, although I would assume NVIDIA has some dedicated helpler instructions for that which might make it counter-productive (unless they customised the A53 which ARM doesn't let its partners do, and a from-scratch design would be expensive).
Overall it's clear that making the best possible business use of Denver is a complex technical problem. I can only hope that the relatively lack of success of K1-64 motivates NVIDIA to double down and find interesting solutions to these and other problems, rather than let this interesting architecture linger in disrepair and fail.
But *if* Denver had higher performance than A57 and equal or better power efficiency, then I think that's not really a problem TBH. The mobile world doesn't need a large number of high IPC cores; what you really want is ~2 extremely fast cores then a large number of smaller cores for parallel workloads. Think of CELL but massively faster and hilariously easier to program (i.e. transparent if you want it to be).
If I was NVIDIA, I would do the following:
- 16FF process
- 2 x Denver (2.5GHz+ with revisions)
- 4 x A53 (2GHz+ - optimised for speed)
- 4 x A53 (1.2GHz+ - optimised for power)
- All cores can be used at the same time...
That gives you a 10-core (yay marketing!) processor with incredibly high single-threaded *and* multi-threaded performance. The *really* hard part is getting all cores to work at the same time - I don't think a 3-cluster system makes any sense otherwise. And NVIDIA apparently already can't do this with a standard A57+A53 config, then it becomes even slightly harder with Denver because of the different internal ISA (probably not too bad as long as Denver has similar IPC to A53 on ARM ISA code pre-transcoding).
One possible advantages of simultaneous Denver+A53 is that you could keep more stuff on the A53s and reduce instruction cache pressure on the Denver. Another is that you could use the A53s for the transcoding, although I would assume NVIDIA has some dedicated helpler instructions for that which might make it counter-productive (unless they customised the A53 which ARM doesn't let its partners do, and a from-scratch design would be expensive).
Overall it's clear that making the best possible business use of Denver is a complex technical problem. I can only hope that the relatively lack of success of K1-64 motivates NVIDIA to double down and find interesting solutions to these and other problems, rather than let this interesting architecture linger in disrepair and fail.
Nebuchadnezzar
Legend
Erineyes: Their power/perf claims are based on SPECint measurements. I've avoided using that for power measurement as to not anger the people who provide us the suite, but I can tell you it's basically just a use-case with just 1 core having any load, furthering my suspicion that most gains are unrelated to the CM scheme and we're talking just process here.
Samsung's 20nm seems about as efficient as 28HPM when strictly talking about voltages.
Samsung's 20nm seems about as efficient as 28HPM when strictly talking about voltages.
Last edited:
It may not be the Holy Grail but it's Qualcomm's main competitive advantage, and they do dominate the smartphone market. They do pretty well in tablets too. They also have Krait and Adreno, but neither seems particularly better than Cortex or Mali/PowerVR respectively. The market performance of their Cortex-powered S810 should bring us more controlled information about the competitive value of their modems, unless Adreno 430 turns out to be spectacular.
As for Mediatek, I don't know what they're working on exactly for 2015, but I imagine they must have some sort of 4+4 A57/A53 setup with decent graphics. I'm not trying to say that they compete with NVIDIA on graphics performance.
Rather, I'm arguing that there's really not much you can do on a Tegra device that you can't do on a (cheaper) Mediatek one. Whatever it is that you can do on Tegra and not on an MT chip, I doubt it's enough for Tegra to be viable as a tablet product. Since (from what I've read) JHH spent far more time talking about cars than tablets when presenting Erista, he just might agree with me.
D
Deleted member 2197
Guest
Jon Peddie ...
From this statement it makes sense to use an off-the-shelf ARM processor in the interest of time to market.
http://www.eetimes.com/author.asp?section_id=36&doc_id=1325158
From this statement it makes sense to use an off-the-shelf ARM processor in the interest of time to market.
http://www.eetimes.com/author.asp?section_id=36&doc_id=1325158
QCOM's hw is fine IMHO; it's the sw that usually leaves a lot to be desired.
MTK has a big.LITTLE setup planned as you describe it with a higher clocked G6200. Mediatek has been getting increasingly better on the sw side since the MT6595.
If you'd want a high end Android gaming tablet you'd obviously go for a Tegra than a Mediatek tablet. In peak GFLOP values the X1 GPU will be over 4x times ahead of the forementioned G6200, but the trouble then is that there aren't enough as demanding games available to make the X1 tablet shine even more. The majority of tablets out there have nowadays MaliT760, Rogue G62x0 and others which are roughly on the same performance level. If you bounce over to the iOS world on the other hand how high is the persentage exactly of iPad Air and iPad Air2 tablet owners out of the total Apple iPad owners? Even much much worse ULP mobile games are short and restricted due to storage and download restrictions; ie you have short $9 games at best. Assuming you're an ISV would you really develop a game only for enthusiast tablet users?
Even worse now that NVIDIA also supports FP16 ops in its ALUs there's no chance in hell they can support console quality games *snicker*
Last but not least: did I misread something or did Jensen really claim that X1 has the performance of the Xbox One console? I call for bullshit no matter how much tear and feathers are on their way
D
Deleted member 13524
Guest
What are the 2GHz A53 doing in there? Why not just 2xDenver + 4x A53?
Oh oh, let's do this and really confuse everyone:
- 2x Denver
- 2x Cortex-A57
- 4x Cortex-A53
Pffff amateurs.....on the upper right tab there will be a "high performance" mode which will be enabled after the tablet reboots. It'll switch the CPU to 3* 2nd generation Denver cores at frequencies ranging exclusively from 2.4 to 3.0GHz and will serve only for popular public benchmarks. Do not attempt to conduct any battery life tests when in that mode as it'll be detected by our nPower sw and will fail; please also ensure that your battery life is higher than 40% in order to avoid random crashes. In "normal mode" you'll be running on the 4*A57+4*A53 CPU config with a minimum frequency of 400MHz for the first A53 core and there you are allowed only to run battery life tests but not any benchmarks
There happy now? THAT'S a solution chinese manufacturers would fall all over
There happy now?
THAT'S a solution chinese manufacturers would fall all over It's similar to the Snapdragon 615 using A53@1.7GHz + A53@1.0GHz. There is quite a large power/area efficiency difference between a ~2GHz and a ~1GHz core.
Plus it gives you a 10-core config which everyone knows is universally better than 6-core or 8-core!
The chip in general does not behave like an ARM chip, although it presents the illusion of it to software.
It may be more complicated than putting the cores in, although I admit I'm speculating on this.
The cache behavior for Denver is definitely different, with some kind of transactional memory setup for the data cache in order to protect the system from seeing data that could be rolled back.
The optimization cache is a decent chunk of system memory set aside with highly specialized permissions, which in the case of Denver's Transmeta ancestors required special instructions to interact with.
Nvidia's interconnect might have needed to be customized to permit this behavior, and to enforce the security of the optimization cache. While I don't have evidence of it being the case, I think there are also possibilities for optimization or better functionality if some of the dynamic translation or more speculative nature of Denver's architecture leaks out. Things like tighter modification checks for the instruction caches or coherence behavior that takes the transactional model into account might make the interconnect behave in a non-standard manner. As long as the other cores in the system are Denver, they would know how to play ball.
The interface could be customized to guard non-Denver cores from seeing that kind of traffic, although the comparatively more straightforward implementation would be a custom interconnect that might be configured at design time for various target architectures, rather than one that tries to support bridging architectures on the fly.
Perhaps instruction footprint would be less of a problem if the ISA wasn't allegedly capable of emulating arbitrary architectures like x86. An ARM-specific emulation ISA with all the extra bells and whistles could probably find economies in areas of functionality that ARM may not need, but which x86 would. Having the expanded uop format in memory seems to imply safeguarding against decode costs that ARM is not noted for, as an example.
The skewed pipeline that allows a load, dependent ALU, and dependent store to exist in the same bundle, which in-order cores sometimes utilize and which x86 cores also like given their use of memory. This, along the transactional model, seems to make allowances for an architecture that is heavy on read/modify/write atomics or for linked loads and checked stores. This is growing the obligations of the ISA and architecture in a way that straddles how two disparate architectures handle atomics.
They could also add a renamer or find a way to go out of order so they don't blow out loops due to putting the bulk output of a straightforward OoO optimization like automatic register renaming in the instruction stream.
Eh, it is not that far off. The CPU is probably as good or better, while the GPU is roughly half the performance (or much closer if using fp16). Bandwidth is the only real killer, but if one is willing to accept 720p instead of 1080p, I imagine Xbox One games could run just fine on it with minimal adjustment. It is certainly much better than the Wii U at any rate....
Individually the higher clocked A57s can probably outpace the Jaguars in normal situations, but I don't think that plus the 4 Cortex-A53s is enough to match the 8 cores. That, and I think there will be few if any actual devices that will allow all four A57s to be run at peak clock simultaneously, at least for any meaningful length of time. Even the original Shield handheld which had a fan had a hard cap of 1.4GHz for the four A15 cores if they were all active.
A lot of XB1 games are already not 1080p, and the typical bandwidth gap is way more than 2.25x anyway...
Similar threads
