Having said that, looking to the future I think Apple is clearly willing to pour more resources into their CPU programme than any of their competitors. This means the risk to them is probably a lot less than to say Qualcomm or Samsung as they have a much better capability to go their own way. As time goes on their designs will probably diverge more and more from main line ARM anyway.
This would have to be the case, because Apple still uses many of their earlier ARM designs in products, which we know used ARM designed cores and would definitely require core design licenses.
> Is there a phone on the planet that doesn't run ARM?
Well, technically, yes ;-) This does not change anything to your point though.
[1] https://en.wikipedia.org/wiki/Asus_ZenFone#Second_generation...
There were some annoying software aspects (the Play Store only allowed me to download x86 apps even though it could run ARM apps), and the device was 100% a battery hog - but cool tech.
Surprised Intel gave up on that effort.
Then they just disappeared. Either MIPS screwed up or ARM did something really smart. My money is on the former...
> Then they just disappeared. Either MIPS screwed up or ARM did something really smart. My money is on the former...
MIPS SoCs simply fell too much behind. They kept presence in the STB, and router boxes for some time, but even there they lost due to overall "deadness" of the entire ecosystem:
Want latest compiler work, and mainline GCC support? Go for ARM
Want to not to have to support your own Linux fork? Go for ARM
Want more IP coming from a single vendor that just core, interrupt, controller, and DMA? Go for ARM
Want to work with an IP vendor whose sales are not part time lawyers? Go for ARM
When MIPS understood that they are losing, they simply gave up on competing, and improving.
And in the end, the lunch went to MediaTek because it was the only SoC vendor that was ready to ship competitive SoCs with 4G baseband without rapacious licensing deals like Qualcomm do.
But then everything suddenly stopped and they left the market altogether.
Edit: Regarding this:
> Want to work with an IP vendor whose sales are not part time lawyers? Go for ARM
One of the founders of OpenCores (RIP) told me that ARM lawyers contact him _within hours_ of someone pushing a design they dont like. While MIPS has a bad rep, ARM is probably more aggressive.
Er... not convinced about this one.
ARM has been quite lawyerish sometimes.
For a while, parts of QEMU could not be published, at ARM's request, because they implemented instructions ARM did not permit a software emulator to emulate.
At least one non-commercial design on opencores.org was removed at ARM's request.
By comparison, for a while MIPS ISA was completely open for anyone to implement, software or hardware. That's been retracted now, but it was nice while it lasted. ARM has never done that as far as I know.
Even before, I used devices based around MIPS without a licence a long time ago, so long as they avoided implementing one or two "special sauce" instructions that was fine. The instructions weren't necessary, just a neat, patented optimisation, and I have a GCC patch somewhere for building the target without those instructions.
So I don't know about today, but until recently I would have consistently regarded MIPS as much less lawyerish than ARM.
Interested in this comment: were MIPS/Imagination known for being particularly litigious around licensing?
> Want to not to have to support your own Linux fork? Go for ARM
But that's also true for MIPS.
Making a Linux port for a given MIPS based SoC is a known pain. They should've worked towards not requiring any hardcoded configuration for each SoC at all, like Linux on ARM does these days.
I thought all major kernel archs were on device trees now...
So every vendor had to upstream their own soc in its own
So their MIPS stuff might be consigned to the past at this point.
I seriously doubt it, Broadcom - Qualcomm sale was blocked because there were concerns that the former would inhibit the telecom technologies development of the latter, resulting in strategic disadvantage to U.S. But, in the case of supposed Nvidia-ARM sale I see the quite opposite i.e. huge strategic advantage to U.S. and so I feel the anti-trust might not be at least State initiated.
But, would other U.S. Big Tech who have invested heavily in the ARM ecosystem oppose this is what to be seen. But even there, I wonder whether their fear could be substantiated? What if Nvidia just signs a good agreement with them to alleviate their fears? After all Apple and Qualcomm were strangling each other throats, now see where they are now.
In the end, I think the deal would just go through and it's us who are worried about the future our Raspberry Pis among others things who would feel lost(and actually loose).
British resistance caused American Pfizer to walk away from a potential merger with British AstraZeneca.
There are countless examples where country 1 has stopped a merger between a company from country 2 and one from country 3.
> There are countless examples where country 1 has stopped a merger between a company from country 2 and one from country 3.
From what I've seen, the only method of enforcement for a third-party country is to ban the sale of goods in their respective markets following the merger (like GE/Honeywell in the early 2000s). Would that even be possible in this case?
Don't forget that these are public companies and a stopped merger can affect their stock. Besides, major investors would eat the board alive if they put the company in such situation.
Antitrust regulators for big markets like the US, EU can effectively block mergers from any internationally operating company. Both AMD and Nvidia need access to EU - their customers certainly do.
> Antitrust regulators for big markets like the US, EU can effectively block mergers from any internationally operating company. Both AMD and Nvidia need access to EU - their customers certainly do.
They could block the merger and if the companies decided to go ahead with it anyway, the EU would ban imports. But, wouldn't that further consolidate the market?
This has never happened, because the profit loss from both parties from losing access to a market with 400M+ people has always made investors blanche.
What I'm trying to get at is, with a sufficiently large merger, the emerging company may produce products so ubiquitous that it would be impractical to bar them from your economy, due to the widespread use of their products and their integration into other products.
I don’t see this being much liked by those authorities, either. nVidia is clearly interested in doing this deal because it will give them competitive advantages, and it’s pretty clear by their behaviour versus other firms (including Apple!) that they have so much of that already that they don’t have to “play nice”. Giving them further purview to do as they please is basically what anti-trust is designed to prevent, whether you focus on industry relations or the ascendant on consumers.
I had an SH-3 PDA in 2001, but Microsoft dropped support for SH-3 and MIPS in Windows CE by the time “Windows Smartphone 2002” came out (my 2002 HTC Canary runs ARM, IIRC) so it’d have to be a non-CE platform. What did the Palm Handspring use?
Source: I maintained the compiler test infra for it.
At some point in time it got then renamed in embedded compact.
Source: worked in the automotive together with a couple of supplier which built those systems.
What’s the current roadmap for CE? I saw there’s a new CE environment in Win10 IoT, but it feels like too-little-too-late to save the myriad of embedded enterprise CE systems.
https://techcommunity.microsoft.com/t5/internet-of-things/mo...
No clue sorry! I left many many years ago.
CE7 was incredibly good, the minimum image size we had it running on was ~20MB on disk.
Oh how naive I was!
(I assume the push for WPF-like XAML in CE7 was because at the time (2011-2012?) there was still hope of a CE7-based Windows Mobile competing with iOS and Android, and Microsoft realized the mistake of not modernizing CE's UI system at-all between 2002 and 2012? Windows Mobile 6.5 was a hideous eyesore (and all the pretty home-screen functionality was literally just skin-deep).
Intel makes both CPUs and GPUs.
AMD makes both CPUs and GPUs.
nVidia would make both CPUs and GPUs.
What would be the difference?
Actually, as long as there are a number of arm design licensees, the situation would be way better than it currently is for x86: beyond Intel and AMD there is basically no other player in that field (Via? Transmeta? are they even noticeable?).
They need to pay $30bn to buy ARM which means they want to maximize the return for that purchase, which would be selling more and not disrupt for competitors to look elsewhere.
Their new notebooks are still moving to an ARM-based CPU... Even if they enhanced the ARM design they still have an ARM licence.
Apple supposedly pays intel more for their CPUs than other OEM to avoid having their sticker on Macs; So I don't see this as odd, it's usual Apple branding tactic and from the looks of it(ARM being under threat of sale) it seems to be a wise decision as an average Apple customer wouldn't mind if it switches the architecture for its silicon.
It would be more accurate to say Apple does not receive the Marketing Discount from Intel.
In reality i seriously doubt those discount dont materialise. Intel could have given the TB3 controller for free as part of the deal. Likely less than the Sticker Discount, but still a decent cost saving.
Could they really do this? Start making incompatible designs? I would have thought that Apple's ARM architecture license would include terms to preclude incompatible forks.
For an ordinary licensee you might think so, but Apple may well have special terms, given that they co-founded ARM
?????
https://www.latimes.com/archives/la-xpm-1990-11-28-fi-4993-s...
Apple went on to use ARM in the Newton and other devices....
Nit: fazed, not phased.
...I can barely bring myself to type and submit that...
I wouldn't call it a corruption though, because I've never actually heard it in Britain; just American film and television, and even on HN.
"Dear America..." https://www.youtube.com/watch?v=om7O0MFkmpw
The intended meaning is obvious. There's plenty of colloquial phrases which say one thing but mean another: "I could murder him", for example, doesn't literally mean that. That is how language works.
And, if you saying "there's beer in the cup" was understood by everyone as meaning "there's no more beer in the cup", professional linguists and dictionaries would be A-OK with that interpretation.
The fact that "I could care less" is now clearly understood is not intentional. It's an adaptation to a mistake. It's similar to how people say "irregardless", which is clearly an error. It's unambiguous, and everyone knows what you mean. It's still a mistake, and using "regardless" is strictly better.
Yes, that's what language is. Will you be complaining about "apron" as an adaptation to a mistake?
https://www.quickanddirtytips.com/education/grammar/how-a-na...
> It's similar to how people say "irregardless", which is clearly an error.
It's an error that's been being made since 1795, though, and people have been understanding it which pretty much qualifies it as being incorporated into the language.
(I should note that I am strongly descriptivist and think that prescriptivists are silly people.)
> using "regardless" is strictly better.
I think "regardless" is better, yes, because it's a lot easier to say but that's just my opinion, not a Gilt Edged Rule Of English.
Now I learned not one but two important correct spellings. Thanks!
Since 2014, apple has almost exclusively used AMD graphics cards in computers that do have discrete GPUs, and I don't think it's unreasonable to suggest this was motivated with their terrible experience with Nvidia.
(I'm aware I'm not really backing this up with evidence, but I think the publicly available facts about the whole situation support this narrative)
In 2010, Apple wasn’t exactly a beleaguered company. It wasn’t like NVidia not reimbursing Apple would break the bank. Apple should have repaired it just to protect its reputation.
Jobs himself was famous for saying to high level employees that at a certain level of authority, you don’t get to make excuses.
Again, I agree with you, apple should have launched the program much, much earlier.
But, I mean, that's besides the point because this isn't a post about how Apple handled these failing GPUs, it's about Nvidia's inability to work with others.
To be fair, the issue was mainly caused by Apples form-over-function thermal design.
To best of my knowledge, Nvidia GPUs works just fine in all other laptops.
Laptops were only affected en masse because they have far more heat-cool thermal cycles than the average desktop computer.
Nvidia bumpgate says hello.
There's also the issue with them refusing to open source Linux drivers. Supposedly this is because they throttle workstation GPUs to create a market for higher-end versions while reducing the manufacturing diversity, but I haven't heard a definitive source for this.
Not sure about this, but they definitely prevent the loading of drivers for GeForce cards if they detect a hypervisor (Quadro cards work). Nvidia claims that it's a bug, and that they're not fixing it only because GeForce cards are not sold to be run in virtual machines. At the very least it's a dubious claim since for a short time there was an arms race as workarounds were figured out and the next version of the driver would detect them...
Of course it's market segmentation by obscurity so it only lasted a few weeks and it's trivial to work around, but still it's quite shady since there's absolutely no ill effect from the work around.
* sk1080/nvidia-kvm-patcher: Fixes "Bug" in Nvidia Driver preventing "Unsupported Configurations" from being used on KVM
I think this is because they were outcompeted by AMD in the GPU crypto days, so they didn't want to get in the way of that (nor were they likely to succeed in blocking this use).
> nVidia
FYI, a few years ago, nVidia has officially changed their name to "Nvidia"...
[0] IOMMU is not only a virtualization feature, it's also an important security feature to protect the host from DMA attacks of malicious peripherals (e.g. 1394, ExpressCard, Thunderbolt, USB 4). Fortunately Intel no longer cripples IOMMU (VT-D) since Skylake, but ECC is another story.
http://international.download.nvidia.com/partnerforce-us/Bra...
> "From the mid 90s to early-mid 2000s, stylized as nVIDIA with a large italicized lowercase "n" on products. Now officially written as NVIDIA, and stylized in the logo as nVIDIA with the lowercase "n" the same height as the uppercase "VIDIA".
It was about NVidia wanting to make it so their 3rd party GPU partners, (EVGA, Asus etc.), could only sell their popular GPU brands with NVIDIA in them, so for AMD they'd have to come up with something customers are entirely unfamiliar with.
> here's also the issue with them refusing to open source Linux drivers.
It's not just that. AMD didn't open-source their original Linux driver, presumably there could have been some 3rd party licensing issues, but they wrote a new one that is open-source.
NVIDIA doesn't even let others write an open-source driver for them, they make it purposely difficult to reverse-engineer, sign their firmware that they only release with a massive delay and generally refuse to cooperate.
Even further than this, they created such a healthy environment for it that there are now two competing open source Vulkan drivers, and the third party one (RADV) is usually winning by a bit, and is now directly supported (with staff) by Valve.
In many projects that support both, OpenCL and CUDA often give similar performance, and in some, OpenCL is faster than CUDA. So CUDA isn't about getting more performance - it's about excluding everything non-NVIDIA.
I suspect that NVIDIA's gameplaying is what led to Apple deciding to not use NVIDIA in any Macs for the last several years.
C++ support only came to OpenCL after it was clear to Khronos that it was time to move beyond C only vision of the world, yet almost no one bothered to implement OpenCL 2.x, which is why OpenCL 3.0 is basically OpenCL 1.2 to make all those OEM compliant, and SYCL is now moving into an backend agnostic C++ stack.
So the competition did not move a finger to make OpenCL eco-system beat CUDA tooling, Google did not cared one second to make OpenCL available on Android instead pushed for their own Renderscript C99 dialect, but it is easy to blame NVidia when competition isn't up to their stuff.
Just like Apple, after creating OpenCL and offering it to Khronos, moved away from their own creation after disputes on how OpenCL roadmap should be managed. Ironically, just like with CUDA, Metal Compute happens to be multiple language aware and having a modern API.
The fundamental failing Khronos made was repeating the GLSL mistake and not specifying a compiled IR that would decouple OpenCL kernel code from program execution. This was clearly known to be a mistake at the time, given ample evidence from CUDA and HLSL that an IR was possible and could greatly improve the developer experience.
You could say that: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
I think it's very clear that the framework was important here. Because you were pointing out that they don't open source much, I pointed out that they do, then you nitpicked by saying it's cuda.
To be fair, I recently bought a new Thinkpad, and with Ubuntu 20.04 and Nvidia CUDA just worked, with absolutely no tuning (I didn't even need to set LD_LIBRARY_PATH, which I found pretty odd). So things seem to be improving, because there's money in it for Nvidia.
Both Intel and AMD do have an official FLOSS Linux driver and regularly work with the wider community.
It's really not hard to find a company that nVidia's pissed off with its dealings.
But, on the plus side, it's the biggest opportunity RISC-V will ever get. Almost overnight anyone who was building ARM cores will suddenly see investments in RISC-V prudent as a hedge against nVidia's future core designs not being licenseable. SiFive will very quickly become a multi-billion dollar organization...