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]
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.
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.
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.
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.
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.
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).