RISC-V still seems too ad-hoc to me, and really new. Hard to say where it'd go for now.
I know momentum is currently towards ARM over POWER, but... OpenPOWER is certainly a thing, and has IBM / Red Hat support. IBM may be expensive, but they already were proven "fair partners" in the OpenPOWER initiative and largely supportive of OSS / Free Software.
I would love OpenPOWER to succeed. I just don't see the 48 pin QFP version that costs < $1 and powers billions of gizmos. For me the ARM ecosystem's biggest win is that it scales from really small (M0/M0+) to really usefully big (A78) and has many points between those two architectures.
I don't see OpenPOWER going there, but I can easily see RISC-V going there. So, for the moment, that is the horse I'm betting on.
Not quite 48-pin QFP chips, but 257-pin embedded is still smaller than Rasp. Pi. (Just searched what NXP's newest Power-chip is, and its a S32R274: 2MB 257-pin BGA. Definitely "embedded" size, but not as small as Cortex-M0)
To be honest, I don't think that NVidia/ARM will screw over their Cortex-M0 or Cortex-M0+ customers over. I'm more worried about the higher-end, whether or not NVidia will "play nice" with its bigger rivals (Apple, Intel, AMD) in the datacenter.
Those processors make quite a few reference to an "e200", which I think is the CPU architecture. I discovered that Digi-Key lists quite a few variants of this under Core Processor; and checking the datasheets of some random results suggests that they are indeed Power architecture parts.
The cheapest option appears to be the $2.67@1000, up-to-48MHz SPC560D40L1B3E0X with 256KB ECC RAM.
Selecting everything >100MHz finds the $7.10@1000 SPC560D40L1B3E0X, an up-to-120MHz part that adds 1MB flash (128KB ECC RAM).
Restricting to >=200MHz finds the $13.32@500 SPC5742PK1AMLQ9R has which has dual cores at 200MHz, 384KB ECC RAM and 2.5MB flash, and notes core lock-step.
--
After discovering the purpose of the "view prices at" field, the landscape changes somewhat.
Sure, the ARM ISA is old, but a few things have happened in microarchitecture since then. I wouldn't be rushing to use a 10-year-old ARM over a newer one. The Cortex cores are pretty great compared to ARM9 or whatever.
The ARM Cortex-M3 was released in 2006 and is still a popular microcontroller core. Microcontrollers have a multi-decade long lifespan. (I'm still seeing new 8051-based designs...)
There are still new chips using the Cortex-M3 today. Microcontroller devs do NOT want to be changing their code that often.
New chips move the core to lower-and-cheaper process nodes (and lower the power consumption), while otherwise retaining the same overall specifications and compatibility.
You’re supposed to drag-solder those. Look it up on YouTube, it’s super easy. The hardest part is positioning the chip, but it’s actually easier than with an oven, because you can rework it if you only solder one or two pins :)
OpenPOWER is pretty awesome but would be nowhere near as awesome as an OpenItanium. IMHO, Itanium was always mismarketed and misoptimized. It made a pretty good server processor, but not so good that enterprises were willing to migrate 40 year old software to run on it.
In mobile form, it would have made a large leap in both performance and battery life. And it would have been a fairly easy market to break into: the average life of a mobile device is a few years, not a few decades. Recompilation and redistribution of software is the status quo.
Itanuim deserved its fiery death and resurrection doesn't make any sense whatsoever. It's a dead end architecture, and humanity gained (by freeing up valuable engineering power to other more useful endeavors) when it died.
Itanium was an excellent idea that needed investment in compilers. Nobody wanted to make that investment because speculative execution got them 80% of the way there without the investment in compilers. But as it turns out, speculative execution was a phenomenally bad idea, and patching its security vulnerabilities has set back processor performance to the point where VLIW seems like a good idea again. We should have made those compiler improvements decades ago.
Each machine instruction on NVidia Volta has the following information:
* Reuse Flags
* Wait Barrier Mask
* Read/Write barrier index (6-bit bitmask)
* Read Dependency barriers
* Stall Cycles (4-bit)
* Yield Flag (1-bit software hint: NVidia CU will select new warp, load-balancing the SMT resources of the compute unit)
Itanium's idea of VLIW was commingled with other ideas; in particular, the idea of a compiler static-scheduler to minimize hardware work at runtime.
To my eyes: the benefits of Itanium are implemented in NVidia's GPUs. The compiler for NVidia's compiler-scheduling flags has been made and is proven effective.
Itanium itself: the crazy "bundling" of instructions and such, seems too complex. The explicit bitmasks / barriers of NVidia Volta seems more straightforward and clear in describing the dependency graph of code (and therefore: the potential parallelism).
----------
Clearly, static-compilers marking what is, and what isn't, parallelizable, is useful. NVidia Volta+ architectures have proven this. Furthermore, compilers that can emit such information already exist. I do await the day when other architectures wake up to this fact.
GPU's, aren't general purpose compute. EPIC did fairly well with HPC/etc style applications as well, it was everything else that was problematic. So, yes there are a fair number of workload and microarch decision similarities. But right now, those workloads tend to be better handled with a GPU style offload engine (or as it appears the industry is slowly moving, possibly a lot of fat vector units attached to a normal core).
I'm talking about Volta's ability to detect dependencies. Which is null: the core itself probably can't detect dependencies at all. Its entirely left up to the compiler (or at least... it seems to be the case).
AMD's GCN and RDNA architecture is still scanning for read/write hazards like any ol' pipelined architecture you learned in college. The NVidia Volta thing is new, and probably should be studied from a architectural point of view.
Yeah, its a GPU-feature on NVidia Volta. But its pretty obvious to me that this explicit dependency-barrier thing could be part of a future ISA, even one for traditional CPUs.
FWIW, this article suggests the static software scheduling you are describing was introduced in Kepler, so it's probably at least not entirely new in Volta:
> NVIDIA has replaced Fermi’s complex scheduler with a far simpler scheduler that still uses scoreboarding and other methods for inter-warp scheduling, but moves the scheduling of instructions in a warp into NVIDIA’s compiler. In essence it’s a return to static scheduling
I think your conflating OoO and speculative execution. It was OoO which the itanium architects (apparently) didn't think would work as well as it did. OoO and being able to build wide superscaler machines, which could dynamically determine instruction dependency chains is what killed EPIC.
Speculative execution is something you would want to do with the itanium as well, otherwise the machine is going to be stalling all the time waiting for branches/etc. Similarly, later itaniums went OoO (dynamically scheduled) because it turns out, the compiler can't know runtime state..
PS: speculative execution is here to stay, it might be wrapped in more security domains and/or its going to just be one more nail in the business model of selling shared compute (something that was questionably from the beginning).
Agreed. If you look at what's the majority of compute loads (e.g. Instagram, Snap, Netflix, HPC) then that's (a) not particularly security critical, and (b) so big that the vendors can split their workload in security critical / not security critical, and rent fast machines for the former, and secure machines for the latter.
I wonder which cloud provider is the first to offer this in a coherent way.
I dimly recall reading an interview with one of Intel's Sr. Managers on the Itanium project where he explained his thoughts on why Itanium failed.
His explanation centred on the fact that Intel decided early on that Itanium would only ever be an ultra high end niche product and only built devices which Intel could demand very high prices for. This in turn meant that almost no one outside of the few companies who were supporting Itanium development and certainly not most of the people who were working on other compilers and similar developer tools at the time, had any interest in working on Itanium because they simply could not justify the expense of obtaining the hardware.
So all the organic open source activity that goes on for all the other platforms which are easily obtainable by pedestrian users simply did not go on for Itanium. Intel did not plan on that up front (though in hindsight it seemed obvious) and by the time that was widely recognised within the management team no one was willing to devote the sort of scale of resources that were required for serious development of developer tools on a floundering project.
and many, many others (it produced so many PhDs in 90s). And, needless to say, HP and Intel hired so many excellent researchers during the heydays of Itanium. So I don't know on what basis you think there wasn't enough investment. So I have no choice but to assume you're ignorant of the actual history here, both in academics and industry.
It turns out instruction scheduling can not overcome the challenge of variable memory and cache latency, and branch prediction, because all of those are dynamic and unpredictable, for "integer" application (i.e. bulk of the code running on the CPUs of your laptop and cell phones). And, predication, which was one of the "solutions" to overcome branch misprediction penalties, turns out to be not very efficient, and is limited in its application.
For integer applications, it turns out the instruction level parallelism isn't really the issue. It's about how to generate and maintain as many outstanding cache misses at a time. VLIW turns out to be insufficient and inefficient for that. Some minor attempts are addressing that through prefetches and more elaborate markings around load/store all failed to give good results.
For HPC type workload, it turns out data parallelism and thread-level parallelism are much more efficient way to improve the performance, and also makes ILP on a single instruction stream play only a very minor role - GPUs and ML accelerators demonstrate this very clearly.
As for the security and the speculative execution, speculative execution is not going anywhere. Naturally, there are many researches around this like:
and while it will take a while before the real pipeline implements ideas like above thus we may continue to see some smaller and smaller vulnerabilities as the industry collectively plays whack-a-mole game, I don't see a world where the top of the line general-purpose microprocessor giving up on speculative execution, as the performance gain is simply too big.
I have yet to meet any academics or industry processor architects or compiler engineer who think VLIW / Itanium is the way to move forward.
This is not to say putting as much work to the compiler is a bad idea, as nVidia has demonstrated. But what they are doing is not VLIW.
IMO VLIW is an absurdly bad choice for a general purpose processor. It requires baking in a huge amount of low level micro-architectural details into the compiler / generated code. Which obviously leads to problems with choosing what hardware generation to optimize for / not being able to generate good code for future architectures.
And the compiler doesn't even come close to having as much information as the CPU has. Which basically means that most of the VLIW stuff just ends up needing to be broken up inside the CPU for good performance.
Traditional compiler techniques may have struggled with maintaining code for different architectures, but a lot has changed in the last 15 years. The rise of widely used IR languages has led to compilers that support dozens of architectures and hundreds of instruction sets. And they are getting better all the time.
The compiler has nearly all of the information that the CPU has, and it has orders of magnitude more. At best, your CPU can think a couple dozen cycles ahead of what it is currently executing. The compiler can see the whole program, can analyze it using dozens of methodologies and models, and can optimize accordingly. Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
> At best, your CPU can think a couple dozen cycles ahead of what it is currently executing.
The 200-sized reorder buffer says otherwise.
Loads/stores can be reordered for 200+ different concurrent objects on modern Intel skylake (2015 through 2020) CPUs. And its about to get a bump to 300+ sized reorder buffers in Icelake.
Modern CPUs are designed to "think ahead" almost the entirety of DDR4 RAM Latency, allowing reordering of instructions to keep the CPU pipes as full as possible (at least, if the underlying assembly code has enough ILP to fill the pipelines while waiting for RAM).
> Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
You might be surprised at what the modern Branch predictor is doing.
If your "call rax" indirect call constantly calls the same location, the branch predictor will remember that location these days.
With proper profiling (say, reservoir sampling of instructions causing pipeline stalls), and dynamic recompilation/reoptimization like IBM's project DAISY / HP's Dynamo, you may get performance near a modern out-of-order desktop processor at the power budget of a modern in-order low-power chip.
You get instructions scheduled based on actual dynamically measured usage patterns, but you don't pay for dedicated circuits to do it, and you don't re-do those calculations in hardware for every single instruction executed.
It's not a guaranteed win, but I think it's worth exploring.
But once you do that, then you hardware optimize the interpreter, and then its no longer called a "dynamic recompiler", but instead a "frontend to the microcode". :-)
No doubt there is still room for a power-hungry out-of-order speed demon of an implementation, but you need to leave the door open for something with approximately the TDP of a very-low-power in-order-processor with performance closer to an out-of-order machine.
Neo: What are you trying to tell me? That I can dodge "call rax"?
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't need "call rax".
---
Compiler has access to optimizations that are at the higher level of abstraction than what CPU can do. For example, the compiler can eliminate the call completely (i.e. inline the function), or convert a dynamic dispatch into static (if it can prove that an object will always have a specific type at the call site), or decide where to favor small code over fast code (via profile-guided optimization), or even switch from non-optimized code (but with short start-up time) to optimized code mid-execution (tiered compilation in JITs), move computation outside loops (if it can prove that the result is the same in all iterations), and many other things...
There is no way a compiler can do anything for an indirect call that goes one way for a while and the other afterwards. A branch predictor can get both with if not 100% accuracy about as close to it as you can possibly get.
My point was simply that the compiler may be in position to disprove the assumption that this call is in fact dynamic (it may actually be static) or that it has to be a call in the first place (and inline the function instead).
I'm certainly not arguing against branch predictors.
VLIW was the best implementation (20 years ago) of instruction level parallelism.
But what have we learned in these past 20 years?
* Computers will continue to become more parallel -- AMD Zen2 has 10 execution pipelines, supporting 4-way decode and 6-uop / clock tick dispatch per core, with somewhere close to 200 registers for renaming / reordering instructions. Future processors will be bigger and more parallel, Ice Lake is rumored to have over 300-renaming registers.
* We need assembly code that scales to all different processors of different sizes. Traditional assembly code is surprisingly good (!!!) at scaling, thanks to "dependency cutting" with instructions like "xor eax, eax".
* Compilers can understand dependency chains, "cut them up" and allow code to scale. The same code optimized for Intel Sandy Bridge (2011-era chips) will continue to be well-optimized for Intel Icelake (2021 era) ten years later, thanks to these dependency-cutting compilers.
I think a future VLIW chip can be made that takes advantage of these facts. But it wouldn't look like Itanium.
----------
EDIT: I feel like "xor eax, eax" and other such instructions for "dependency cutting" are wasting bits. There might be a better way for encoding the dependency graph rather than entire instructions.
Itanium's VLIW "packages" is too static.
I've discussed NVidia's Volta elsewhere, which has 6-bit dependency bitmasks on every instruction. That's the kind of "dependency graph" information that a compiler can provide very easily, and probably save a ton on power / decoding.
I'm talking about a mythical / mystical VLIW architecture. Obviously, older VLIW designs have failed in this regards... but I don't necessarily see "future" VLIW processors making the same mistake.
Perhaps from your perspective, a VLIW architecture that fixes these problems wouldn't necessarily be VLIW anymore. Which... could be true.
I agree there is merit in the idea of encoding instruction dependencies in the ISA. There have been a number of research projects in this area, e.g. wavescalar, EDGE/TRIPS, etc.
It's not only about reducing the need for figuring out dependencies at runtime, but you could also partly reduce the need for the (power hungry and hard to scale!) register file to communicate between instructions.
All of this hackery with hundreds of registers just to continue to make a massively parallel computer look like an 80s processor is what something like Itanium would have prevented. Modern processors ended up becoming basically VLIW anyway, Itanium just refused to lie to you.
When standard machine code is written in a "Dependency cutting" way, then it scales to many different reorder registers. A system from 10+ years ago with only 100-reorder registers will execute the code with maximum parallelism... while a system today with 200 to 300-reorder buffers will execute the SAME code with also maximum parallelism (and reach higher instructions-per-clock tick).
That's why today's CPUs can have 4-way decoders and 6-way dispatch (AMD Zen and Skylake), because they can "pick up more latent parallelism" that the compilers have given them many years ago.
"Classic" VLIW limits your potential parallelism to the ~3-wide bundles (in Itanium's case). Whoever makes the "next" VLIW CPU should allow a similar scaling over the years.
-----------
It was accidental: I doubt that anyone actually planned the x86 instruction set to be so effectively instruction-level parallel. Its something that was discovered over the years, and proven to be effective.
Yes: somehow more parallel than the explicitly parallel VLIW architecture. Its a bit of a hack, but if it works, why change things?
Main lesson: we failed to make all the software JIT-compiled or AOT-recompiled-on-boot or something, that would allow retargeting the optimizations for the new generation of a VLIW CPU. Barely anyone even tried. Well I guess in the early 2000s there was this vision that everything would be Java, which is JIT, but lol
Your point seems invalid, in the face of a large chunk of HPC (neural nets, matrix multiplication, etc. etc.) getting rewritten to support CUDA, which didn't even exist back when Itanium was announced.
VLIW is a compromise product: its more parallel than a traditional CPU, but less parallel than SIMD/GPUs.
And modern CPUs have incredibly powerful SIMD engines: AVX2 and AVX512 are extremely fast and parallel. There are compilers that auto-vectorize code, as well as dedicated languages (such as ipsc) which work for SIMD.
Encoders, decoders, raytracers, and more have been rewritten for Intel AVX2 SIMD instructions, and then re-rewritten for GPUs. The will to find faster execution has always existed, but unfortunately, Itanium failed to perform as well as its competition.
I'm not talking about rewrites and GPUs. I'm saying we do not have dynamicrecompilation of everything. As in – if we would have ALL binaries that run on the machine (starting with the kernel) stored in some portable representation like wasm (or not-fully-portable-but-still-reoptimizable like llvm bitcode) and recompiled with optimization for the current exact processor when starting. Only that would solve the "new generation of VLIW-CPU needs very different compiler optimizations to perform, oops all your binaries are for first generation and they are slow now" problem.
GPUs do work like this – shaders recompiled all the time – so VLIW was used in GPUs (e.g. TeraScale). But on CPUs we have a world of optimized, "done" binaries.
> And the compiler doesn't even come close to having as much information as the CPU has.
Unless your CPU has a means for profiling where your pipeline stalls are coming from, combined with dynamic recompilation/reoptimization similar to IBM's project DAISY or HP's Dynamo.
It's not going to do well as out-of-order CPUs that make instruction re-optimization decisions for every instruction, but I wouldn't rule out software-controlled dynamic re-optimization getting most of the performance benefits of out-of-order execution with a much smaller power budget, due to not re-doing those optimization calculations for every instruction. There are reasons most low-power implementations are in-order chips.
Because of this transaction? I’m sure this deal will have absolutely no impact on apple’s deal with ARM.
Apple could of course Afford to invest in RISC-V (and surely has played with it internally) but they have enough control of their future under the current arrangement that it will be a long long time before they feel any need to switch — 15 years at least.
Apple and Nvidia don't seem to see eye to eye. Nvidia doesn't support macs (CUDA support was pulled a year or two ago) and apples don't include Nvidia cards.
This is because Nvidia screwed apple (from Apple’s POV) years ago with some bad GPUs to the point where Apple flat out refuses to source Nvidia parts. I don’t know the internal details of course just the public ones so can’t say if Apple is being petty or if Nvidia burned the bridge while the problem was unfolding.
Given that the CEO was the supply chain guy at the time I suspect the latter, as I’d imagine he’d be more dispassionate than Jobs.
In any case I seriously doubt nvidia could, much less would benefit from cancelling Apple’s agreement.
> ... to the point where Apple flat out refuses to source Nvidia parts.
I've seen this argument made before.
It would be a valid point if Apple stopped using Nvidia GPUs in 2008 (they did), and then never used them again. And yet, 4 years later, they used Nvidia GPUs on the 2012 MacBook Retina 15" on which I'm typing this.
AMD doesn't grossly lie about their thermal specifications like Nvidia consistently does. To the point engineers can't design shit properly.
It's one thing to make mistakes in engineering, that can be smoothed out with cash.
It's another to outright lie and cover up.
> I never liked Softbank owning it, but hey someone has to.
I understand what you're saying and this seems to be the prevailing pattern but I really don't understand it. ARM could easily be a standalone company. For some reason, mergers are in.
I would like to understand what you know about ARM that it's board of director's didn't (doesn't) know? In my experience companies merge when they are forced to, not because they want to.
I have always assumed that their shareholders were offered so much of a premium on their shares that they chose to sell them rather than hold onto them. Clearly based on their fiscal 2015 results[1] they were a going concern.
I don't have any specific knowledge of the ARM sale but I've seen other mergers.
Clearly, if a buyer is willing to pay a premium for shares, it's because they believe the company is worth that premium. If the shareholders were optimistic, they might consider that as a signal of the company's underlying value and choose not to sell.
Sometimes activist shareholders will pressure a company to sell, like in the case of the Whole Foods sale to Amazon. Jana Partners owned ~8% and they motivated Whole Foods to look for buyers. They dumped their shares after the sale was announced and before it was executed. Whether that was the best for the other 92% of shareholders, the company's employees, and its customers is another question entirely.
My question is really outside of that. There will always be banks, investors, and companies that are motivated to consolidate and integrate companies to be increasingly competitive to the point of being anti-competitive. What is the counter force that helps maintain moderately sized companies that are profitable on their own?
Conversely, Nvidia has done a solid job of advancing GPU performance even in the face of weak competition, and with their additional resources, ARM performance may advance even faster, and provide the first competition in decades to x86 in servers and desktops.
The tech may have advanced due to the insatiable hunger of machine learning, but the weak competition has meant pricing has not decreased as much as it should have or could have, only enough to move more GPUs. (nvidia biggest competitor are the GPUs they manufactured two years earlier).
Yes really. Performance that is cleverly hampered by RAM (and driver licensing) on the low end from an ML perspective. The only reason they can do this is because of lack of competition. The performance of 3000 series cards could be dramatically improved for large models at a modest increase in price if RAM was doubled.
It really is possible to be critical of a monopoly without disparaging the product itself. It is when a true competitor arises that we see the monopolist's true capabilities (see Intel and AMD).
The GeForce series is targeted at gamers. Video games are not making use of more than ~8GB of VRAM.
There is literally no benefit to 90% of the audience if they doubled the RAM. Of course, they also want to do market segmentation too, but you can’t blame GeForce for not being designed for ML training.
An independent ARM that did not manufacture processors was the best outcome for everyone in the industry.
ARM being owned by an organisation deeply embedded in processor design and manufacturing, will now be licensing designs to competitors, as well as getting a lot of intel on its competitors.
ARM supercomputers were poised to take on Nvidia. Now its all one and the same.
As others have said, this will do wonders for RISC-V.
Consider one of NVidia's rivals: AMD, who uses an ARM chip in their EPYC line of chips as a security co-processor. Does anyone expect NVidia to "play fair" with such a rival?
ARM as an independent company, has been profoundly "neutral", allowing many companies to benefit from the ARM instruction set. It has been run very well: slightly profitable and an incremental value to all parties involved (be you Apple's iPhone, NVidia's Tegra (aka Nintendo Switch chip), AMD's EPYC, Qualcomm's Snapdragon, numerous hard drive companies, etc. etc.). All in all, ARM's reach has been because of its well-made business decisions that have been fair to all parties involved.
NVidia, despite all their technical achievements, is known to play hardball from a business perspective. I don't think anyone expects NVidia to remain "neutral" or "fair".
> Consider one of NVidia's rivals: AMD, who uses an ARM chip in their EPYC line of chips as a security co-processor. Does anyone expect NVidia to "play fair" with such a rival?
Yes, absolutely.
NVIDIA's not going to burn the ARM ecosystem to the ground. They just paid $40 billion for it. And they only had $11b of cash on hand, they really overpaid for it (because SoftBank desperately needed a big win to cover for their other recent losses).
Now: will everybody (including AMD) probably be paying more for their ARM IP from now on? Yes.
When Oracle purchased Sun Microsystems for $7.4 Billion, did you expect Oracle to burn Solaris to the ground, and turn their back on MySQL's open source philosophy? Then sue Google for billions of dollars over the Java / Android thing?
Or more recently, when Facebook bought Oculus for $2 Billion, did you expect Facebook to betraying the customer's trust and start pushing Facebook logins?
The Oculus / Facebook login thin just happened weeks ago. Companies betraying the promises they made to their core audience is like... bread-and-butter at this point (and seems to almost always happen after an acquisition play). We know Facebook's modus operandi, and even if its worse for Oculus, we know that Facebook will do what Facebook does.
Similarly, we know NVidia's modus operandi. NVidia is trying to make a datacenter play and create a vertical company for high-end supercomputers. Such a strategy means that NVidia will NOT play nice with their rivals: Intel or AMD. (And the Mellanox acquisition is just icing on the cake now).
NVidia will absolutely leverage ARM to gain dominance in the datacenter. That's the entire point of this purchase.
--------
There's a story about scorpions and swimming with one on your back. I'm sure you've heard of it before. Just because its necessary for the scorpion's survival doesn't mean it is safe to trust the scorpion.
I'm not at all surprised they killed Solaris. Given that Oracle was pretty much the only software that ran on Solaris (or that there might be a good reason to run on Solaris), maybe it was just a big support headache. As for MySQL? Not surprised at all. They pretty much just bought a brand name, maybe just to spite red hat.
> Or more recently, when Facebook bought Oculus for $2 Billion, did you expect Facebook to betraying the customer's trust and start pushing Facebook logins?
yes? I mean that felt eminently possible from the get-go.
>When Oracle purchased Sun Microsystems for $7.4 Billion, did you expect Oracle
Yes, yes, and yes. This is Oracle we're talking about. Of course they'll invest more in lawyers than tech. The only reason they still invest in Java is the lawsuit potential. If only Google had the smarts to buy Sun instead...
As for NVidia, their play probably is integration and datacenters. At the moment, going after other ARM licencees will hinder NVidia more than help (they're going after x86, no time to waste on bad PR and legal issues with small time ARM datacenter licencees; Qualcomm and Apple are in a different segment altogether). Of course, we can't guarantee it stays that way.
It wouldn't have been good if any of the people who could actually afford to buy ARM did so.
Would you rather have TSMC in control of ARM? Maybe have access to new architectures bundled with a mandate that you have to build them on TSMC's processes?
How about Samsung? All of the fab ownership concerns of TSMC plus they also make basically any tech product you care to name, so all the integration concerns of NVIDIA.
Could Apple hypothetically use their perpetual license to ARM to license the ISA to other manufacturers if they so desired? (not that they do now, but it could be a saving grace if Nvidia assimilated ARM fully).
I'm pretty sure they can't, but I also think there's no way in hell they'd do it if they could. It's not in Apple's DNA. Better for them if no one else has access to the instruction set.
I bet they'd make a completely custom ISA if they could. Heck, maybe they plan to some day, and that's why they're calling the new Mac processors "Apple Silicon".
> I bet they'd make a completely custom ISA if they could. Heck, maybe they plan to some day, and that's why they're calling the new Mac processors "Apple Silicon".
That was my first thought.
I'd be surprised if Apple wasn't already working on this.
I could see apple being the next in line of basically failed VLIW ISAs - the cost/benefit doesn't really add up to completely redesign, prove, implement, and support a new ISA unless it was worth it technologically.
If they could pull it off I would be very impressed.
Thinking about that though, from a technical perspective keeping the name but changing the function would only produce bad PR.
- "We changed from the 68K to PPC" "Agh!...fine"
- "We changed from PPC to x86" "What, again?"
- "We changed from x86 to Apple Silicon" "...oooo...kay..."
- "We changed from Apple Silicon to, uh, Apple Silicon - like it's still called Apple Silicon, but the architecture is different" "What's an architecture?" "The CPU ISA." "The CPU is a what?"
Wow, this is tectonic. I cannot wait to see how this redraws the competition map. There are dozens of major embedded semi vendors that license Arm IP. Nvidia could eradicate them trivially.
GAAP is an accounting set of rules, EPS is Earning per Share. Basically means they think it will increase their gross margin and EPS but you can't sue them if it does not.
Non-GAAP -> doesn’t follow generaly accepted accounting practices. There are alternative accounting methods. GAAP is very US-centric (not good or bad, just stating a fact).
You are correct that it means they expect margins to increase. One possibility is that ARM has higher margins as you mentioned. Another is that they are making some assumptions about how much they can reduce certain expenses by, and once you factor in those savings, margins go up.
This is awful. Out of all the big tech companies, Nvidia is probably least friendly to open source and cross-platform comparability. It seems to me that their goal is to monopolize AI hardware over the next 20 years, the same way Intel effectively monopolized cloud hardware over the last 20. Expect to see less choice in the chip market and more and more propietary software frameworks like CUDA. A sad day for CS and for AI.
The key difference between a TPU and a GPU is that a TPU has a CPU. It's an entire computer, not just a piece of hardware. Is nVidia moving in that direction?
In term of cutting edge tech, They have their own GPUs, CPUs from ARM, Networking from Mellanox, so I'd say they're pretty much set to build a kick ass TPU.
I don't know where all of this misinformation is coming from or why, but, as someone who has spent the last year programming TPUs to do all kinds of things that a GPU can't do, this isn't true.
Are we going to simply say "Nu uh" at each other, or do you want to throw down some specific examples so I can show you how mistaken they are?
Please show me the API where I can write a generic function on a TPU. I'm talking about writing something like a custom reduction or a peak search, not offloading a tensor flow model.
I'll make it easier for you, directly from Google's website:
TPUs
Cloud TPUs are optimized for specific workloads. In some situations, you might want to use GPUs or CPUs on Compute Engine instances to run your machine learning workloads.
Please tell me a workload a gpu can't do that a TPU can.
In my experience, well over 80% of these operations are implemented on TPU CPUs, and at least 60% are implemented on TPU cores.
Again, if you give a specific example, I can simply write a program demonstrating that it works. What kind of custom reduction do you want? What's a peak search?
As for workloads that GPUs can't do, we regularly train GANs at 500+ examples/sec across a total dataset size of >3M photos. Rather hard to do that with GPUs.
Well, there you go. For one TensorFlow is not a generic framework like cuda is, so you lose a whole bunch of the configurability you have with cuda. So, for example, even though there is an FFT raw function, there doesn't appear to be a way to do more complicated FFTs, such as an overlap-save. This is trivial to do on a GPU, and is built into the library. The raw functions it provides is not direct access to the hardware and memory subsystem. It's a set of raw functions that is a small subset of the total problem space. And certainly if you are saying that running something on a TPU's CPU cores are in any way going to compete with a gpu, then I don't know what to tell you.
You did not give an example of something GPUs can't do. all you said was that TPUs are faster for a specific function in your case.
For one TensorFlow is not a generic framework like cuda is, so you lose a whole bunch of the configurability you have with cuda
Why make generalizations like this? It's not true, and we've devolved back into the "nu uh" we originally started with.
This is trivial to do on a GPU, and is built into the library
Yes, I'm sure there are hardwired operations that are trivial to do on GPUs. That's not exactly a +1 in favor of generic programmability. There are also operations that are trivial to do on TPUs, such as CrossReplicaSum across a massive cluster of cores, or the various special-case Adam operations. This doesn't seem related to the claim that TPUs are less flexible.
The raw functions it provides is not direct access to the hardware and memory subsystem.
Jax is also going to be giving even lower-level access than TF, which may interest you.
You did not give an example of something GPUs can't do. all you said was that TPUs are faster for a specific function in your case.
Well yeah, I care about achieving goals in my specific case, as you do yours. And simply getting together a VM that can feed 500 examples/sec to a set of GPUs is a massive undertaking in and of itself. TPUs make it more or less "easy" in comparison. (I won't say effortless, since it does take some effort to get yourself into the TPU programming mindset.)
I gave you an example of something you can't do, which is an overlap-save FFT, and you ignored that completely. Please implement it, or show me any example of someone implementing any custom FFT that's not a simple, standard, batched FFT. I'll take any example of implementing any type of signal processing pipeline on TPU, such as a 5G radio.
Your last sentence is pretty funny: a GPU can't do certain workloads because one it can do is too slow for you. Yet it remains a fact that TPU cannot do certain workloads without offloading to the CPU (making it orders of magnitude slower), and that's somehow okay? It seems where this discussion is going is you pointed to a TensorFlow library that may or may not offload to a TPU, and it probably doesn't. But even that library is incomplete to implement things like a 5G LDPC decoder.
You'll need to link me to some specific implementation that you want me to port over, not just namedrop some random algorithm. Got a link to a github?
If your point is "There isn't a preexisting operation for overlap-save FFT" then... yes, sure, that's true. There's also not a preexisting operation for any of the hundreds of other algorithms that you'd like to do with signal processing. But they can all be implemented efficiently.
Yet it remains a fact that TPU cannot do certain workloads without offloading to the CPU (making it orders of magnitude slower), and that's somehow okay?
I think this is the crux of the issue: you're saying X can't be done, I'm saying X can be done, so please link to a specific code example. Emphasis on "specific" and "code".
Let's just leave this one alone then. I can't argue with someone who claims anything is possible, yet absolutely nobody seems to be doing what you're referring to (except you). A100 now tops all MLPerf benchmarks, and the unavailable TPUv4 may not even keep up.
Trust me, I would love if TPUs could do what you're saying, but they simply can't. There's no direct DMA from the NIC to where I can do a streaming application at 40+Gbps to it. Even if TPU could do all the things you claim, if it's not as fast as the A100, what's the point? To go through undocumented pain to prove something?
FWIW, you can stream at 10Gbps to TPUs. (I've done it.)
10Gbps isn't quite 40Gbps, but I think you can get there by streaming to a few different TPUs on different VPC networks. Or to the same TPU from different VMs, possibly.
The point is that there's a realistic alternative to nVidia's monopoly.
I'm a TPU user and I'd be interested to see a specific example of something that can be done on TPU but not GPU.
Perhaps I'm just not experienced enough with the programming model, but I've found them to be strictly less flexible/more tricky than GPUs, especially for things like conditional execution, multiple graphs, variable size inputs and custom ops.
The central reason that TPUs feel less flexible is Google's awful mistake in encouraging everyone to use TPUEstimator as the One True API For Doing TPU Programming. Getting off that API was the single biggest boost to my TPU skills.
You can run basically any C program on a CUDA core even those requiring malloc. It may not be efficient but you can do it. Google themselves call GPUs general purpose and TPUs domain specific. https://cloud.google.com/blog/products/ai-machine-learning/w...
no they are not. Go read recent MLPerf results more carefully and not Google’s blogpost.
NVIDIA won 8/8 benchmarks for publicly available SW/HW combo. Also 8/8 on per chip performance.
Google did show better results with some “research” system which is not available to anyone other then them yet.
This is a weirdly aggressive reply. I don't "read Google's blogpost," I use TPUs daily. As for MLPerf benchmarks, you can see for yourself here: https://mlperf.org/training-results-0-6 TPUs are far ahead of competitors. All of these training results are openly available, and you can run them yourself. (I did.)
For MLPerf 0.7, it's true that Google's software isn't available to the public yet. That's because they're in the middle of transitioning to Jax (and by extension, Pytorch). Once that transition is complete, and available to the public, you'll probably be learning TPU programming one way or another, since there's no other practical way to e.g. train a GAN on millions of photos.
You'd think people would be happy that there are realistic alternatives to nVidia's monopoly for AI training, rather than rushing to defend them...
You are basing your opinion on last year MLPerf and some stuff that may or may not be available in the future. MLPerf 0.7 "available" category has been ghosted by google.
I checked MLPerf website, and it looks like A100 is outperforming TPUv3, and is also more capable (there does not seem to be a working implementation of RL for Go on TPU).
To be fair, TPUv4 is not out yet, and it might catch up using the latest processes (7nm TSMC or 8nm Samsung).
Hardly sleeping, they have a fraction of the revenue and profit of NVidia and Intel. Revenue was half of Nvidia, profit was 5% of NVidia. Intel is even bigger. They only have so much in the way of R&D money.
ROCm is their product for compute and it still can't run on their latest NAVI cards which have been out for over a year while CUDA works on every nvidia card on day one.
> Revenue was half of Nvidia, profit was 5% of NVidia.
For operating income it's 25%, for net income it's 18%; not 5%.
Last four quarters operating income for AMD: $884 million
Last four quarters operating income for Nvidia: $3.5 billion
This speaks to the dramatic improvement in AMD's operating condition over the last several years. For contrast, in fiscal 2016 AMD's operating income was negative $382 million. Op income has increased by over 300% in just ~2 1/2 years. Increasingly AMD is no longer a profit lightweight.
AMD 2019 Profit (as earnings per share): $0.30 [1]
NVIDIA 2019 Profit (as earnings per share): $6.63 [2]
4.52%, rounds to 5%, as I said.
However, you still proved my point. Lightweight or not, they do not, and have not had the amount of money available compared to NVidia and Intel. It's growing, they'll be able to continue to invest, and they have an advantage in the CPU space that should last for another year or two, giving them a great influx of cash, and their focus on Zen 2 really paid off allowing them greater cash flow to focus on GPUs as well.
> AMD 2019 Profit (as earnings per share): $0.30 [1] NVIDIA 2019 Profit (as earnings per share): $6.63 [2]
> 4.52%, rounds to 5%, as I said.
You're misunderstanding how to properly compare profitability between two companies.
If Company A has 1 billion shares outstanding and earns $0.10 per share, that's $100m in profit.
If Company B has 10 billion shares outstanding and earns $0.05 per share, that's $500m in profit.
Company A is not 100% larger on profit just because they earned more per share. It depends on how many shares you have outstanding, which is what you failed to account for.
AMD's profit was not close to 5% of Nvidia's in 2019. That is what you directly claimed (as you're saying you went by the last full fiscal year).
AMD had $341m in net income in their last full fiscal year. Nvidia had $2.8 billion in net income for their last full fiscal year. That's 12%, not 5%. And AMD's operating income was 22% of Nvidia for the last fiscal year.
The trailing four quarters and operating income, is the superior way to judge the present condition of the two companies, rather than using the prior fiscal year. Especially given the rapid ongoing improvement in AMD's business. Regardless, even going by the last full fiscal year, your 5% figure is still wrong by a large amount.
Operating income is a key measure of profitability and it's a far better manner of gauging business profitability than net income at this point. That's because the modern net income numbers are partially useless as they will include such things as asset gains/losses during the quarter. If you want to read up more on it, Warren Buffett has pointed out the absurdity of this approach on numerous occasions (if Berkshire's portfolio goes up a lot, they have to report that as net income, even though it wasn't a real profit generation event).
I didn't say anything refuting your revenue figures, because I wasn't refuting them. I'm not sure why you mention that.
Earnings per share is only useful when you look at the stock price. Since number of outstanding shares are different between two companies, it's incorrect to measure company's profit based on EPS.
NVIDIA’s hardware works on x86, PowerPC, and ARM platforms.
Many of their AI libraries/tools are in fact open source.
They stand to be a force that could propel ARM’s strength in data center and desktop computing. For some reason you’re okay with the current x86 duopoly held by AMD and Intel, both who have their own destiny over CPUs and GPUs.
The HN crowd is incredibly biased against certain companies. Why not look at some of the potential bright sides to this for a more nuanced and balanced opinion?
There are good points on both sides; as a Linux user, I feel the effects of their proprietary drivers and uncooperative approach, while I can also appreciate that they've managed to work with the Gnome and KDE project to have some support under Wayland, and the contributions they've made to the
machine learning communities. Ad a whole, I do think that the former outweighs the latter, and loath the acquisition, but do think that the resources they're packing will bring ARM to new heights for the majority users.
That's because they implemented egl streams, nothing has changed majorly since then. There's been a lot of talk, but no action towards unification. The ball is entirely in Nvidia's court and they continue to work together on this.
The funny thing about GBM vs EGLStreams, though, based on everything I’ve read online, is that there’s broad agreement that EGLStreams is the technically superior approach - and that the reason it’s been rejected by the Linux graphics devs is GBM, while inferior, has broad hardware vendor support. Apparently very few GPU vendors outside the big 3 had decent EGl implementations.
That's not true. EGLStreams would be better suited to Nvidia's proprietary driver design, but it's technically inferior. This is the "broad agreement". No one but Nvidia wants EGLStreams, or we would have implemented it in other drivers.
Yes I wonder the same thing about the sentiment against nvidia. It’s be helpful if there were some wiki about things they’ve killed or instances they’ve acted against foss systems.
"linus went on a hyperbolic rant" isn't sufficient evidence for anything.
linus is a hyperbolic jerk (as he admitted himself for a few months before resuming his hyperbolic ways) who is increasingly out of touch with anything outside the direct sphere of his projects. Like his misguided and completely unnecessary rants about ZFS or AVX.
if there are technical merits to discuss you can post those instead of just appealing to linus' hyperbole.
(I won't even say "appeal to authority" because that's not what you're appealing to. You're literally appealing to his middle finger.)
The notion that the maintainer if Linux has a narrow focus role that isn't capable of advocating and serving the broader community is belied by the fact that Linux has grown from being a niche hobbyist platform to the de facto cloud standard OS.
/shrug. The guy can't keep from popping off with obviously false statements about things he knows nothing about. What exactly do you want me to say? Yes, he's been a good manager for the linux kernel, but he is self-admittedly hyperbolic and statements like these show that he really doesn't have an issue running his mouth about things that he really doesn't understand.
It is the old problem with software engineers: they think expertise in one field or one area makes them a certified supergenius with relevant input in completely unrelated areas. I can't count how many times I've seen someone on HN suggest One Weird Trick To Solve Hard Problems in [aerospace/materials sciences/etc]. Linus suffers from the same thing.
His experiences with NVIDIA are probably relevant, and if so we can discuss that, but the fact that he gave someone the middle finger in a Q+A session is not. That's just Linus being an asshole.
(and him being a long-term successful project manager doesn't make him not an asshole either. Jensen's an asshole and he's one of the most successful tech CEOs of all time. Linus doesn't mince words and we should do the same - he's an asshole on a professional level, the "I'm just being blunt!" schtick is just a nice dressing for what would in any other setting be described as a textbook toxic work environment, and his defenses are textbook "haha it's just locker room talk/we're all friends here" excuses that people causing toxic work environment are wont to make. He knows it, he said he'd tone it down, that lasted about a month and he's back to hyperbolic rants about things he doesn't really understand... like ZFS and AVX. But hey I guess they're not directed at people this time.)
Again, if he's got relevant technical input we can discuss that but "linus gives the middle finger!!!!" is not the last word on the topic.
He just responded to a complaint that nVidia hardware wasn't working with "nVidia is the worst company we've dealt with". I don't think that's "out of touch", it's pretty much the kind of stuff his job description entails. If you don't like his style, fair enough, but if the leader of a project says "company X is the worst company we deal with" then that doesn't inspire a whole lot of confidence.
AFAIK the debate was mostly settled by NVIDIA submitting their own EGLStreams backend for Wayland (that promptly exposed a bunch of Wayland bugs). So difficult to work with, that NVIDIA, asking to do something different and then submitting their own code to implement it!
AFAIK it also ended up being literally a couple thousand lines of code, not some massive endeavor, so the Wayland guys don’t come off looking real great, looks like they have their own Not Invented Here syndrome and certainly a lot of generalized hostility towards NVIDIA. Like Torvalds, I'll be blunt, my experience is that a lot of people just know NVIDIA is evil because of these dozens of little scandals they’ve drummed up, and they almost all fall apart when you look into them, but people just fall back on asserting that NVIDIA must be up to something because of these 27 other things (that also fall apart when you poke them a bit). It is super trendy to hate on NVIDIA in the same way it’s super trendy to hate on Apple or Intel.
Example: everyone used to bitch and moan about G-Sync, the biggest innovation in gaming in 10 years. Oh, it's this proprietary standard, it's using a proprietary module, why are they doing this, why don't they support the Adaptive Sync standard? Well, at the time they started doing it, Adaptive Sync was a draft standard for power-saving in laptops that had languished for years, there was no impetus to push the standard through, there were no monitors that supported it, and no real push to implement monitors either. Why take 10 years to get things through a standards group when you can just take a FPGA and do it yourself? And once you've done all that engineering work, are you going to give it away for free? Back in 2016 I outright said that sooner or later NVIDIA would have to support Adaptive Sync or else lose the home theater market/etc as consoles gained support. People told me I was loony, "NVIDIA'S just not that kind of company", etc. Well, turns out they were that kind of company, weren't they? Turns out people were mostly mad that... NVIDIA didn't immediately give all their engineering work away for free.
The GPP is the only thing I’ve seen that really stank and they backed off that when they saw the reaction. Other than that they are mostly guilty of... using a software license you don’t like. It says a lot about the success of copyleft that anyone developing software with a proprietary license is automatically suspect.
The truth is that NVIDIA, while proprietary, does a huge amount of really great engineering in novel areas that HNers would really applaud if it were any other company. Going and making your own monitor from scratch with a FPGA so you can implement a game-changing technology is exactly the kind of go-getter attitude that this site is supposed to embody.
Variable refresh rate/GSync is a game changer. DLSS 2.0 is a game changer. Raytracing is a game changer. And you have NVIDIA to thank for all of those, "proprietary" and all. They would not exist today without NVIDIA, AMD or Intel would not have independently pushed to develop those, even though they do have open-source drivers. What a conundrum.
"AFAIK". Your rant is wrong in so many levels it's not even funny.
Nvidia earned that hostility. It's not even worth replying when you're giving a comment in such bad faith. There's a search function with many many threads that dealt with this subject before if anyone wants a less biased view of EGLStream and Wayland.
I'm not sure if Linus was talking about the Wayland stuff specifically; the answer was in response to a complaint that the nvidia/Intel graphics card switching didn't work on Linux.
I haven't used nvidia products for about 10 years and I'
m not really in to gaming or graphics, so I don't really have an opinion on them either way, either business or technical. I used their FreeBSD drivers back in the day and was pretty happy it allowed me to play Unreal Tournament on my FreeBSD machine :-)
Linus is not always right, but a lot of what he says is often considerably more nuanced and balanced than his "worst-of" highlight reel suggests. There are plenty of examples of that in the presentation/Q&A he did from which this excerpt comes, for example (but of course, most people only see the "fuck you" part).
So if Linus – the person responsible for writing operating systems with their hardware – says they're the "worst company we deal with" then this strikes me as a good reason to at least do your research if you plan to buy hardware from them, if you intend to use it with Linux anyway. I'll take your word for it that they're doing great stuff, but if it outright refuses to work on my Linux box then that's kinda useless to me.
This was also 6 or 7 years ago I think, so perhaps things are better now too.
Thank you for this comment. I learned quite a bit! As an investor it makes sense to go with a company that takes the profit for a renovation for a while.
The OP said nothing about being ok with the x86 duopoly.
Its possible to dislike two things at once, its also possible to be wary of new developments that give much more market power to a notoriously uncooperative and closed company.
> The HN crowd is incredibly biased against certain companies.
No kidding, regarding the HN crowd. -- every time I post a comment criticizing Apple's monopoly and policies I get downvoted to oblivion, and I'd say that some of the things they do e.g. on the Apple store and proprietary hardware/software combinations are far more egregious than anything Nvidia has ever done. The HN algorithm basically encourages an echo chamber of people who gang up and downvote/flag others who don't agree with the gang opinion.
(Psst ... If you see this comment disappear after a while, it's probably because the same Apple fanboys found this comment and decided to hammer it down again.)
Haven't looked at the rest of your posts, but if this gets flagged, it's probably from this:
[Edit: I disagree with my past self of having put this comment here. This is something that if one feels that they notice, they should probably comment on. Leaving it here for clarity's sake]
> The HN algorithm basically encourages an echo chamber of people who gang up and downvote/flag others who don't agree with the gang opinion.
or this:
> (Psst ... If you see this comment disappear after a while, it's probably because the same Apple fanboys found this comment and decided to hammer it down again.)
than this:
> criticizing Apple's monopoly and policies
Source: Have criticized Apple without having been downvoted and flagged.
I think it depends on how you criticize them. I've criticized:
- The idea that we can trust Apple with privacy, when their OS isn't open source
- The idea that the Apple Store is doing good things in the disguise of privacy when they actually play corporate favoritism and unfairly monopolize the app market
- The idea that a PIN has enough entropy to be a good measure of security
- Right to repair, soldered-to-motherboard SSDs
- The environmental waste associated with the lack of upgradability
- Price gouging on upgrades ($400 for +512GB, anyone? When I can get 4TB on Amazon for $500?) and lack of user upgradability
I've been downvoted to hell for speaking the above. There are a bunch of brainwashed Apple worshippers lurking around here who don't accept any criticism of the holy.
I totally welcome engaging in an intelligent discussion about any of the above, but downvotes and flagging (in most cases without any response) doesn't accomplish any of that, and serves just to amplify the fanboy echo chamber.
Also, I don't think criticizing HN's algorithm or design should warrant being flagged or downvoted, either.
Downvoting should be reserved for trolling, not intelligent protest. I'm also of the opinion that downvotes shouldn't be used for well-written disagreement, as that creates an echo chamber and suppresses non-majority opinions.
> I've been downvoted to hell for speaking the above.
Fair enough. I don't think I've ever mentioned Apple by name, just participated in threads about them and commented on how I disagree about how they do some things.
I also went and reread some of my comments, and realized I haven't criticized Apple as much here as I'd originally thought. Apparently I mostly stick to that in meatspace.
> There are a bunch of brainwashed Apple worshippers lurking around here who don't accept any criticism of the holy.
As there are everywhere unfortunately. I haven't run into many here personally, but have no difficulty believing they are here.
> Also, I don't think criticizing HN's algorithm or design should warrant being flagged or downvoted, either. Downvoting should be reserved for trolling, not intelligent protest. I'm also of the opinion that downvotes shouldn't be used for well-written disagreement, as that creates an echo chamber and suppresses non-majority opinions.
I agree here as well. I was more trying to point out the combative tone then the content of the text. There was also some content that could be interpreted as accusations of shilling, which is technically against the guidelines.
To be clear -- I don't think your comment was accusing people of shilling, just that I can see how people could interpret it that way.
Edit: The first quote I took from your comment really shouldn't have been there. Sorry about that. I still think if you get flagged it's because of the "(Psst..." part though. That one does come off as a bit aggressive.
This is off topic and breaks the site guidelines. Would you please review them and stick to the rules?
This sort of $BigCo metaflamewar in which each side accuses HN of being shills for the opposite side is incredibly repetitive and tedious. It's also a cognitive bias; everyone feels like the community (and the moderators for that matter) is biased against whatever view they favor.
I don't really have an opinion on nVidia, as I haven't dealt with any of their products for over a decade; my own problem with this is somewhat more abstract: I'm not a big fan of this constant drive towards merging all these tech companies (or indeed, any company really). Perhaps there are some short-term advantages for the ARM platform, but on the long term it means a few small tech companies will have all the power, which doesn't strike me as a good thing.
I'm not so sure about that second point; I don't see why an independent ARM couldn't provide an effective competition? Server ARMs have been a thing for a while, and Apple has been working on ARM macbooks for a while. I believe the goal is even to completely displace Intel macBooks in favour of the ARM ones eventually.
The big practical issue is probably software compatibility and the like, and it seems to me that the Apple/macOS adoption will do more for that than nVidia ownership.
Hyperbole is how you get upvotes. No one really reacts to wishy-washy answers, it's the "OMG world is ending" provocative stuff that gets people engaged.
Surprisingly - they have a working driver for FreeBSD. Never had an issue with it - and the performance is fantastic. As far back as early 2000's I remember installing proprietary nvidia drivers on Linux and playing UT2004.
Maybe Nintendo/Sony uses Nvidia cards on their developer machines? I imagine FreeBSD drivers aren't simply altruism on their part.
On the other hand, stagnation on other fronts:
- Nouveau (tried recently) is basically unusable on Ubuntu. As in the mouse/keyboard locks every 6 seconds.
- Proprietary drivers won't work with wayland
And since their stuff isn't open, the community can't do much to push Nouveau forward.
Nvidia's "Blob" approach does have an advantage when it comes to supporting random OSes.
It's less of a driver and more of an operating system. Basically self-contained with all the support libraries it needs. Super easy to port to a new operating system and any driver improvement work on all OSes.
But the approach also has many downsides. It's big. It ignores all the native stuff (like linux's GEM interface).
It also has random issues with locking up the entire system. Like if you are debugging a process with the linux drivers, a breakpoint or a pause in the wrong place can deadlock the system.
Native Linux stuff is not at all native for FreeBSD. If Nvidia suddenly decides to open their driver (to merge it into Linux), FreeBSD and Solaris support will be the first thing thrown out.
You say that, but: Nvidia's "blob" driver doesn't have CUDA, NVENC/NVDEC, nor DDC I2C support on FreeBSD — despite all of this functionality being specific to Nvidia's own hardware, and the support being present in the Linux blob, which runs on a relatively similar platform.
If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.
> If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.
In fact it is. For Linux and FreeBSD Nvidia distributes exactly the same blob for compilation into nvidia.ko; the blobs for nvidia-modeset.ko are slightly different. (Don't take my word for it, download both drivers and compare kernel/nvidia/nv-kernel.o_binary with src/nvidia/nv-kernel.o.) Nothing is locked in the closed source part.
The userspace CUDA/NVENC libraries are distributed as pre-compiled artifacts in the Linux driver, and no such FreeBSD library is distributed in the FreeBSD driver package.
Not just developer machines e.g. the Nintendo Switch uses an Nvidia Tegra X1 and run FreeBSD. Lots of game consoles do, you don't have to worry about the GPL.
I thought the switch ran a modified form of android, but just looked it up and found this on the Switch Wikipedia page:
> Despite popular misconceptions to the contrary, Horizon [The switch software's codename] is not largely derived from FreeBSD code, nor from Android, although the software licence[7] and reverse engineering efforts[8][9] have revealed that Nintendo does use some code from both in some system services and drivers.
That being said, at least one of the Playstation's runs a modified form of FreeBSD.
The FreeBSD blob driver will drive a monitor, but it lacks a bunch of GPU hardware support the Linux one has: all of CUDA, NVENC/NVDEC, I²C DDC, and certainly more.
On the other hand, if Nvidia wants ARM to succeed (and why else would they acquire it?), they can be a source of more competition in the CPU market.
I don't really see how this deal makes the CPU market worse -- wasn't the ARM market for mobile devices basically dominated by Qualcomm for years? Plus, the other existing ARM licensees don't seem to be impacted. On the other hand, I do see a lot of potential if Nvidia is serious about innovating in the CPU space.
This seems fair, as long as it stays true(regarding open licensing and neutrality). I've mentioned before, I think this will ultimately be a good thing. NVidia has the gpu chops to really amp up the reference implementation, which is a good thing for competition in the mobile, settop, and perhaps even desktop space.
No, what everyone thinks will happen is a pretend open ARM architecture and Nvidia CPUs dominating. Nvidia isn’t going to license the best GPU features they start adding.
It’s an excellent deal for NVIDIA of course, I’m certain they intend to make the chips they produce much faster than the ones they license (if they even ever release another open design) to the point where buying CPUs from Nvidia might be they only game in town. We’ll have to see but this is what I expect to happen.
Perhaps not. I mean AMD and soon Intel basically compete with themselves by pushing advances in both discrete GPU and APU at the same time, one negating the need for the other.
I'm not claiming I'm right and you're wrong, of course. I just think it's unfair to make negative assumptions at this point, so wanted to paint a possible good thing.
NVIDIA already has an CPU architect team building their own ARM CPUs with an unlimited ARM license.
ARM doesn't give NVIDIA a world-class CPU team like apple's, amazon's or fujitsu. ARM own cores are "meh" at best. Buying such a team, would also have been much cheaper than 40b$.
Mobile ARM chips are meh, but nvidia doesn't have GPUs for that segment, and their current architectures probably don't work well there. The only ARM chips that are ok-ish are embedded/IoT at < 1W power envelope. It would probably take nvidia 10 years to develop GPUs for that segment, the margins on that segment are razor thin (0.10$ is the cost of a full SoC on that segment), and it is unclear whether applications on that segment need GPUs (your toaster certainly does not).
The UK appears to require huge R&D investments in ARM to allow the sale. And ARMs bottom line is 300million $/year in revenue, which is peanuts for nvidia.
So if anything, ARM has a lot to win here with nvidia pumping in money like crazy to try to improve ARM's CPU offering. Yet this all seem super-risky because at the segments ARM is competing at, RISC-V competes as well, and without royalties. It is hard to compete against something that's free, even if it is slightly less good. And chances are that over the next 10 years RISC-V will have much better cores (NVIDIA themselves started replacing ARM cores with RISC-V cores in their GPUs years ago already...).
Either way, the claim that it is obvious to everybody what the 3D-chess being played here is false. To me this looks like a bad buy for nvidia. They could have paid 1 billion for a world class CPU team and just continue to license ARM and/or switch to RISC-V chips. Instead they are spending 40 billion in a company that makes 300 million a year, makes meh-cpus, is heavily regulated in the UK and the world, has problems with China due to being in the West, have to invest in the UK which is leaving the EU in a couple of weeks, etc.
No. Precisely the Tegra SoC within the Nintendo Switch (X1) uses ARM Cores. Specifically A57 and A53. NVIDIA's project to develop their own v8.2 ARM-based chip is called Denver.
What do you define the difference between an in-house developed SoC with ARM-IP Cores and Denver's "ARM-based chip"? It is going to be a new architecture, but using a mix of ARM IP blocks and in-house IP following the ARM ISA?
It’s a bad buy unless they plan to use this to leverage a better position. Your argument is that ARM is essentially worthless to NVIDIA or at least extremely high $40bn bet. I guess only time will tell but I think NVIDIA intend to make their money back on this purchase and that won’t be through the current licensing model (as your own figures show).
If you only look at today's numbers, it doesn't make a ton of sense. But looking at the market, the world is moving -more- towards ARM, not away. The last couple years have given us ARM in a gaming console, ARM in mainstream laptops, ARM in the datacenter. Especially as the world strives to go 'carbon neutral', ARM kills everything from Intel/AMD. So with that in mind, I don't think it's a bad buy, but time will tell.
RISC-V and ARM can coexist, but RISC-V in the mainstream is a far away due to nothing more than momentum. People won't even touch Intel in a mobile device anymore, not just because of power usage, but software compatibility.
This has been out there in the news for well over a month, I guess I don't understand why Apple didn't try to make a bid for ARM? Or why Apple didn't try to set up some sort of independent holding company or consortium to buy ARM. They definitely have the money and clout to have done something like that.
ARM and Apple go way back (Apple was one of the three original consortium members who founded ARM). I am sure they pay a flat fee and have freedom to do whatever they like (probably other than sub licensing).
Owning ARM would make no sense for them as they would gain no IP but would have to deal with antitrust which would force them to continue licensing the ip to others, which is not a business they are in.
If ARM vanished tomorrow I doubt it would affect apple’s business at all.
I doubt Apple's arm license will be affected. But I think they will be getting tougher competition in the sense that Android phones will be getting a fair bit better now - most of them will be using super well integrated Nvidia GPU/ML chips in the future because of this deal.
I think it will also bring Google and Nvidia closer together
Yes, but the Brexit referendum was only 1 month before SoftBank acquired Arm Holdings. The deal was probably already in progress, and finalised before the UK had any real policies about Brexit, so EU requirements would have been reasonable if decided ahed of time. But the timing may also explain the lack of any national security focused requirement (general confusion).
I'm so exercised about this that I'm setting up a think tank to actively discuss UK control of critical tech (and "golden geese" as per others in this thread). If you're in tech and have a problem with this, please drop me a line, I'm @bencollier on Twitter.
Britain and the US are politically, and economically entwined with each other. As a country, keeping core technology at home is tied to defense (don't buy your guns from your competitor). If they don't intend to go to war with the US, then there isn't any real defense loss (I'd also point out that making IP "blueprints" for a core is different from manufacturing the core itself). If Britain were to have a real issue, it would be the US locking down F35 jets they sell to their allies.
This isn't going to do good things for anyone who doesn't own a lot of Nvidia stock.
This is going to do especially bad things for anyone who needs to buy a cell phone or the SoC that powers one. There's no real alternative to ARM-based phone SoCs. Given Nvidia's business practices, any manufacturer who doesn't already have a perpetual ARM license should expect to have to pay a lot more money into Jensen Huang's retirement fund going forward. These costs will be passed on to consumers and will also provide an avenue for perpetual license holders to raise their consumer prices to match.
Android still works on x86-64; indeed there are quite a few actively maintained x86-64 Android ports that are used, both on bare metal PCs and virtualized, for various purposes.
The problem is that there are no x86 SoCs that are sufficiently power efficient to be battery-life competitive with ARM SoCs in phones.
You would first need an actual working RISC-V silicon that it would be worth porting to. Not the essentially demo chips with poor performance that are around now.
RISV-V is a lot of talk and hype but the actual silicon that you could buy and implement into a product is hard to come by. With the exception of a few small microcontroller efforts (GigaDevice, Sipeed).
MIPS support was removed from the Android NDK, though older versions of the NDK stand a good chance of working, still. So app developers with components needing the NDK support have a bit of work to remain compatible.
Well, the commenter is actively worried about Nvidia destroying shareholder value. If you destroy ARM in the process of acquiring it the combined company will be worth less in the long run. If the acquisition was actually motivated by synergy then Nvidia could have gotten away with a much cheaper license from ARM.
> Huang told me that first thing that the combined company will do is to, “bring NVIDIA technology through Arm’s vast network.” So I’d expect NVIDIA GPU and NPU IP to become available quickly to smartphone, tablet, TV and automobile SoC providers as quickly as possible.
> Arm CEO Simon Segars framed it well when he told me, “We're moving into a world where software doesn't just run in one place. Your application today might run in the cloud, it might run on your phone, and there might be some embedded application running on a device, but I think increasingly and with the rollout of 5g and with some of the technologies that Jensen was just talking about this kind of application will become spread across all of those places. Delivering that and managing that there's a huge task to do."
> Huang ... “We're about to enter a phase, where we're going to create an internet that is thousands of times bigger than the internet that we enjoy today. A lot of people don't realize this. And so, so we would like to create a computing company for this age of AI.”
This is NVIDIA's "xbox one/PS4" moment. AMD has deals with console manufacturers, their clients pay for a huge amount of R&D that gets ported back into AMD's desktop graphics architecture. Even if AMD doesn't make basically anything on the consoles themselves, it's a huge win for their R&D.
Now, every reference-implementation ARM processor manufactured will fund GeForce desktop products, datacenter/enterprise, etc as well.
NVIDIA definitely needs something like this in the face of the new Samsung deal, as well as AMD's pre-existing console deals.
> Now, every reference-implementation ARM processor manufactured will fund GeForce desktop products, datacenter/enterprise, etc as well.
That's like throwing pennies onto a pile of gold. NVIDIA makes billions of yearly revenue. ARM makes ~300 million. NVIDIA revenue is 60% of a GPU price. ARM margins in IoT/embedded/phone chips are thin-to-non-existent. If anything, NVIDIA will need to cut GPU spending to push ARM to the moon. And the announcement already suggest that this will happen.
ARM doesn't make any chips. They license IP (CPU cores and the MALI GPU) needed to build those chips to companies like Apple, Samsung, TI, ST Micro, Microchip, Qualcomm ...
That margins on $1 microcontroller are "thin-to-non-existent" is thus completely irrelevant - those are margins of the silicon manufacturer, not ARM's.
So what's the marging of ARM per chip bought? ARM's IP isn't free. It is created by engineers that cost money. Those chip sell for 0.10$, so ARM's margin's can't be more than 0.10$ per chip, otherwise seller would be operating at a loss.
Console makers dictated that RDNA must use a forward-compatible version of the GCN ISA. While AMD might have wanted to make some changes of some ideas that turned out to be less-than-optimal, they cannot because they are stopped by the console makers paying the bills.
Is the situation better with Mali? This seems something that might actually improve with Nvidia. I was under the impression that ARM GPUs are currently heavily locked down anyway (in terms of open source drivers). Nvidia would presumably still be locked down, but maybe we'd have more uniform cross platform interfaces like CUDA.
Tegra open source support is great and actually supported by NVIDIA. Probably the best ARM GPU option for open source drivers.
Mali support is done by outside groups (not ARM). Midgard and Bifrost models are well supported (anything that starts with a T or G, respectively). Support for older models is a little worse, but better than some other GPUs.
Adreno support is done by outside groups (not Qualcomm) and is lagging behind new GPUs that come out considerably.
PowerVR GPUs (Imagination) have terrible open source support.
Tegra the chipset is supported by Nvidia, but even then they are not a paragon of cooperation with the Linux community. They have their own non-mainlined driver, while the mainlined one (tegra) is done by someone else.
They did contribute somewhat to the "tegra" driver at least.
My instincts are telling me this is smoke and mirrors to rationalize a $40E9 deal. The only part of that that computes at all is the GPU integration, and that only works if NVIDIA doesn't terrorize Arm licencees. The rest is buzzwords.
Makes sense. IoT was a buzzword in 2013. It is now a mature ecosystem and we've gotten a good taste and smell for it. Its on its way towards the plateau of productivity on the Gartner curve if I were to guess.
The sole meaning of the "Gartner Curve" is the amount of money available to be spent on hype, that Gartner can hope to get. It has the most tenuous imaginable relationship with the market for actual, you know, products.
The Gartner Hype Cycle might be branded but the basic delta between overhyped technology vs actual production processes has been observed for a long time.
There's a pretty big assumption that the deal even gets approved.
Even if it does get approved, and even if NVIDIA decides to not screw up any of the licensees, the whole notion of NVIDIA being capable of doing so to any of their (NVIDIA's) competitors, will surely mean extra selling points for all of ARM competitors like MIPS, RISC-V etc.
Arm CEO really doesn't understand what's going on. There is no future where everything runs on the cloud. That simply cannot happen for legal reasons. Additionally the internet is getting more balkanized and that further is against the idea of the cloud. AI will not be running in the cloud, it will be running locally. Apple sees this but many others don't yet. You only run AI in the cloud if you want to monetize it with advertising.
What a death sentence for ARM right there and the start of a starvation in a new microprocessor winter. I guess we now have to wait for RISC-V to catch up.
Aside from that, ARM was one of the only actual tech companies the UK could talk about on the so-called "world stage", that has survived more than 2 decades. But instead, they continue to sell themselves and their businesses to the US instead of vice versa.
In 2011, I thought that they would learn the lessons and warnings highlighted from Eric Schmidt about the UK creating long standing tech companies like FAANMG. [0] I had high hopes for them to learn from this, but after 2016 with Softbank and now this, it is just typical.
ARM will certainly be more expensive after this and will certainly be even more closed-source, since their Mali GPUs drivers were already as closed as Nvidia's GPUs. This is a terrible outcome I have seen but from Nvidia's perspective, it makes sense. From a FOSS perspective, ARM is dead, long live RISC-V.
Once they were sold to SoftBank ARM had no more control over its destiny. You're saying that they're repeating the pattern, but they had no choice in this today. This was SoftBank's decision as the owner of ARM.
Buying a stake in AAPL,FB, or any tech company would have netted higher returns for less effort than buying ARM. If anything, a 25% ROI in 4 years is quite poor.
It's not too early to judge, because this has been in the news for a while and people have had the time to do an analysis of what it means for Nvidia to buy ARM. The press release doesn't add much to that analysis. We've seen a ton of press releases go by for acquisitions and they're always full of sunshine... at the moment, I'm thinking of Oracle's acquisition of Sun, but that's just one example. The typical pattern for acquisitions is that a tech company will acquire another tech company because they can extract more value from the acquired company's IP compared to the value the acquired company would have by itself, and you can extract a lot of value from an IP while you slash development budgets. Not saying that's going to happen, but it's a common pattern in acquisitions.
I think it's enough to know what Nvidia is, how they operate, and what their general strategies are.
Not saying I agree with the analysis... but I am not that optimistic.
One of the (many) synergies in this acquisition is that it's also an acqui-hire for CPU development talent. NVIDIA's efforts in that area have not gone very smoothly. They aren't going to fire all the engineers they just bought.
They might, just like Apple do. But then their forty billion dollar investment would stagnate and be eaten by riscv, which is probably what they are hoping to avoid.
Why would you read the press release at all? Do you expect a company to not do what's in their own financial self-interest? Look, I love nVidia. I only buy nVidia GPUs and I adore their devices like the SHIELD TV, handheld, tablet, even the Tegra Note 7. Even I can see that they're not just buying ARM on a whim. They intend to make that money back. Them using ARM to make that money is good for absolutely nobody except nVidia themselves.
I'll listen to what they're saying but I'm paying far more attention when I look at what they're doing. The only way buying ARM helps nVidia is by damaging their competitors, AKA almost everyone.
My experience of acquisitions is that sweet songs are sung to calm the horses. Then the next financial quarter comes around and the truck from the glue factory arrives.
If you take at face value anything from a press release, earnings call or investor relations website, then I would like to take a moment to share with you the prospectus of Brooklyn Bridge LLC.
And when Facebook bought Oculus, they said no FB login would be required to use Oculus. FoxConn was supposed to ramp up production in the US according to a press release. That was then, now time has passed. bigCorp hopes your short term memory forgets the woohooism from a foregone press release.
Netflix really doesn’t belong in the same category as the others. It’s big but not as big, and it isn’t a sprawling conglomerate. Clearly “FAGMA” is the best acronym.
love the armchair CEO perspectives that NVIDIA spent $40b only to flush the whole ARM ecosystem right down the drain, that's definitely a rational thing to do, right?
Jensen's not an idiot, how many OG 90s tech CEOs are still at the helm of the company they founded? Any severely negative moves towards their customers just drives them into RISC-V and they know that.
Yes, ARM customers will be paying more for their ARM IP. No, NVIDIA is not going to burn ARM to the ground.
Even if/when RISCV takes over, Intel and AMD will be in a unique position to offer "combination" chips with both x86 and RISCV cores which could milk the richest enterprise and government markets for decades to come.
I think this is driven by partly embedded applications and more directly by the datacenter.
Nvidia already own the parallel compute/ML part of the datacenter and the Mellanox acquisition had brought the ability to compete in the networking part of the datacenter - but they were missing CPU IP, for tasks that aren't well matched to the GPU. This plugs that hole. They are in control of a complete data-center solution now.
There's a huge number of synergies that this deal provides.
(a) NVIDIA becomes a full-fledged full-stack house, they have both CPU and GPU now. They can now compete with AMD and Intel on equal terms. That has huge implications in the datacenter.
(b) GeForce becomes the reference implementation of the GPU, ARM processors now directly fund NVIDIA's desktop/datacenter R&D in the same way consoles and Samsung SOCs fund Radeon's R&D. CUDA can be used anywhere on any platform easily.
(c) Acqui-hire for CPU development talent. NVIDIA's efforts in this area have not been very good to date. Now they have an entire team that is experienced in developing ARM and can aim the direction of development where they want.
Basically there's a reason that NVIDIA was willing to pay more than anyone else for this property. And (Softbank's) Son desperately needed a big financial win to show his investors that he's not a fucking idiot for paying $32b for ARM and to make up for his other recent losses.
Quite. Nvidia will be able to make a single chip CPU, GPU and Infiniband. Plus they'll score some people that know about cache coherency from Arm. We can see the future datacentre starting to form...
I love this, I was amongst early engineers on CUDA (compilers).
NVIDIA was so well run, but boxed into a smaller graphics card market - ATI and it were forced into low margins since they were made replaceable by OpenGL and DirectX standards. For the standard fans - they resulted a wealth transfer from NVIDIA to Apple etc. and reduced capital available for R&D.
NVIDIA was constantly attacked by a much bigger Intel (which changed interfaces to kill products and was made to pay by a court)
Through innovation, developing new technologies (CUDA) they increased market cap, and have used that to buy Arm/Mellanox.
I love the story of the underdog run by a founder, innovating it’s way to getting into new markets against harsh competition. Win for capitalism!
The comment identified the positive side of the nvidia story. Note that nvidia had not had large acquisition for many years.
This acquisition can be seen as a beacon of nvidia's past struggle against the market and the competitors.
For whatever happened, nvidia innovated to their success, and had enabled possibly the biggest tech boom so far through deep learning. Might be one day everyone claimed nvidia to be the "most important company" on earth.
I'm excited to see what technology is being brought to the table. I don't think that Nvidia will settle with being only second to Apple's CPUs in performance.
I wonder what this means for NVIDIA's recent RISC-V efforts [1]. Apparently they've been aiming to ship (or already have been shipping?) RISC-V microcontrollers on their GPUs for some time .
"The proposed transaction is subject to customary closing conditions, including the receipt of regulatory approvals for the U.K., China, the European Union and the United States. Completion of the transaction is expected to take place in approximately 18 months."
Hopefully, the EU does its job, laughs at this and tells Nvidia to either go home or forces them to FRAND licensing of ARM IP.
I’m not convinced this is a death sentence for ARM. I doubt nVidia spent $40b on a company with the intention of killing it’s golden goose business model. The contractual agreements might change, but ARM wasn’t exactly giving their IP away for free before this move.
Does Nvidia have a habit of killing acquisitions? I'm only familiar with their graphics business, but as far as I can see the only culture going on there is excellence.
NVIDIAs whole schtick is making a bunch of interesting software and arbitrarily locking it to their own hardware. Doesn't seem compatible with being the steward for what has up until now been a relatively open CPU architecture.
arbitrarily? Nvidia invests a lot in software R&D, why should they just give it away to their competitor AMD who basically invest nothing in comparison?
At issue is the conflict between ARM's business model- which revolves around licensing designs to other companies- and Nvidia's reputation of not playing nicely with other companies.
The concern is more that nvidias culture has historically been being overall hostile to parterships. Which works great for what Nvidia is doing right now, but is probably bad for a company that depends heavily on partnerships.
From a purely capitalistic standpoint, it's fine to kill off some of your customer base if you make more money from the remainder. If it can work for tobacco, you believe that Nvidia is will to kill off some of its customers if they can get the remainder to pay more.
I see this going a few ways for different players:
The perpetual architecture license folks that make their own cores like Apple, Samsung, Qualcomm, and Fujitsu (I think they needed this for the A64FX, right?) will be fine, and may just fork off on the ARMv8.3 spec, adding a few instructions here or there. Apple especially will be fine as they can get code into LLVM for whatever "Apple Silicon" evolves into over time.
The smaller vendors that license core designs (like the A5x and A7x series, etc.) like Allwinner, Rockchip, and Broadcom are probably in a worse state - nVidia could cut them off from any new designs. I'd be scrambling for an alternative if I were any of these companies.
Long term, it really depends on how nVidia acts - they could release low end cores with no license fees to try to fend off RISC-V, but that hasn't been overly successful when tried earlier with the SPARC and Power architectures. Best case scenario, they keep all the perpetual architecture people happy and architecturally coherent, and release some interesting datacenter chips, leaving the low end (and low margin) to 3rd parties.
Hopefully they'll also try to mend fences with the open source community, or at least avoid repeating past offenses.
I'm not defending Apple, just thinking that can't we say this for many of the biggest tech firms? They are way past the line on anticompetitive business.
I would also agree, the thing is - businesses breakup and come together all the time. If it makes sense and both parties can agree despite of past disagrements and lawsuits, they will partner.
Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.
But if your chip heavily builds on arm's IP you need a license for that at least as long as you can't replace the infringing parts of the design. Which sounds very much impossible if you also want to progress on other aspects of having the best chips.
Apple uses the ARM ISA. It doesn't use ARM IP - as in, the design of the chip. Apple designed their own damn chip!
Since they're not branding it as ARM in any way, shape, or form, and they have a perpetual architectural license to the ISA, I suspect they could do pretty much what they please - as long as they don't call it ARM. Which they don't.
I doubt that will be true going forward. They first used the “Apple Silicon” branding for the Mac and yesterday they used the branding for the Watch and iPad (?)
>Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.
Yea, they got fucked by Nvidia business practices multiple times. There's a saying about shame on you, shame on me, etc.
Unless the entire Nvidia business unit also gets replaced in the same transaction, it doesn't matter how much of a faux separation of concerns they want to market.
They can certainly have a contract with Arm that allows them to renew their arch license in perpetuity that nvidia won't be able to void.
I obviously don't know that for sure but the idea that Apple would stake their future on something they don't have a legal ironclad position seems unlikely.
Wow, but that cost - it's not a small thing to transition ISA, and don't forget that this transition is one of the simpler ones (more registers, fairly few devices). The risks of transitioning everything away from arm would be much greater.
I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.
Do it more and more and they'll have the tools to efficiently manage them.
Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.
At the low-level driver interface, transitioning ISA is a big deal. But I would guess that, at higher levels, most of the work is just changing the target of your compiler?
As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.
First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff.
Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc
Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat.
Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad?
All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.
Extremely aggressive optimizations are really special though, and they tend to require rewrites when new CPU extensions release (and workarounds to work on older hardware). If you rely on super low level ultra-aggressive micro optimizations your code is going to have a relatively short shelf life, different ISA or not.
The vast majority of the code written for any given computer or smartphone doesn't have this level of sophistication and optimization though. I'd wager that for most code just changing the build target will indeed mostly just work.
It won't be painless but modern code tends to be so high level and abstracted (especially on smartphones) than the underlying ISA matters a lot less than in the past.
Absolutely this - even some aggressively optimised stuff like game engines don't have insurmountable amounts of micro optimisations in them.
Also - why would Apple massively up and change uArchs? Even if they did decide to turn Apple Silicon into not-ARM, I'd wager it would look a lot more like ARM than for example, x86 does.
That's not my experience. Plain old SIMD code ages fairly well - but if you port to a new arch, you will need to look at it again.
This isn't a question of precise instruction timing, it's a question of compilers being pretty bad at leveraging SIMD in general, even in 2020. Also, while I'm sure lots of projects have hand-tuned assembly, even higher level stuff like intrinsics help a lot, and need manual porting.
Offer customers iOS apps and games on the next MacBook as a straight swap for Boot Camp and Parallels. Once they’ve moved everyone over to their own chips and brought back Rosetta and U/Bs they’re essentially free to replace whatever they like at the architecture level.
In their reveal I noticed that they only mentioned ARM binaries running in virtual environments. It makes sense if you don’t want to commit to supporting GNU tools natively on your devices (as it would mean sticking with an established ISA)
Apple is large enough that if they want to break from ARM in the future they can do so by forking an LLVM backend. That's not a large job if it's a very small change, but once it's been done once they have plenty of resources to provide ongoing support (like they do for webkit).
The dividends of doing so are potentially massive. Given that they've been able to make really large gains with the A series chips to date on mobile (not least because they've been able to offload tasks to dedicated co-processors that general-purpose ARM cores don't ship with), the rewards for having chips that are a generation ahead of other like-for-like computers will outweigh the cost of maintaining the software.
> The perpetual architecture license folks that make their own cores like Apple, Samsung, Qualcomm, and Fujitsu (I think they needed this for the A64FX, right?) will be fine
There is one thing they would need to worry about though, which is that if the rest of the market moves to RISC-V or x64 or whatever else, it's not implausible that someone might at some point make a processor which is superior to the ones those companies make in-house. If it's the same architecture, you just buy them or license the design and put them in your devices. If it's not, you're stuck between suffering an architecture transition that your competitors have already put behind them or sticking with your uncompetitive in-house designs using the old architecture that nobody else wants anymore.
Their best move might be to forget about the architecture license and make the switch to something else with the rest of the market.
> Their best move might be to forget about the architecture license and make the switch to something else with the rest of the market.
This assumes that there isn't some other factor in transitioning architecture - this argument could boil down in the mid 2000's to "Why not go x86/amd64", but you couldn't buy a license to that easily (would need to be 3-way with Intel/AMD to further complicate things)
Apple has done quite well with their ARM license, outperforming the rest of the mobile form factor CPU market by a considerable margin. I don't doubt that they could transition - they've done it successfully 3 times already, even before the current ARM transition.
Apple under Cook has said they want to "to own and control the primary technologies behind the products we make". I doubt they'd turn away from that now to become dependent on an outside technology, especially given how deep their pockets are.
Apple could transition in 10 years to RISC-V, just like how they transitioned 10 years ago to x86, 10 years before to PPC, 10 years before to .........
Many of Apple's direct competitors are ARM customers, and US politics is already turning a large anti-trust eye towards FAANG. That might have been a factor.
> Apple has done quite well with their ARM license, outperforming the rest of the mobile form factor CPU market by a considerable margin.
But that has really nothing to do with the architecture. They just spent more money on CPU R&D than their ARM competitors. They could have done the same thing with RISC-V, and if that's where the rest of the industry is going, they could be better off going there too. Especially for Mac, since they're about to do a transition anyway. They could benefit from putting it off for another year while they change the target architecture to something the rest of the market might not be expected to avoid in the future.
There is also no guarantee that their success is permanent. They might have done a better job than Qualcomm this year, but what happens tomorrow, if Google throws their hat into the ring, or AMD makes a strong play for the mobile market, or Intel gets their heads out of their butts, or China decides they want the crown and gives a design team an unlimited budget? There is value in the ability to switch easily in the event that someone else is the king of the mountain for a while.
> I don't doubt that they could transition - they've done it successfully 3 times already, even before the current ARM transition.
Just because they can do it doesn't mean it's free.
Really if Intel was shrewd, they'd recognize that they've lost Apple's business already and just sell them an x86 license, under some terms that Intel would care about and Apple wouldn't, like they can only put the chips in their own devices. Then Apple could save themselves the transition entirely and do another refresh with processors from Intel while they put their CPU team to task redesigning their own chips to be x86_64. It would give both Apple and Intel a chance to throw a punch at Nvidia (which neither of them like) while helping both of them. Apple by avoiding the Mac transition cost and Intel by maintaining the market share of their processor architecture and earning them whatever money they get from Apple for the license.
And it gives Intel a chance to win Apple's business back. All they have to do is design a better CPU than Apple does in-house, and Apple could start shipping them again without having to switch architectures. Which is also of value to Apple because it allows them to do just that if Intel does produce a better CPU than they do at any point in the future.
The problem I see with your argument is that it ignores their superior mobile ARM SoC. If they are going to unify on an architecture, it would certainly be easier to migrate Mac to ARM than iOS to x86.
Samsung, Qualcomm, and MediaTek all currently just use off the shelf A5x & A7x cores in their SoCs. Unless that part of the company is losing money I don't expect nVidia to cut that off. Especially since that's likely a key part of why nVidia acquired ARM in the first place - I can't imagine they care about the Mali team(s) or IP.
That was a really sad time honestly. QCOMM went from leading the pack to basically using reference designs (which they still arrogantly brand as Kryo despite essentially being a tweak of a reference design.
It all happened because Apple came out with the first 64-bit design, and QCOMM wasn't ready. Rather than deliver 32-bit for 1 more year, they used an off the shelf ARM 64-bit design (A57) in their SoC called the Snapdragon 810, and boy was it terrible.
From what I gathered, they made at least _some_ risky architecture choices in their custom architecture that turned out not to be sustainable over the next generations. Also note that their Cortex core is indeed customized to a significant extent.
What happens if/when Nvidia launches SoCs that compete with Qualcomm and MediaTek. Will it continue to offer the latest cores to competitors when it will make a lot more money on its own SoCs? This is the reason for the widepsread concern about Nvidia owning Arm.
Mediatek are in the lower end market, something Nvidia's culture doesn't like competing in. Qualcomm holds the key to Modem. Which means Nvidia competing with Qualcomm wont work that well. Not to mention they have already tried that with Icera and generally speaking Mobile Phone SoC are low margin business. ( Comparatively Speaking )
On mobile SoC margins I guess that margins are low because there is a lot of competition - start cutting off IP to the competition and margins will rise.
I suspect that their focus will be on the server / automotive to start off with but the very fact that they can to any of this is troubling for me.
I don't know if Nvidia is eager to re-enter the SoC market. It wouldn't be a clear path to more money, since they would need to then handle modem, wifi, ISP, display, etc... instead of just CPU & GPU. And they'd need to work with Android & its HALs. And all the dozens/hundreds of device OEMs.
They could, but that's more than just an easy money grab. Something Nvidia would already be familiar with from Tegra.
What seems more likely/risky would be nvidia starts charging a premium for a Mali replacement, or begins sandbagging Mali on the lower end of things. But Qualcomm already has Adreno to defend against that.
They released a new SBC aimed at autonomous vehicles. They haven't had a mobile SoC since 2015's Tegra X1. Which only made it into the Pixel C tablet, Nintendo Shield, and Nvidia's Shield TV (including the 2019 refresh)
Why would they do that anyway? The downsides are obvious (immediate loss of revenue), the risks are huge (antitrust litigation, big boost to RiscV or even Mips), the possible benefits are nebulous.
Those who are most obviously at risk are designers of mobile GPUs (Broadcom, PowerVR ...).
If they do it that directly, sure. But on a large enough (time)scale, incentives are the only thing that matters. And they'll certainly think hard about putting their fancy new research that would help a competitor into their openly licensed chips from now on.
"and may just fork off on the ARMv8.3 spec, adding a few instructions here or there"
No, they may not. People keep suggesting these kinds of things, but part of the license agreement is that you can't modify the ISA. Only ARM can do that.
That's like saying that my Intel CPU comes with an NVIDA Turing AI acceleration extension. The instructions the CPU can run on an Apple ARM-based CPU is all ARM ISA. That's in the license arrangement, if you fail to pass ARM's compliance tests (which include not adding your own instructions, or modifying the ones included) you can't use ARM's license.
Please, stop spreading nonsense. All of this is public knowledge.
No. I reverse-engineered it and AMX on the Apple A13 is an instruction set extension running on the main CPU core.
The Neural Engine is a completely separate hardware block, and you have good reasons to have such an extension available on the CPU directly, to reduce latency for short-running tasks.
The AMX is an accelerator block... If you concluded otherwise, your reverse-engineering skills are not great...
Let me repeat this: part of the ARM architectural license says that you can't modify the ISA. You have to implement a whole subset (the manual says what's mandatory and what's optional), and only that. This is, as I've been saying, publicknowledge. This is how it works. And there are very good reasons for this, like avoiding fragmentation and losing control of their own ISA.
After your tone, not certainly obligated to answer but will write one quickly...
Apple A13 adds AMX, a set of (mostly) AI acceleration instructions that are also useful for matrix math in general. The AMX configuration happens at the level of the AMX_CONFIG_EL1/EL12/EL2/EL21 registers, with AMX_STATE_T_EL1 and AMX_CONTEXT_EL1 being also present.
Is it possible AMX is implemented with the implementation-defined system registers and aliases of SYS/SYSL in the encoding space reserved for implementation-defined system instructions? Do you have the encodings for the AMX instructions?
Now custom instructions are directly on the regular instruction space...
(+ there's the can of worms of target-specific MSRs being writable from user-space, Apple does this as part of APRR to flip the JIT region from RW- to R-X and vice-versa without going through a trip to the kernel. That also has the advantage that the state is modifiable per-thread)
Well, regardless of whether this amendment is kosher or not, AMX definitely exists. Perhaps the $2T tech behemoth was able to work out a sweetheart deal with the $40B semiconductor company.
> There’s been a lot of confusion as to what this means, as until now it hadn’t been widely known that Arm architecture licensees were allowed to extend their ISA with custom instructions. We weren’t able to get any confirmation from either Apple or Arm on the matter, but one thing that is clear is that Apple isn’t publicly exposing these new instructions to developers, and they’re not included in Apple’s public compilers. We do know, however, that Apple internally does have compilers available for it, and libraries such as the Acclerate.framework seem to be able to take advantage of AMX. [0]
my123's instruction names leads to a very shallow rabbit hole on google, which turns up a similar list [1]
Curious as I don't know the terms of a perpetual architectural ARM license. But, is it valid only for a specific architecture, say v8 or v9, or is it valid for all future architectures as well? Or is it one of those things, where it depends per licensee and how they negotiated?
Broadcom has an architectural license. They do also license core designs.
Really if nVidia locks up the lower end cores, then a lot of stuff breaks. Billions of super tiny ARM cores are everywhere. ARM has few competitors in the instruction set space for low end, low power, low cost cores. AVR, PIC, and MIPS are what come to mind. And AVR/PIC are owned by Microchip corporation.
These ARM chip unit licenses are dirt cheap, there's hundreds of small manufacturers, and their chips go in everything, and in unexpected places. And these aren't just little microprocessors anymore. They're even in SoCs as little coprocessors that manage separate hardware components in realtime.
The amount of penetration ARM has in hidden places cannot be underestimated. And there isn't a quick replacement for them. Not one freely licensed to any manufacturer.
There's low power inference from Intel (Movidius) and Google (Coral Edge TPU). Nvidia doesn't really have anything below the Jetson Nano. I think there are a smattering of other low power cores out there (also dedicated chips in phones). TPUs are used on the high performance end and there are also companies like Graphcore who do insane things in silicon. Also niche HPC products like Intel Knight's Landing (Xeon Phi) which is designed for heterogeneous compute.
There isn't a huge amount of competition in the consumer/midrange sector. Nvidia has almost total market domination here. Really we just need a credible cross platform solution that could open up gpgpu on AMD. I'm surprised Apple isn't pushing this more, as they heavily use ML on-device and to actually train anything you need Nvidia hardware (eg try buying a Macbook for local deep learning training using only apple approved bits, it's hard!). Maybe they'll bring out their own training silicon at some point.
Also you need to make a distinction between training and inference hardware. Nvidia absolutely dominate model training, but inference is comparably simpler to implement and there is more competition there - often you don't even need dedicated hardware beyond a cpu.
784 comments
[ 5.2 ms ] story [ 366 ms ] threadI never liked Softbank owning it, but hey someone has to.
Regarding the federal investment in FOSS thread that was here perhaps CPU architecture would be a good candidate.
I know momentum is currently towards ARM over POWER, but... OpenPOWER is certainly a thing, and has IBM / Red Hat support. IBM may be expensive, but they already were proven "fair partners" in the OpenPOWER initiative and largely supportive of OSS / Free Software.
I don't see OpenPOWER going there, but I can easily see RISC-V going there. So, for the moment, that is the horse I'm betting on.
To be honest, I don't think that NVidia/ARM will screw over their Cortex-M0 or Cortex-M0+ customers over. I'm more worried about the higher-end, whether or not NVidia will "play nice" with its bigger rivals (Apple, Intel, AMD) in the datacenter.
https://www.nxp.com/part/FS32R274VCK2VMM
https://www.digikey.com/product-detail/en/nxp-usa-inc/FS32R2...
The two related devkits list for $529 and $4,123: https://www.digikey.com/products/en/development-boards-kits-...
--
Those processors make quite a few reference to an "e200", which I think is the CPU architecture. I discovered that Digi-Key lists quite a few variants of this under Core Processor; and checking the datasheets of some random results suggests that they are indeed Power architecture parts.
https://www.digikey.com/products/en/integrated-circuits-ics/...
The cheapest option appears to be the $2.67@1000, up-to-48MHz SPC560D40L1B3E0X with 256KB ECC RAM.
Selecting everything >100MHz finds the $7.10@1000 SPC560D40L1B3E0X, an up-to-120MHz part that adds 1MB flash (128KB ECC RAM).
Restricting to >=200MHz finds the $13.32@500 SPC5742PK1AMLQ9R has which has dual cores at 200MHz, 384KB ECC RAM and 2.5MB flash, and notes core lock-step.
--
After discovering the purpose of the "view prices at" field, the landscape changes somewhat.
https://www.digikey.com/products/en/integrated-circuits-ics/...
The SPC574S64E3CEFAR (https://www.st.com/resource/en/datasheet/spc574s64e3.pdf) is 140MHz, has 1.5MB code + 64KB data flash and 96KB+32KB data RAM, and is available for $14.61 per 1ea.
The SPC5744PFK1AMLQ9 (https://www.nxp.com/docs/en/data-sheet/MPC5744P.pdf) is $20.55@1, 200MHz, 2.5MB ECC flash, 384KB ECC RAM, and has two cores that support lockstep.
The MPC5125YVN400 (https://www.nxp.com/docs/en/product-brief/MPC5125PB.pdf) is $29.72@1,...
No different than say, Cortex-M0 or M0+ in many regards (although ARM scales down to lower spec'd pieces).
Its really too bad the dev boards are so expensive but I get you need a lot of layers to route that sort of BGA.
There are still new chips using the Cortex-M3 today. Microcontroller devs do NOT want to be changing their code that often.
New chips move the core to lower-and-cheaper process nodes (and lower the power consumption), while otherwise retaining the same overall specifications and compatibility.
The use some desoldering braid to soak up the excess solder. It will remove all the bridges and leave perfect joints.
In mobile form, it would have made a large leap in both performance and battery life. And it would have been a fairly easy market to break into: the average life of a mobile device is a few years, not a few decades. Recompilation and redistribution of software is the status quo.
Each machine instruction on NVidia Volta has the following information:
* Reuse Flags
* Wait Barrier Mask
* Read/Write barrier index (6-bit bitmask)
* Read Dependency barriers
* Stall Cycles (4-bit)
* Yield Flag (1-bit software hint: NVidia CU will select new warp, load-balancing the SMT resources of the compute unit)
Itanium's idea of VLIW was commingled with other ideas; in particular, the idea of a compiler static-scheduler to minimize hardware work at runtime.
To my eyes: the benefits of Itanium are implemented in NVidia's GPUs. The compiler for NVidia's compiler-scheduling flags has been made and is proven effective.
Itanium itself: the crazy "bundling" of instructions and such, seems too complex. The explicit bitmasks / barriers of NVidia Volta seems more straightforward and clear in describing the dependency graph of code (and therefore: the potential parallelism).
----------
Clearly, static-compilers marking what is, and what isn't, parallelizable, is useful. NVidia Volta+ architectures have proven this. Furthermore, compilers that can emit such information already exist. I do await the day when other architectures wake up to this fact.
I'm talking about Volta's ability to detect dependencies. Which is null: the core itself probably can't detect dependencies at all. Its entirely left up to the compiler (or at least... it seems to be the case).
AMD's GCN and RDNA architecture is still scanning for read/write hazards like any ol' pipelined architecture you learned in college. The NVidia Volta thing is new, and probably should be studied from a architectural point of view.
Yeah, its a GPU-feature on NVidia Volta. But its pretty obvious to me that this explicit dependency-barrier thing could be part of a future ISA, even one for traditional CPUs.
https://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-r...
> NVIDIA has replaced Fermi’s complex scheduler with a far simpler scheduler that still uses scoreboarding and other methods for inter-warp scheduling, but moves the scheduling of instructions in a warp into NVIDIA’s compiler. In essence it’s a return to static scheduling
and I think this is describing more or less the same thing in Maxwell: https://github.com/NervanaSystems/maxas/wiki/Control-Codes
Speculative execution is something you would want to do with the itanium as well, otherwise the machine is going to be stalling all the time waiting for branches/etc. Similarly, later itaniums went OoO (dynamically scheduled) because it turns out, the compiler can't know runtime state..
https://www.realworldtech.com/poulson/
Also while googling for that, ran across this:
https://news.ycombinator.com/item?id=21410976
PS: speculative execution is here to stay, it might be wrapped in more security domains and/or its going to just be one more nail in the business model of selling shared compute (something that was questionably from the beginning).
I wonder which cloud provider is the first to offer this in a coherent way.
ISTR that Intel & HP spent well over a $billion on VLIW compiler R&D, with crickets to show for it all.
How much are you suggesting should be spent this time for a markedly different result?
His explanation centred on the fact that Intel decided early on that Itanium would only ever be an ultra high end niche product and only built devices which Intel could demand very high prices for. This in turn meant that almost no one outside of the few companies who were supporting Itanium development and certainly not most of the people who were working on other compilers and similar developer tools at the time, had any interest in working on Itanium because they simply could not justify the expense of obtaining the hardware.
So all the organic open source activity that goes on for all the other platforms which are easily obtainable by pedestrian users simply did not go on for Itanium. Intel did not plan on that up front (though in hindsight it seemed obvious) and by the time that was widely recognised within the management team no one was willing to devote the sort of scale of resources that were required for serious development of developer tools on a floundering project.
https://dl.acm.org/doi/book/10.5555/923366 https://dl.acm.org/doi/10.1145/349299.349318
and many, many others (it produced so many PhDs in 90s). And, needless to say, HP and Intel hired so many excellent researchers during the heydays of Itanium. So I don't know on what basis you think there wasn't enough investment. So I have no choice but to assume you're ignorant of the actual history here, both in academics and industry.
It turns out instruction scheduling can not overcome the challenge of variable memory and cache latency, and branch prediction, because all of those are dynamic and unpredictable, for "integer" application (i.e. bulk of the code running on the CPUs of your laptop and cell phones). And, predication, which was one of the "solutions" to overcome branch misprediction penalties, turns out to be not very efficient, and is limited in its application.
For integer applications, it turns out the instruction level parallelism isn't really the issue. It's about how to generate and maintain as many outstanding cache misses at a time. VLIW turns out to be insufficient and inefficient for that. Some minor attempts are addressing that through prefetches and more elaborate markings around load/store all failed to give good results.
For HPC type workload, it turns out data parallelism and thread-level parallelism are much more efficient way to improve the performance, and also makes ILP on a single instruction stream play only a very minor role - GPUs and ML accelerators demonstrate this very clearly.
As for the security and the speculative execution, speculative execution is not going anywhere. Naturally, there are many researches around this like:
https://ieeexplore.ieee.org/abstract/document/9138997 https://dl.acm.org/doi/abs/10.1145/3352460.3358306
and while it will take a while before the real pipeline implements ideas like above thus we may continue to see some smaller and smaller vulnerabilities as the industry collectively plays whack-a-mole game, I don't see a world where the top of the line general-purpose microprocessor giving up on speculative execution, as the performance gain is simply too big.
I have yet to meet any academics or industry processor architects or compiler engineer who think VLIW / Itanium is the way to move forward.
This is not to say putting as much work to the compiler is a bad idea, as nVidia has demonstrated. But what they are doing is not VLIW.
And the compiler doesn't even come close to having as much information as the CPU has. Which basically means that most of the VLIW stuff just ends up needing to be broken up inside the CPU for good performance.
The compiler has nearly all of the information that the CPU has, and it has orders of magnitude more. At best, your CPU can think a couple dozen cycles ahead of what it is currently executing. The compiler can see the whole program, can analyze it using dozens of methodologies and models, and can optimize accordingly. Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
The 200-sized reorder buffer says otherwise.
Loads/stores can be reordered for 200+ different concurrent objects on modern Intel skylake (2015 through 2020) CPUs. And its about to get a bump to 300+ sized reorder buffers in Icelake.
Modern CPUs are designed to "think ahead" almost the entirety of DDR4 RAM Latency, allowing reordering of instructions to keep the CPU pipes as full as possible (at least, if the underlying assembly code has enough ILP to fill the pipelines while waiting for RAM).
> Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
You might be surprised at what the modern Branch predictor is doing.
If your "call rax" indirect call constantly calls the same location, the branch predictor will remember that location these days.
You get instructions scheduled based on actual dynamically measured usage patterns, but you don't pay for dedicated circuits to do it, and you don't re-do those calculations in hardware for every single instruction executed.
It's not a guaranteed win, but I think it's worth exploring.
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't need "call rax".
---
Compiler has access to optimizations that are at the higher level of abstraction than what CPU can do. For example, the compiler can eliminate the call completely (i.e. inline the function), or convert a dynamic dispatch into static (if it can prove that an object will always have a specific type at the call site), or decide where to favor small code over fast code (via profile-guided optimization), or even switch from non-optimized code (but with short start-up time) to optimized code mid-execution (tiered compilation in JITs), move computation outside loops (if it can prove that the result is the same in all iterations), and many other things...
My point was simply that the compiler may be in position to disprove the assumption that this call is in fact dynamic (it may actually be static) or that it has to be a call in the first place (and inline the function instead).
I'm certainly not arguing against branch predictors.
The CPU has something the compiler can never have.
Runtime information.
That's why VLIW works great for DSP which is 99.9 % fixed access patterns, while being bad for general purpose code.
But what have we learned in these past 20 years?
* Computers will continue to become more parallel -- AMD Zen2 has 10 execution pipelines, supporting 4-way decode and 6-uop / clock tick dispatch per core, with somewhere close to 200 registers for renaming / reordering instructions. Future processors will be bigger and more parallel, Ice Lake is rumored to have over 300-renaming registers.
* We need assembly code that scales to all different processors of different sizes. Traditional assembly code is surprisingly good (!!!) at scaling, thanks to "dependency cutting" with instructions like "xor eax, eax".
* Compilers can understand dependency chains, "cut them up" and allow code to scale. The same code optimized for Intel Sandy Bridge (2011-era chips) will continue to be well-optimized for Intel Icelake (2021 era) ten years later, thanks to these dependency-cutting compilers.
I think a future VLIW chip can be made that takes advantage of these facts. But it wouldn't look like Itanium.
----------
EDIT: I feel like "xor eax, eax" and other such instructions for "dependency cutting" are wasting bits. There might be a better way for encoding the dependency graph rather than entire instructions.
Itanium's VLIW "packages" is too static.
I've discussed NVidia's Volta elsewhere, which has 6-bit dependency bitmasks on every instruction. That's the kind of "dependency graph" information that a compiler can provide very easily, and probably save a ton on power / decoding.
Perhaps from your perspective, a VLIW architecture that fixes these problems wouldn't necessarily be VLIW anymore. Which... could be true.
It's not only about reducing the need for figuring out dependencies at runtime, but you could also partly reduce the need for the (power hungry and hard to scale!) register file to communicate between instructions.
That's why today's CPUs can have 4-way decoders and 6-way dispatch (AMD Zen and Skylake), because they can "pick up more latent parallelism" that the compilers have given them many years ago.
"Classic" VLIW limits your potential parallelism to the ~3-wide bundles (in Itanium's case). Whoever makes the "next" VLIW CPU should allow a similar scaling over the years.
-----------
It was accidental: I doubt that anyone actually planned the x86 instruction set to be so effectively instruction-level parallel. Its something that was discovered over the years, and proven to be effective.
Yes: somehow more parallel than the explicitly parallel VLIW architecture. Its a bit of a hack, but if it works, why change things?
VLIW is a compromise product: its more parallel than a traditional CPU, but less parallel than SIMD/GPUs.
And modern CPUs have incredibly powerful SIMD engines: AVX2 and AVX512 are extremely fast and parallel. There are compilers that auto-vectorize code, as well as dedicated languages (such as ipsc) which work for SIMD.
Encoders, decoders, raytracers, and more have been rewritten for Intel AVX2 SIMD instructions, and then re-rewritten for GPUs. The will to find faster execution has always existed, but unfortunately, Itanium failed to perform as well as its competition.
GPUs do work like this – shaders recompiled all the time – so VLIW was used in GPUs (e.g. TeraScale). But on CPUs we have a world of optimized, "done" binaries.
Unless your CPU has a means for profiling where your pipeline stalls are coming from, combined with dynamic recompilation/reoptimization similar to IBM's project DAISY or HP's Dynamo.
It's not going to do well as out-of-order CPUs that make instruction re-optimization decisions for every instruction, but I wouldn't rule out software-controlled dynamic re-optimization getting most of the performance benefits of out-of-order execution with a much smaller power budget, due to not re-doing those optimization calculations for every instruction. There are reasons most low-power implementations are in-order chips.
Apple could of course Afford to invest in RISC-V (and surely has played with it internally) but they have enough control of their future under the current arrangement that it will be a long long time before they feel any need to switch — 15 years at least.
This could change.
Given that the CEO was the supply chain guy at the time I suspect the latter, as I’d imagine he’d be more dispassionate than Jobs.
In any case I seriously doubt nvidia could, much less would benefit from cancelling Apple’s agreement.
I've seen this argument made before.
It would be a valid point if Apple stopped using Nvidia GPUs in 2008 (they did), and then never used them again. And yet, 4 years later, they used Nvidia GPUs on the 2012 MacBook Retina 15" on which I'm typing this.
And then that was that. We haven't seen Nvidia GPU again.
That said: AMD GPUs have also had their share of issues on MacBooks.
https://riscv.org/membership/members/
While some like Google and Alibaba are listed as platinum founding members.
I understand what you're saying and this seems to be the prevailing pattern but I really don't understand it. ARM could easily be a standalone company. For some reason, mergers are in.
I have always assumed that their shareholders were offered so much of a premium on their shares that they chose to sell them rather than hold onto them. Clearly based on their fiscal 2015 results[1] they were a going concern.
[1] https://www.arm.com/company/news/2016/02/arm-holdings-plc-re...
Clearly, if a buyer is willing to pay a premium for shares, it's because they believe the company is worth that premium. If the shareholders were optimistic, they might consider that as a signal of the company's underlying value and choose not to sell.
Sometimes activist shareholders will pressure a company to sell, like in the case of the Whole Foods sale to Amazon. Jana Partners owned ~8% and they motivated Whole Foods to look for buyers. They dumped their shares after the sale was announced and before it was executed. Whether that was the best for the other 92% of shareholders, the company's employees, and its customers is another question entirely.
My question is really outside of that. There will always be banks, investors, and companies that are motivated to consolidate and integrate companies to be increasingly competitive to the point of being anti-competitive. What is the counter force that helps maintain moderately sized companies that are profitable on their own?
It really is possible to be critical of a monopoly without disparaging the product itself. It is when a true competitor arises that we see the monopolist's true capabilities (see Intel and AMD).
There is literally no benefit to 90% of the audience if they doubled the RAM. Of course, they also want to do market segmentation too, but you can’t blame GeForce for not being designed for ML training.
ARM being owned by an organisation deeply embedded in processor design and manufacturing, will now be licensing designs to competitors, as well as getting a lot of intel on its competitors.
ARM supercomputers were poised to take on Nvidia. Now its all one and the same.
As others have said, this will do wonders for RISC-V.
ARM as an independent company, has been profoundly "neutral", allowing many companies to benefit from the ARM instruction set. It has been run very well: slightly profitable and an incremental value to all parties involved (be you Apple's iPhone, NVidia's Tegra (aka Nintendo Switch chip), AMD's EPYC, Qualcomm's Snapdragon, numerous hard drive companies, etc. etc.). All in all, ARM's reach has been because of its well-made business decisions that have been fair to all parties involved.
NVidia, despite all their technical achievements, is known to play hardball from a business perspective. I don't think anyone expects NVidia to remain "neutral" or "fair".
Yes, absolutely.
NVIDIA's not going to burn the ARM ecosystem to the ground. They just paid $40 billion for it. And they only had $11b of cash on hand, they really overpaid for it (because SoftBank desperately needed a big win to cover for their other recent losses).
Now: will everybody (including AMD) probably be paying more for their ARM IP from now on? Yes.
Or more recently, when Facebook bought Oculus for $2 Billion, did you expect Facebook to betraying the customer's trust and start pushing Facebook logins?
The Oculus / Facebook login thin just happened weeks ago. Companies betraying the promises they made to their core audience is like... bread-and-butter at this point (and seems to almost always happen after an acquisition play). We know Facebook's modus operandi, and even if its worse for Oculus, we know that Facebook will do what Facebook does.
Similarly, we know NVidia's modus operandi. NVidia is trying to make a datacenter play and create a vertical company for high-end supercomputers. Such a strategy means that NVidia will NOT play nice with their rivals: Intel or AMD. (And the Mellanox acquisition is just icing on the cake now).
NVidia will absolutely leverage ARM to gain dominance in the datacenter. That's the entire point of this purchase.
--------
There's a story about scorpions and swimming with one on your back. I'm sure you've heard of it before. Just because its necessary for the scorpion's survival doesn't mean it is safe to trust the scorpion.
yes? I mean that felt eminently possible from the get-go.
Yes, yes, and yes. This is Oracle we're talking about. Of course they'll invest more in lawyers than tech. The only reason they still invest in Java is the lawsuit potential. If only Google had the smarts to buy Sun instead...
As for NVidia, their play probably is integration and datacenters. At the moment, going after other ARM licencees will hinder NVidia more than help (they're going after x86, no time to waste on bad PR and legal issues with small time ARM datacenter licencees; Qualcomm and Apple are in a different segment altogether). Of course, we can't guarantee it stays that way.
Would you rather have TSMC in control of ARM? Maybe have access to new architectures bundled with a mandate that you have to build them on TSMC's processes?
How about Samsung? All of the fab ownership concerns of TSMC plus they also make basically any tech product you care to name, so all the integration concerns of NVIDIA.
https://asia.nikkei.com/Business/Technology/Key-Apple-suppli...
Microsoft? Oracle? None of the companies who could have afforded to pay what Son wanted for Softbank were any better than NVIDIA.
There are a lot of good things that will come out of this as well. NVIDIA is a vibrant company compared to a lot of the others.
I bet they'd make a completely custom ISA if they could. Heck, maybe they plan to some day, and that's why they're calling the new Mac processors "Apple Silicon".
That was my first thought.
I'd be surprised if Apple wasn't already working on this.
If they could pull it off I would be very impressed.
- "We changed from the 68K to PPC" "Agh!...fine"
- "We changed from PPC to x86" "What, again?"
- "We changed from x86 to Apple Silicon" "...oooo...kay..."
- "We changed from Apple Silicon to, uh, Apple Silicon - like it's still called Apple Silicon, but the architecture is different" "What's an architecture?" "The CPU ISA." "The CPU is a what?"
Can someone explain this? (From the bullet points of the article)
I looked up the definition of accretive: "characterized by gradual growth or increase."
So it seems like they expect this to increase their margins. Does that mean ARM had better margins than NVIDIA?
Edit: I don't know what non-GAAP and EPS stand for
Non-GAAP -> doesn’t follow generaly accepted accounting practices. There are alternative accounting methods. GAAP is very US-centric (not good or bad, just stating a fact).
This article is old, but suggests a 48% operating margin: https://asia.nikkei.com/NAR/Articles/ARM-posts-strong-profit...
Are we going to simply say "Nu uh" at each other, or do you want to throw down some specific examples so I can show you how mistaken they are?
I'll make it easier for you, directly from Google's website:
TPUs Cloud TPUs are optimized for specific workloads. In some situations, you might want to use GPUs or CPUs on Compute Engine instances to run your machine learning workloads.
Please tell me a workload a gpu can't do that a TPU can.
In my experience, well over 80% of these operations are implemented on TPU CPUs, and at least 60% are implemented on TPU cores.
Again, if you give a specific example, I can simply write a program demonstrating that it works. What kind of custom reduction do you want? What's a peak search?
As for workloads that GPUs can't do, we regularly train GANs at 500+ examples/sec across a total dataset size of >3M photos. Rather hard to do that with GPUs.
You did not give an example of something GPUs can't do. all you said was that TPUs are faster for a specific function in your case.
Why make generalizations like this? It's not true, and we've devolved back into the "nu uh" we originally started with.
This is trivial to do on a GPU, and is built into the library
Yes, I'm sure there are hardwired operations that are trivial to do on GPUs. That's not exactly a +1 in favor of generic programmability. There are also operations that are trivial to do on TPUs, such as CrossReplicaSum across a massive cluster of cores, or the various special-case Adam operations. This doesn't seem related to the claim that TPUs are less flexible.
The raw functions it provides is not direct access to the hardware and memory subsystem.
Not true. https://www.tensorflow.org/api_docs/python/tf/raw_ops/Inplac...
Jax is also going to be giving even lower-level access than TF, which may interest you.
You did not give an example of something GPUs can't do. all you said was that TPUs are faster for a specific function in your case.
Well yeah, I care about achieving goals in my specific case, as you do yours. And simply getting together a VM that can feed 500 examples/sec to a set of GPUs is a massive undertaking in and of itself. TPUs make it more or less "easy" in comparison. (I won't say effortless, since it does take some effort to get yourself into the TPU programming mindset.)
Your last sentence is pretty funny: a GPU can't do certain workloads because one it can do is too slow for you. Yet it remains a fact that TPU cannot do certain workloads without offloading to the CPU (making it orders of magnitude slower), and that's somehow okay? It seems where this discussion is going is you pointed to a TensorFlow library that may or may not offload to a TPU, and it probably doesn't. But even that library is incomplete to implement things like a 5G LDPC decoder.
You'll need to link me to some specific implementation that you want me to port over, not just namedrop some random algorithm. Got a link to a github?
If your point is "There isn't a preexisting operation for overlap-save FFT" then... yes, sure, that's true. There's also not a preexisting operation for any of the hundreds of other algorithms that you'd like to do with signal processing. But they can all be implemented efficiently.
Yet it remains a fact that TPU cannot do certain workloads without offloading to the CPU (making it orders of magnitude slower), and that's somehow okay?
I think this is the crux of the issue: you're saying X can't be done, I'm saying X can be done, so please link to a specific code example. Emphasis on "specific" and "code".
Trust me, I would love if TPUs could do what you're saying, but they simply can't. There's no direct DMA from the NIC to where I can do a streaming application at 40+Gbps to it. Even if TPU could do all the things you claim, if it's not as fast as the A100, what's the point? To go through undocumented pain to prove something?
10Gbps isn't quite 40Gbps, but I think you can get there by streaming to a few different TPUs on different VPC networks. Or to the same TPU from different VMs, possibly.
The point is that there's a realistic alternative to nVidia's monopoly.
Perhaps I'm just not experienced enough with the programming model, but I've found them to be strictly less flexible/more tricky than GPUs, especially for things like conditional execution, multiple graphs, variable size inputs and custom ops.
The central reason that TPUs feel less flexible is Google's awful mistake in encouraging everyone to use TPUEstimator as the One True API For Doing TPU Programming. Getting off that API was the single biggest boost to my TPU skills.
You can see an example of how to do that here: https://github.com/shawwn/ml-notes/blob/master/train_runner.... This is a repo that can train GPT-2 1.5B at 10 examples/sec on a TPUv3-8 (aka around 10k tokens/sec).
Happy to answer any specific questions or peek at codebases you're hoping to run on TPUs.
GPT-2 was trained on TPUs. (There are explicit references to TPUs in the source code: https://github.com/openai/gpt-2/blob/0574c5708b094bfa0b0f6df...)
GPT-3 was trained on a GPU cluster probably because of Microsoft's billion-dollar Azure cloud credit investment, not because it was the best choice.
For MLPerf 0.7, it's true that Google's software isn't available to the public yet. That's because they're in the middle of transitioning to Jax (and by extension, Pytorch). Once that transition is complete, and available to the public, you'll probably be learning TPU programming one way or another, since there's no other practical way to e.g. train a GAN on millions of photos.
You'd think people would be happy that there are realistic alternatives to nVidia's monopoly for AI training, rather than rushing to defend them...
Pointing this out is not aggressive.
Wait, what? Why would transition to Jax imply transition to Pytorch?
To be fair, TPUv4 is not out yet, and it might catch up using the latest processes (7nm TSMC or 8nm Samsung).
https://mlperf.org/training-results-0-7
For operating income it's 25%, for net income it's 18%; not 5%.
Last four quarters operating income for AMD: $884 million
Last four quarters operating income for Nvidia: $3.5 billion
This speaks to the dramatic improvement in AMD's operating condition over the last several years. For contrast, in fiscal 2016 AMD's operating income was negative $382 million. Op income has increased by over 300% in just ~2 1/2 years. Increasingly AMD is no longer a profit lightweight.
AMD 2019 Revenue: $6.73b [1] NVIDIA 2019 Revenue: $11.72b [2]
Roughly half, as I said.
AMD 2019 Profit (as earnings per share): $0.30 [1] NVIDIA 2019 Profit (as earnings per share): $6.63 [2]
4.52%, rounds to 5%, as I said.
However, you still proved my point. Lightweight or not, they do not, and have not had the amount of money available compared to NVidia and Intel. It's growing, they'll be able to continue to invest, and they have an advantage in the CPU space that should last for another year or two, giving them a great influx of cash, and their focus on Zen 2 really paid off allowing them greater cash flow to focus on GPUs as well.
[1] https://ir.amd.com/news-events/press-releases/detail/930/amd... [2] https://nvidianews.nvidia.com/news/nvidia-announces-financia...
> 4.52%, rounds to 5%, as I said.
You're misunderstanding how to properly compare profitability between two companies.
If Company A has 1 billion shares outstanding and earns $0.10 per share, that's $100m in profit.
If Company B has 10 billion shares outstanding and earns $0.05 per share, that's $500m in profit.
Company A is not 100% larger on profit just because they earned more per share. It depends on how many shares you have outstanding, which is what you failed to account for.
AMD's profit was not close to 5% of Nvidia's in 2019. That is what you directly claimed (as you're saying you went by the last full fiscal year).
AMD had $341m in net income in their last full fiscal year. Nvidia had $2.8 billion in net income for their last full fiscal year. That's 12%, not 5%. And AMD's operating income was 22% of Nvidia for the last fiscal year.
The trailing four quarters and operating income, is the superior way to judge the present condition of the two companies, rather than using the prior fiscal year. Especially given the rapid ongoing improvement in AMD's business. Regardless, even going by the last full fiscal year, your 5% figure is still wrong by a large amount.
Operating income is a key measure of profitability and it's a far better manner of gauging business profitability than net income at this point. That's because the modern net income numbers are partially useless as they will include such things as asset gains/losses during the quarter. If you want to read up more on it, Warren Buffett has pointed out the absurdity of this approach on numerous occasions (if Berkshire's portfolio goes up a lot, they have to report that as net income, even though it wasn't a real profit generation event).
I didn't say anything refuting your revenue figures, because I wasn't refuting them. I'm not sure why you mention that.
Many of their AI libraries/tools are in fact open source.
They stand to be a force that could propel ARM’s strength in data center and desktop computing. For some reason you’re okay with the current x86 duopoly held by AMD and Intel, both who have their own destiny over CPUs and GPUs.
The HN crowd is incredibly biased against certain companies. Why not look at some of the potential bright sides to this for a more nuanced and balanced opinion?
You mean this Weyland "support"?
I'm not coming out and saying it's gotten significantly better, but that is a three year old article and Nvidia-wayland does work on KDE and Gnome.
https://mesa-dev.freedesktop.narkive.com/qq4iQ7RR/egl-stream...
linus is a hyperbolic jerk (as he admitted himself for a few months before resuming his hyperbolic ways) who is increasingly out of touch with anything outside the direct sphere of his projects. Like his misguided and completely unnecessary rants about ZFS or AVX.
if there are technical merits to discuss you can post those instead of just appealing to linus' hyperbole.
(I won't even say "appeal to authority" because that's not what you're appealing to. You're literally appealing to his middle finger.)
https://www.zdnet.com/article/linus-torvalds-i-hope-intels-a...
/shrug. The guy can't keep from popping off with obviously false statements about things he knows nothing about. What exactly do you want me to say? Yes, he's been a good manager for the linux kernel, but he is self-admittedly hyperbolic and statements like these show that he really doesn't have an issue running his mouth about things that he really doesn't understand.
It is the old problem with software engineers: they think expertise in one field or one area makes them a certified supergenius with relevant input in completely unrelated areas. I can't count how many times I've seen someone on HN suggest One Weird Trick To Solve Hard Problems in [aerospace/materials sciences/etc]. Linus suffers from the same thing.
His experiences with NVIDIA are probably relevant, and if so we can discuss that, but the fact that he gave someone the middle finger in a Q+A session is not. That's just Linus being an asshole.
(and him being a long-term successful project manager doesn't make him not an asshole either. Jensen's an asshole and he's one of the most successful tech CEOs of all time. Linus doesn't mince words and we should do the same - he's an asshole on a professional level, the "I'm just being blunt!" schtick is just a nice dressing for what would in any other setting be described as a textbook toxic work environment, and his defenses are textbook "haha it's just locker room talk/we're all friends here" excuses that people causing toxic work environment are wont to make. He knows it, he said he'd tone it down, that lasted about a month and he's back to hyperbolic rants about things he doesn't really understand... like ZFS and AVX. But hey I guess they're not directed at people this time.)
Again, if he's got relevant technical input we can discuss that but "linus gives the middle finger!!!!" is not the last word on the topic.
https://www.phoronix.com/scan.php?page=news_item&px=EGLStrea...
AFAIK it also ended up being literally a couple thousand lines of code, not some massive endeavor, so the Wayland guys don’t come off looking real great, looks like they have their own Not Invented Here syndrome and certainly a lot of generalized hostility towards NVIDIA. Like Torvalds, I'll be blunt, my experience is that a lot of people just know NVIDIA is evil because of these dozens of little scandals they’ve drummed up, and they almost all fall apart when you look into them, but people just fall back on asserting that NVIDIA must be up to something because of these 27 other things (that also fall apart when you poke them a bit). It is super trendy to hate on NVIDIA in the same way it’s super trendy to hate on Apple or Intel.
Example: everyone used to bitch and moan about G-Sync, the biggest innovation in gaming in 10 years. Oh, it's this proprietary standard, it's using a proprietary module, why are they doing this, why don't they support the Adaptive Sync standard? Well, at the time they started doing it, Adaptive Sync was a draft standard for power-saving in laptops that had languished for years, there was no impetus to push the standard through, there were no monitors that supported it, and no real push to implement monitors either. Why take 10 years to get things through a standards group when you can just take a FPGA and do it yourself? And once you've done all that engineering work, are you going to give it away for free? Back in 2016 I outright said that sooner or later NVIDIA would have to support Adaptive Sync or else lose the home theater market/etc as consoles gained support. People told me I was loony, "NVIDIA'S just not that kind of company", etc. Well, turns out they were that kind of company, weren't they? Turns out people were mostly mad that... NVIDIA didn't immediately give all their engineering work away for free.
The GPP is the only thing I’ve seen that really stank and they backed off that when they saw the reaction. Other than that they are mostly guilty of... using a software license you don’t like. It says a lot about the success of copyleft that anyone developing software with a proprietary license is automatically suspect.
The truth is that NVIDIA, while proprietary, does a huge amount of really great engineering in novel areas that HNers would really applaud if it were any other company. Going and making your own monitor from scratch with a FPGA so you can implement a game-changing technology is exactly the kind of go-getter attitude that this site is supposed to embody.
Variable refresh rate/GSync is a game changer. DLSS 2.0 is a game changer. Raytracing is a game changer. And you have NVIDIA to thank for all of those, "proprietary" and all. They would not exist today without NVIDIA, AMD or Intel would not have independently pushed to develop those, even though they do have open-source drivers. What a conundrum.
Nvidia earned that hostility. It's not even worth replying when you're giving a comment in such bad faith. There's a search function with many many threads that dealt with this subject before if anyone wants a less biased view of EGLStream and Wayland.
I haven't used nvidia products for about 10 years and I' m not really in to gaming or graphics, so I don't really have an opinion on them either way, either business or technical. I used their FreeBSD drivers back in the day and was pretty happy it allowed me to play Unreal Tournament on my FreeBSD machine :-)
Linus is not always right, but a lot of what he says is often considerably more nuanced and balanced than his "worst-of" highlight reel suggests. There are plenty of examples of that in the presentation/Q&A he did from which this excerpt comes, for example (but of course, most people only see the "fuck you" part).
So if Linus – the person responsible for writing operating systems with their hardware – says they're the "worst company we deal with" then this strikes me as a good reason to at least do your research if you plan to buy hardware from them, if you intend to use it with Linux anyway. I'll take your word for it that they're doing great stuff, but if it outright refuses to work on my Linux box then that's kinda useless to me.
This was also 6 or 7 years ago I think, so perhaps things are better now too.
You generally have to wrap those and use them while not being foss-compatible.
Its possible to dislike two things at once, its also possible to be wary of new developments that give much more market power to a notoriously uncooperative and closed company.
No kidding, regarding the HN crowd. -- every time I post a comment criticizing Apple's monopoly and policies I get downvoted to oblivion, and I'd say that some of the things they do e.g. on the Apple store and proprietary hardware/software combinations are far more egregious than anything Nvidia has ever done. The HN algorithm basically encourages an echo chamber of people who gang up and downvote/flag others who don't agree with the gang opinion.
(Psst ... If you see this comment disappear after a while, it's probably because the same Apple fanboys found this comment and decided to hammer it down again.)
[Edit: I disagree with my past self of having put this comment here. This is something that if one feels that they notice, they should probably comment on. Leaving it here for clarity's sake]
> The HN algorithm basically encourages an echo chamber of people who gang up and downvote/flag others who don't agree with the gang opinion.
or this:
> (Psst ... If you see this comment disappear after a while, it's probably because the same Apple fanboys found this comment and decided to hammer it down again.)
than this:
> criticizing Apple's monopoly and policies
Source: Have criticized Apple without having been downvoted and flagged.
- The idea that we can trust Apple with privacy, when their OS isn't open source
- The idea that the Apple Store is doing good things in the disguise of privacy when they actually play corporate favoritism and unfairly monopolize the app market
- The idea that a PIN has enough entropy to be a good measure of security
- Right to repair, soldered-to-motherboard SSDs
- The environmental waste associated with the lack of upgradability
- Price gouging on upgrades ($400 for +512GB, anyone? When I can get 4TB on Amazon for $500?) and lack of user upgradability
I've been downvoted to hell for speaking the above. There are a bunch of brainwashed Apple worshippers lurking around here who don't accept any criticism of the holy.
I totally welcome engaging in an intelligent discussion about any of the above, but downvotes and flagging (in most cases without any response) doesn't accomplish any of that, and serves just to amplify the fanboy echo chamber.
Also, I don't think criticizing HN's algorithm or design should warrant being flagged or downvoted, either. Downvoting should be reserved for trolling, not intelligent protest. I'm also of the opinion that downvotes shouldn't be used for well-written disagreement, as that creates an echo chamber and suppresses non-majority opinions.
Fair enough. I don't think I've ever mentioned Apple by name, just participated in threads about them and commented on how I disagree about how they do some things.
I also went and reread some of my comments, and realized I haven't criticized Apple as much here as I'd originally thought. Apparently I mostly stick to that in meatspace.
> There are a bunch of brainwashed Apple worshippers lurking around here who don't accept any criticism of the holy.
As there are everywhere unfortunately. I haven't run into many here personally, but have no difficulty believing they are here.
> Also, I don't think criticizing HN's algorithm or design should warrant being flagged or downvoted, either. Downvoting should be reserved for trolling, not intelligent protest. I'm also of the opinion that downvotes shouldn't be used for well-written disagreement, as that creates an echo chamber and suppresses non-majority opinions.
I agree here as well. I was more trying to point out the combative tone then the content of the text. There was also some content that could be interpreted as accusations of shilling, which is technically against the guidelines.
To be clear -- I don't think your comment was accusing people of shilling, just that I can see how people could interpret it that way.
Edit: The first quote I took from your comment really shouldn't have been there. Sorry about that. I still think if you get flagged it's because of the "(Psst..." part though. That one does come off as a bit aggressive.
This sort of $BigCo metaflamewar in which each side accuses HN of being shills for the opposite side is incredibly repetitive and tedious. It's also a cognitive bias; everyone feels like the community (and the moderators for that matter) is biased against whatever view they favor.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
https://news.ycombinator.com/newsguidelines.html
because as a NVIDIA user of the last 20 years, I never saw such bright side when it comes to open source.
1. The continued conglomeratization in the tech sector is a worrying trend as we see fewer and fewer small players.
2. Only a large-ish company could provide effective competition in the CPU/ISA/architecture space against the current x86 duopoly.
The big practical issue is probably software compatibility and the like, and it seems to me that the Apple/macOS adoption will do more for that than nVidia ownership.
Maybe Nintendo/Sony uses Nvidia cards on their developer machines? I imagine FreeBSD drivers aren't simply altruism on their part.
On the other hand, stagnation on other fronts:
- Nouveau (tried recently) is basically unusable on Ubuntu. As in the mouse/keyboard locks every 6 seconds.
- Proprietary drivers won't work with wayland
And since their stuff isn't open, the community can't do much to push Nouveau forward.
It's maintained while simultaneously not receiving any new features.
The latest FreeBSD driver is 450.66, published 2020-8-18. Supports RTX 20xx, GTX 16xx, GTX 10xx, and older.
It's less of a driver and more of an operating system. Basically self-contained with all the support libraries it needs. Super easy to port to a new operating system and any driver improvement work on all OSes.
But the approach also has many downsides. It's big. It ignores all the native stuff (like linux's GEM interface).
It also has random issues with locking up the entire system. Like if you are debugging a process with the linux drivers, a breakpoint or a pause in the wrong place can deadlock the system.
If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.
In fact it is. For Linux and FreeBSD Nvidia distributes exactly the same blob for compilation into nvidia.ko; the blobs for nvidia-modeset.ko are slightly different. (Don't take my word for it, download both drivers and compare kernel/nvidia/nv-kernel.o_binary with src/nvidia/nv-kernel.o.) Nothing is locked in the closed source part.
> Despite popular misconceptions to the contrary, Horizon [The switch software's codename] is not largely derived from FreeBSD code, nor from Android, although the software licence[7] and reverse engineering efforts[8][9] have revealed that Nintendo does use some code from both in some system services and drivers.
That being said, at least one of the Playstation's runs a modified form of FreeBSD.
Edit: add [The ... codename]
I don't really see how this deal makes the CPU market worse -- wasn't the ARM market for mobile devices basically dominated by Qualcomm for years? Plus, the other existing ARM licensees don't seem to be impacted. On the other hand, I do see a lot of potential if Nvidia is serious about innovating in the CPU space.
It’s an excellent deal for NVIDIA of course, I’m certain they intend to make the chips they produce much faster than the ones they license (if they even ever release another open design) to the point where buying CPUs from Nvidia might be they only game in town. We’ll have to see but this is what I expect to happen.
I'm not claiming I'm right and you're wrong, of course. I just think it's unfair to make negative assumptions at this point, so wanted to paint a possible good thing.
NVIDIA already has an CPU architect team building their own ARM CPUs with an unlimited ARM license.
ARM doesn't give NVIDIA a world-class CPU team like apple's, amazon's or fujitsu. ARM own cores are "meh" at best. Buying such a team, would also have been much cheaper than 40b$.
Mobile ARM chips are meh, but nvidia doesn't have GPUs for that segment, and their current architectures probably don't work well there. The only ARM chips that are ok-ish are embedded/IoT at < 1W power envelope. It would probably take nvidia 10 years to develop GPUs for that segment, the margins on that segment are razor thin (0.10$ is the cost of a full SoC on that segment), and it is unclear whether applications on that segment need GPUs (your toaster certainly does not).
The UK appears to require huge R&D investments in ARM to allow the sale. And ARMs bottom line is 300million $/year in revenue, which is peanuts for nvidia.
So if anything, ARM has a lot to win here with nvidia pumping in money like crazy to try to improve ARM's CPU offering. Yet this all seem super-risky because at the segments ARM is competing at, RISC-V competes as well, and without royalties. It is hard to compete against something that's free, even if it is slightly less good. And chances are that over the next 10 years RISC-V will have much better cores (NVIDIA themselves started replacing ARM cores with RISC-V cores in their GPUs years ago already...).
Either way, the claim that it is obvious to everybody what the 3D-chess being played here is false. To me this looks like a bad buy for nvidia. They could have paid 1 billion for a world class CPU team and just continue to license ARM and/or switch to RISC-V chips. Instead they are spending 40 billion in a company that makes 300 million a year, makes meh-cpus, is heavily regulated in the UK and the world, has problems with China due to being in the West, have to invest in the UK which is leaving the EU in a couple of weeks, etc.
Famously, the Tegra SoCs, as used in the Nintendo Switch.
Are you referring to the Graviton2 for Amazon? If so, you might be interested to learn that ARM designed the cores in that chip.
> (NVIDIA themselves started replacing ARM cores with RISC-V cores in their GPUs years ago already...).
The only info on this I'm aware of is https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI..., which says nvidia is replacing some internal proprietary RISC ISA with RISC-V, not replacing ARM with RISC-V.
RISC-V and ARM can coexist, but RISC-V in the mainstream is a far away due to nothing more than momentum. People won't even touch Intel in a mobile device anymore, not just because of power usage, but software compatibility.
Does anyone know if or how Apple will be affected by this? What are the licensing agreements on the ISA?
Owning ARM would make no sense for them as they would gain no IP but would have to deal with antitrust which would force them to continue licensing the ip to others, which is not a business they are in.
If ARM vanished tomorrow I doubt it would affect apple’s business at all.
I think it will also bring Google and Nvidia closer together
Now arm is yet another US company.
This is going to do especially bad things for anyone who needs to buy a cell phone or the SoC that powers one. There's no real alternative to ARM-based phone SoCs. Given Nvidia's business practices, any manufacturer who doesn't already have a perpetual ARM license should expect to have to pay a lot more money into Jensen Huang's retirement fund going forward. These costs will be passed on to consumers and will also provide an avenue for perpetual license holders to raise their consumer prices to match.
The problem is that there are no x86 SoCs that are sufficiently power efficient to be battery-life competitive with ARM SoCs in phones.
RISV-V is a lot of talk and hype but the actual silicon that you could buy and implement into a product is hard to come by. With the exception of a few small microcontroller efforts (GigaDevice, Sipeed).
If it makes you feel any better, studies of acquisitions show that most of them are duds and destroy acquirer shareholder value.
> Huang told me that first thing that the combined company will do is to, “bring NVIDIA technology through Arm’s vast network.” So I’d expect NVIDIA GPU and NPU IP to become available quickly to smartphone, tablet, TV and automobile SoC providers as quickly as possible.
> Arm CEO Simon Segars framed it well when he told me, “We're moving into a world where software doesn't just run in one place. Your application today might run in the cloud, it might run on your phone, and there might be some embedded application running on a device, but I think increasingly and with the rollout of 5g and with some of the technologies that Jensen was just talking about this kind of application will become spread across all of those places. Delivering that and managing that there's a huge task to do."
> Huang ... “We're about to enter a phase, where we're going to create an internet that is thousands of times bigger than the internet that we enjoy today. A lot of people don't realize this. And so, so we would like to create a computing company for this age of AI.”
Now, every reference-implementation ARM processor manufactured will fund GeForce desktop products, datacenter/enterprise, etc as well.
NVIDIA definitely needs something like this in the face of the new Samsung deal, as well as AMD's pre-existing console deals.
GPU profits should be able to cover their own R&D, especially given the obscene prices on the high end cards.
That's like throwing pennies onto a pile of gold. NVIDIA makes billions of yearly revenue. ARM makes ~300 million. NVIDIA revenue is 60% of a GPU price. ARM margins in IoT/embedded/phone chips are thin-to-non-existent. If anything, NVIDIA will need to cut GPU spending to push ARM to the moon. And the announcement already suggest that this will happen.
That margins on $1 microcontroller are "thin-to-non-existent" is thus completely irrelevant - those are margins of the silicon manufacturer, not ARM's.
Console makers dictated that RDNA must use a forward-compatible version of the GCN ISA. While AMD might have wanted to make some changes of some ideas that turned out to be less-than-optimal, they cannot because they are stopped by the console makers paying the bills.
Mali support is done by outside groups (not ARM). Midgard and Bifrost models are well supported (anything that starts with a T or G, respectively). Support for older models is a little worse, but better than some other GPUs.
Adreno support is done by outside groups (not Qualcomm) and is lagging behind new GPUs that come out considerably.
PowerVR GPUs (Imagination) have terrible open source support.
They did contribute somewhat to the "tegra" driver at least.
Not all fashionable words are devoid of meaning.
Even if it does get approved, and even if NVIDIA decides to not screw up any of the licensees, the whole notion of NVIDIA being capable of doing so to any of their (NVIDIA's) competitors, will surely mean extra selling points for all of ARM competitors like MIPS, RISC-V etc.
If not then it's very likely that NVIDIA will do everything in it's power to increase prices for ARM designs.
Aside from that, ARM was one of the only actual tech companies the UK could talk about on the so-called "world stage", that has survived more than 2 decades. But instead, they continue to sell themselves and their businesses to the US instead of vice versa.
In 2011, I thought that they would learn the lessons and warnings highlighted from Eric Schmidt about the UK creating long standing tech companies like FAANMG. [0] I had high hopes for them to learn from this, but after 2016 with Softbank and now this, it is just typical.
ARM will certainly be more expensive after this and will certainly be even more closed-source, since their Mali GPUs drivers were already as closed as Nvidia's GPUs. This is a terrible outcome I have seen but from Nvidia's perspective, it makes sense. From a FOSS perspective, ARM is dead, long live RISC-V.
[0] https://www.theguardian.com/technology/2011/aug/26/eric-schm...
I think it's enough to know what Nvidia is, how they operate, and what their general strategies are.
Not saying I agree with the analysis... but I am not that optimistic.
If you take at face value anything from a press release, earnings call or investor relations website, then I would like to take a moment to share with you the prospectus of Brooklyn Bridge LLC.
https://www.oculus.com/blog/a-single-way-to-log-into-oculus-...
Discussed here on HN, with the top comment being a copy and paste of Palmer Lucky's acknowledgement that the early critics turned out to be correct:
https://news.ycombinator.com/item?id=24201306
Different situation, different companies, but if you "follow the money" you'll never be too far wrong.
why are people going out of their ways to avoid the obvious and intuitive "FAGMAN" acronym?
Jensen's not an idiot, how many OG 90s tech CEOs are still at the helm of the company they founded? Any severely negative moves towards their customers just drives them into RISC-V and they know that.
Yes, ARM customers will be paying more for their ARM IP. No, NVIDIA is not going to burn ARM to the ground.
https://news.ycombinator.com/item?id=19118642
Nvidia already own the parallel compute/ML part of the datacenter and the Mellanox acquisition had brought the ability to compete in the networking part of the datacenter - but they were missing CPU IP, for tasks that aren't well matched to the GPU. This plugs that hole. They are in control of a complete data-center solution now.
(a) NVIDIA becomes a full-fledged full-stack house, they have both CPU and GPU now. They can now compete with AMD and Intel on equal terms. That has huge implications in the datacenter.
(b) GeForce becomes the reference implementation of the GPU, ARM processors now directly fund NVIDIA's desktop/datacenter R&D in the same way consoles and Samsung SOCs fund Radeon's R&D. CUDA can be used anywhere on any platform easily.
(c) Acqui-hire for CPU development talent. NVIDIA's efforts in this area have not been very good to date. Now they have an entire team that is experienced in developing ARM and can aim the direction of development where they want.
Basically there's a reason that NVIDIA was willing to pay more than anyone else for this property. And (Softbank's) Son desperately needed a big financial win to show his investors that he's not a fucking idiot for paying $32b for ARM and to make up for his other recent losses.
NVIDIA was so well run, but boxed into a smaller graphics card market - ATI and it were forced into low margins since they were made replaceable by OpenGL and DirectX standards. For the standard fans - they resulted a wealth transfer from NVIDIA to Apple etc. and reduced capital available for R&D.
NVIDIA was constantly attacked by a much bigger Intel (which changed interfaces to kill products and was made to pay by a court)
Through innovation, developing new technologies (CUDA) they increased market cap, and have used that to buy Arm/Mellanox.
I love the story of the underdog run by a founder, innovating it’s way to getting into new markets against harsh competition. Win for capitalism!
https://www.extremetech.com/computing/312528-nvidia-overtake...
This acquisition can be seen as a beacon of nvidia's past struggle against the market and the competitors.
For whatever happened, nvidia innovated to their success, and had enabled possibly the biggest tech boom so far through deep learning. Might be one day everyone claimed nvidia to be the "most important company" on earth.
Not correct Mellanox was bought for $7B.
[1] https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI...
"The proposed transaction is subject to customary closing conditions, including the receipt of regulatory approvals for the U.K., China, the European Union and the United States. Completion of the transaction is expected to take place in approximately 18 months."
Hopefully, the EU does its job, laughs at this and tells Nvidia to either go home or forces them to FRAND licensing of ARM IP.
FRAND licensing is worthless, if Qualcomm taught us anything.
An open architecture, and business model based on partnership doesn't really synchronize with vendor locking your products for increased profits.
From a purely capitalistic standpoint, it's fine to kill off some of your customer base if you make more money from the remainder. If it can work for tobacco, you believe that Nvidia is will to kill off some of its customers if they can get the remainder to pay more.
The perpetual architecture license folks that make their own cores like Apple, Samsung, Qualcomm, and Fujitsu (I think they needed this for the A64FX, right?) will be fine, and may just fork off on the ARMv8.3 spec, adding a few instructions here or there. Apple especially will be fine as they can get code into LLVM for whatever "Apple Silicon" evolves into over time.
The smaller vendors that license core designs (like the A5x and A7x series, etc.) like Allwinner, Rockchip, and Broadcom are probably in a worse state - nVidia could cut them off from any new designs. I'd be scrambling for an alternative if I were any of these companies.
Long term, it really depends on how nVidia acts - they could release low end cores with no license fees to try to fend off RISC-V, but that hasn't been overly successful when tried earlier with the SPARC and Power architectures. Best case scenario, they keep all the perpetual architecture people happy and architecturally coherent, and release some interesting datacenter chips, leaving the low end (and low margin) to 3rd parties.
Hopefully they'll also try to mend fences with the open source community, or at least avoid repeating past offenses.
Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.
True about frenemies the entire time that Apple was suing Samsung, it was using Samsung to manufacture many of its components.
Since they're not branding it as ARM in any way, shape, or form, and they have a perpetual architectural license to the ISA, I suspect they could do pretty much what they please - as long as they don't call it ARM. Which they don't.
Even if not, then yes, I would imagine that a behemoth of IP design like Apple would probably have considered IP rights during that design...
Yea, they got fucked by Nvidia business practices multiple times. There's a saying about shame on you, shame on me, etc. Unless the entire Nvidia business unit also gets replaced in the same transaction, it doesn't matter how much of a faux separation of concerns they want to market.
Not to mention starting a JV has nothing to do with perpetual IP access. You will still have to pay for it.
I obviously don't know that for sure but the idea that Apple would stake their future on something they don't have a legal ironclad position seems unlikely.
I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.
Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.
As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.
First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff.
Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc
Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat.
Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad?
All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.
The vast majority of the code written for any given computer or smartphone doesn't have this level of sophistication and optimization though. I'd wager that for most code just changing the build target will indeed mostly just work.
It won't be painless but modern code tends to be so high level and abstracted (especially on smartphones) than the underlying ISA matters a lot less than in the past.
Also - why would Apple massively up and change uArchs? Even if they did decide to turn Apple Silicon into not-ARM, I'd wager it would look a lot more like ARM than for example, x86 does.
This isn't a question of precise instruction timing, it's a question of compilers being pretty bad at leveraging SIMD in general, even in 2020. Also, while I'm sure lots of projects have hand-tuned assembly, even higher level stuff like intrinsics help a lot, and need manual porting.
Offer customers iOS apps and games on the next MacBook as a straight swap for Boot Camp and Parallels. Once they’ve moved everyone over to their own chips and brought back Rosetta and U/Bs they’re essentially free to replace whatever they like at the architecture level.
In their reveal I noticed that they only mentioned ARM binaries running in virtual environments. It makes sense if you don’t want to commit to supporting GNU tools natively on your devices (as it would mean sticking with an established ISA)
Apple is large enough that if they want to break from ARM in the future they can do so by forking an LLVM backend. That's not a large job if it's a very small change, but once it's been done once they have plenty of resources to provide ongoing support (like they do for webkit).
The dividends of doing so are potentially massive. Given that they've been able to make really large gains with the A series chips to date on mobile (not least because they've been able to offload tasks to dedicated co-processors that general-purpose ARM cores don't ship with), the rewards for having chips that are a generation ahead of other like-for-like computers will outweigh the cost of maintaining the software.
There is one thing they would need to worry about though, which is that if the rest of the market moves to RISC-V or x64 or whatever else, it's not implausible that someone might at some point make a processor which is superior to the ones those companies make in-house. If it's the same architecture, you just buy them or license the design and put them in your devices. If it's not, you're stuck between suffering an architecture transition that your competitors have already put behind them or sticking with your uncompetitive in-house designs using the old architecture that nobody else wants anymore.
Their best move might be to forget about the architecture license and make the switch to something else with the rest of the market.
This assumes that there isn't some other factor in transitioning architecture - this argument could boil down in the mid 2000's to "Why not go x86/amd64", but you couldn't buy a license to that easily (would need to be 3-way with Intel/AMD to further complicate things)
Apple has done quite well with their ARM license, outperforming the rest of the mobile form factor CPU market by a considerable margin. I don't doubt that they could transition - they've done it successfully 3 times already, even before the current ARM transition.
Apple under Cook has said they want to "to own and control the primary technologies behind the products we make". I doubt they'd turn away from that now to become dependent on an outside technology, especially given how deep their pockets are.
But that has really nothing to do with the architecture. They just spent more money on CPU R&D than their ARM competitors. They could have done the same thing with RISC-V, and if that's where the rest of the industry is going, they could be better off going there too. Especially for Mac, since they're about to do a transition anyway. They could benefit from putting it off for another year while they change the target architecture to something the rest of the market might not be expected to avoid in the future.
There is also no guarantee that their success is permanent. They might have done a better job than Qualcomm this year, but what happens tomorrow, if Google throws their hat into the ring, or AMD makes a strong play for the mobile market, or Intel gets their heads out of their butts, or China decides they want the crown and gives a design team an unlimited budget? There is value in the ability to switch easily in the event that someone else is the king of the mountain for a while.
> I don't doubt that they could transition - they've done it successfully 3 times already, even before the current ARM transition.
Just because they can do it doesn't mean it's free.
Really if Intel was shrewd, they'd recognize that they've lost Apple's business already and just sell them an x86 license, under some terms that Intel would care about and Apple wouldn't, like they can only put the chips in their own devices. Then Apple could save themselves the transition entirely and do another refresh with processors from Intel while they put their CPU team to task redesigning their own chips to be x86_64. It would give both Apple and Intel a chance to throw a punch at Nvidia (which neither of them like) while helping both of them. Apple by avoiding the Mac transition cost and Intel by maintaining the market share of their processor architecture and earning them whatever money they get from Apple for the license.
And it gives Intel a chance to win Apple's business back. All they have to do is design a better CPU than Apple does in-house, and Apple could start shipping them again without having to switch architectures. Which is also of value to Apple because it allows them to do just that if Intel does produce a better CPU than they do at any point in the future.
And you don't want to move to ARM if everybody else is moving away from it.
EDIT: correction, make that the last generation or four (oops, time flies)
It all happened because Apple came out with the first 64-bit design, and QCOMM wasn't ready. Rather than deliver 32-bit for 1 more year, they used an off the shelf ARM 64-bit design (A57) in their SoC called the Snapdragon 810, and boy was it terrible.
On mobile SoC margins I guess that margins are low because there is a lot of competition - start cutting off IP to the competition and margins will rise.
I suspect that their focus will be on the server / automotive to start off with but the very fact that they can to any of this is troubling for me.
They could, but that's more than just an easy money grab. Something Nvidia would already be familiar with from Tegra.
What seems more likely/risky would be nvidia starts charging a premium for a Mali replacement, or begins sandbagging Mali on the lower end of things. But Qualcomm already has Adreno to defend against that.
The latest Tegra SoC launched March of 2020.
Why would they do that anyway? The downsides are obvious (immediate loss of revenue), the risks are huge (antitrust litigation, big boost to RiscV or even Mips), the possible benefits are nebulous.
Those who are most obviously at risk are designers of mobile GPUs (Broadcom, PowerVR ...).
No, they may not. People keep suggesting these kinds of things, but part of the license agreement is that you can't modify the ISA. Only ARM can do that.
(famously so, Intel used to ship arm chips with WMMX and Apple for example ships their CPU today with the AMX AI acceleration extension)
Please, stop spreading nonsense. All of this is public knowledge.
The Neural Engine is a completely separate hardware block, and you have good reasons to have such an extension available on the CPU directly, to reduce latency for short-running tasks.
Let me repeat this: part of the ARM architectural license says that you can't modify the ISA. You have to implement a whole subset (the manual says what's mandatory and what's optional), and only that. This is, as I've been saying, public knowledge. This is how it works. And there are very good reasons for this, like avoiding fragmentation and losing control of their own ISA.
And once again, stop spreading misinformation.
Specifically about the Apple case,
After your tone, not certainly obligated to answer but will write one quickly...
Apple A13 adds AMX, a set of (mostly) AI acceleration instructions that are also useful for matrix math in general. The AMX configuration happens at the level of the AMX_CONFIG_EL1/EL12/EL2/EL21 registers, with AMX_STATE_T_EL1 and AMX_CONTEXT_EL1 being also present.
The list of instructions is at https://pastebin.ubuntu.com/p/xZmmVF7tS8/ (didn't bother to document it publicly at least at this point).
Hopefully that clears things up a bit,
And please don't ever do this again, thank you. (this also doesn't comply with the guidelines)
-- a member of the checkra1n team
Is it possible AMX is implemented with the implementation-defined system registers and aliases of SYS/SYSL in the encoding space reserved for implementation-defined system instructions? Do you have the encodings for the AMX instructions?
A sample instruction: 20 12 20 00... which doesn't in any stretch parse as a valid arm64 instruction in the Arm specification.
Edit: Some other AMX combinations off-hand:
00 10 20 00
21 12 20 00
20 12 20 00
40 10 20 00
(+ there's the can of worms of target-specific MSRs being writable from user-space, Apple does this as part of APRR to flip the JIT region from RW- to R-X and vice-versa without going through a trip to the kernel. That also has the advantage that the state is modifiable per-thread)
> There’s been a lot of confusion as to what this means, as until now it hadn’t been widely known that Arm architecture licensees were allowed to extend their ISA with custom instructions. We weren’t able to get any confirmation from either Apple or Arm on the matter, but one thing that is clear is that Apple isn’t publicly exposing these new instructions to developers, and they’re not included in Apple’s public compilers. We do know, however, that Apple internally does have compilers available for it, and libraries such as the Acclerate.framework seem to be able to take advantage of AMX. [0]
my123's instruction names leads to a very shallow rabbit hole on google, which turns up a similar list [1]
Agreed upon: ['amxclr', 'amxextrx', 'amxextry', 'amxfma16', 'amxfma32', 'amxfma64', 'amxfms16', 'amxfms32', 'amxfms64', 'amxgenlut', 'amxldx', 'amxldy', 'amxldz', 'amxldzi', 'amxmac16', 'amxmatfp', 'amxmatint', 'amxset', 'amxstx', 'amxsty', 'amxstz', 'amxstzi', 'amxvecfp', 'amxvecint']
my123 also has ['amxextrh', 'amxextrv'].
[0] https://www.anandtech.com/show/14892/the-apple-iphone-11-pro....
[1] https://www.realworldtech.com/forum/?threadid=187087&curpost...
Broadcom has an architectural license. They do also license core designs.
Really if nVidia locks up the lower end cores, then a lot of stuff breaks. Billions of super tiny ARM cores are everywhere. ARM has few competitors in the instruction set space for low end, low power, low cost cores. AVR, PIC, and MIPS are what come to mind. And AVR/PIC are owned by Microchip corporation.
These ARM chip unit licenses are dirt cheap, there's hundreds of small manufacturers, and their chips go in everything, and in unexpected places. And these aren't just little microprocessors anymore. They're even in SoCs as little coprocessors that manage separate hardware components in realtime.
The amount of penetration ARM has in hidden places cannot be underestimated. And there isn't a quick replacement for them. Not one freely licensed to any manufacturer.
There isn't a huge amount of competition in the consumer/midrange sector. Nvidia has almost total market domination here. Really we just need a credible cross platform solution that could open up gpgpu on AMD. I'm surprised Apple isn't pushing this more, as they heavily use ML on-device and to actually train anything you need Nvidia hardware (eg try buying a Macbook for local deep learning training using only apple approved bits, it's hard!). Maybe they'll bring out their own training silicon at some point.
Also you need to make a distinction between training and inference hardware. Nvidia absolutely dominate model training, but inference is comparably simpler to implement and there is more competition there - often you don't even need dedicated hardware beyond a cpu.