Hacker News Reader

Comment by modeless | Hacker News Reader

Ugh. I hope the upcoming discrete GPUs from Intel [1] and ImgTec [2] are competitive, because Nvidia desperately needs more competition. The Nvidia Linux driver situation is the single worst part of using Linux for me. I've lost count of the number of times Nvidia has rendered my machine unbootable for one reason or another.

[1] https://www.engadget.com/intel-xe-gpu-gamers-130000411.html

[2] Yes, ImgTec/PowerVR is getting back into the discrete GPU game! https://www.imgtec.com/blog/back-in-the-high-performance-gam...

View on HN

There's always AMD/ATI with its completely open drivers and hardware.

AMD even redesigned the silicon to isolate HDCP from rest of the core to be able to open video encoders and other HDCP facing hardware to open drivers.

Also, AMD's open driver's written by a different team in AMD. So they're not exactly 3rd party drivers.

For how long, though?

https://www.arm.com/company/news/2020/09/nvidia-to-acquire-a...

And hopefully AMD has good news on the 28th.

Unfortunately AMD totally missed the boat on ML. They need to dramatically increase their investment both in hardware and software. My impression in the past has also been that they lag in performance on the high end, and their OpenGL driver quality is not as good in terms of features and conformance either. Though I am not totally up to date on their latest stuff.

The OpenGL quality problems are strictly on the Windows side.

The open-source OpenGL drivers are very good.

I don't think any company, aside from NVidia, is working on FP16 Tensor cores. Not Intel, not AMD. Google has a systolic processor for tensor units, but that's cloud only.

I know ML is where the current money is at, but coprocessors in general seem to be applicable to far more problems than just machine learning and graphics.

Just food for thought:

What if AMD actually acquires Xilinix?

Everybody thought it's about CPU-FPGA integration but, they may pull something very, very different.

I'm not an expert on Xilinx's stuff, but Xilinx's 18-bit x 27-bit multiplier DSP48 architecture still seems quite awkward to me.

https://www.xilinx.com/support/documentation/white_papers/wp...

True, a systolic processor can be built out of these components, but I doubt it'd be anything as fast as a proper matrix-multiplication unit that NVidia is putting out. And that's after the complications associated with FPGA programming.

----------

Xilinx's FPGAs are a combination of LUTs (4-bit or 6-bit look-up tables), Routing, and "DSP Slices" (prefabricated multipliers). The bulk of your math is still going to be performed in the DSP Slice.

Where FPGAs win is that their LUTs and Routing tables allow you to create custom high-speed glue-logic between these DSP slices. But when it comes to something like a regular Convolutional neural net, the routing is very straightforward.

------

I'm not really a deep learning expert. I know that FP16 seems to be pushed by NVidia. This INT8 stuff seems odd to me (there's no way INT8 gets the same dynamic range as FP16), but I'm also not really sure if the dynamic range is needed or useful in deep learning applications.

I've done some systolic processors on Xilinx hardware. It's really dang hard, on their biggest, fanciest chips, to pump the DSPs at anything close to their advertised clock speeds. Maybe if I was smarter, I could do an asynchronous design that would somehow avoid clocking issues, but I suspect that doing async between mismatched clock regions would effectively halve the clock (and that might be optimistic).

The only consolation for me is that I/O over PCI ends up being my ultimate bottleneck. If AMD did a full-on integration with their infinity fabric, it could actually be a game changer. For me, in my weirdo niche.

I'm pretty sure I/O over PCIe is a substantial bottleneck in many applications (which is part of the reason for the 300GB/s POWER9 / OpenCAPI / NVLink / GPUs). Its a shame that NVLink is isolated to pretty much the DGX-line of computers and POWER9 (The "big" ones too, I don't think Talos II supports NVLink). But I guess an interconnect that fast will require dedicated, non-standard hardware.

----------

AMD's GPU Infinity Fabric seems to be a different infinity fabric from their CPU. CPU Infinity Fabric is ~50GB/s, but the GPU Infinity Fabric is GPU-to-GPU links of ~90GB/s.

Realistically, PCIe 4.0 and 5.0 will be the path forward for standard PCs. There will always be incredible application-specific solutions (such as NVLink / NVSwitch on the DGX), but the general computer user will wait for the open standards to support such speeds before adopting them.

At the moment, GPU-to-GPU communications probably will scale better than CPU-to-GPU comms. CPUs just aren't built for the bandwidth (outside of POWER9 / POWER10).

  Unfortunately AMD totally missed the boat on ML.

I think by this measure so did everyone else. Nvidia pushed cuda, and everyone took it, even though 8 or so years ago openCL was a reasonable competitor. But various orgs choose to make a proprietary technology a first class citizen rather than putting the effort into an open alternative. Big win for nvidia, big loss for everyone else not large enough to create their own ML frameworks and accelerators.

Its not really about CUDA or OpenCL. Its about the choice to support FP16 matrix-multiplication at the assembly level of NVidia chips.

When you build a processor that literally has "do 4x4 matrix multiplication" as an assembly statement, you'll get far superior ML performance compared to everyone else. (Except Google's TPUs, which have larger matrix-multiplication arrays)

Open source is great, but AMD is not a good example of how to do open source right. AMD's drivers are often not usable in released kernels until many months after hardware is released. For example, AMD is just now adding initial support for their new GPUs [1]. From what I have read, good support for AMD's previous generation is only now getting to distributions.

Intel on the other hand typically has their drivers in released kernels long before their hardware is released. Intel's New GPUs haven't been released yet, but they first started adding support in early 2019 [2]. I can't find it now, but I remember hearing a story about Intel removing drivers from the kernel tree for some hardware that they cancelled.

If you want to use a modern high-end GPU in Linux, your only real choice continues to be Nvidia. Their drivers are not open source, but at least they work at launch (except maybe with a 5.9 kernel?).

This is why Intel entering into the high-end GPU space is so exciting. Soon we may have a high-end option with good open source drivers while the part is still high-end.

[1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

[2] https://www.forbes.com/sites/jasonevangelho/2019/02/18/intel...

This comment is very weird. For Linux users it is definitely better buying an AMD discrete graphics card than Nvidia, and it has been for an eternity. Just google "torvalds Nvidia" as an example of how the community feels about Nvidia. Is it even possible using Nvidia cards with Wayland?

Nvidia has a history of problems in Linux. I can still remember having to log out of my X session just to change monitor layout; which is something you do alot with a laptop and external displays. Took them several years to fix!

I've experienced intel boards where I had trouble getting anything but the newest fedora with custom kernel parameter to even get the installer running. But most of the time intel has very good upstream support, so it is normally a pretty safe bet.

With AMD there are sometimes delays getting full support for a new generation upstreamed (e.g. hdmi audio and such), so it is usually good to Google for Linux reviews first.

In general AMD has superb open source support for their cards, if not immediately at launch, and I recommend them for Linux users who want the least amount of hassle.

I've seen people recommending Nvidia to Linux on YouTube (and now here), and I honestly think it's a disfavor to anyone interested in Linux.

Your comment is highly inaccurate- and in fact is basically straight up Nvidia propoganda. The article you linked to is an article about AMD submitting code for unreleased hardware, which is exactly what you said they are not doing.

I have been using a Polaris based card for years (card released in 2017), and the drivers were submitted in 2016. The kernel drivers were ready at launch and key features like HDMI audio were all working out of the box. Now, you might need to install a modern kernel for everything to work- but that is the Linux way.

It is true that the initial performance was not super great- maybe about 70% of the possible performance, however this was addressed by subsequent improvements to mesa (userspace portion)

AMD has even gone out of their way to support older, obsolete graphics cards that were released before AMD adopted the open source first strategy.

Source: https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-P...

The difference is the timeline. Basic support landing ~1 month before launch is not acceptable. We barely have a stable kernel with this initial support, and that kernel won't have been picked up by any distributions. Further, for previous AMD hardware releases, this initial support has not been really usable from what I have read. Most of the posts I found on Reddit pointed to it taking several months after launch for the Navi drivers to stabilize. Even then, running a custom kernel in my experience is a lot more trouble than the proprietary Nvidia drivers.

Compare to Intel where you have initial basic support landing around 2 years before launch with incremental improvements following. This is the correct way to do open source drivers.

On my ThinkPad I've just disabled the Nvidia and purchased a usb hdmi dongle (pretty low profile, little more than a standard hdmi cable). I leave the Nvidia off permanently because it's the only way I can have a laptop that supports multiple monitors and doesn't fucking chew through battery. I couldn't give a toss about graphics performance, this is a work machine so I'm not playing games on it. Fuck Nvidia, and fuck Lenovo for making the Nvidia necessary in order for the hdmi port to work.

You can buy thinkpads that just have integrated graphics. The dedicated card is a desirable feature for a lot of people - Lenovo didn't go out of their way to screw you, you just bought a product that has a feature you don't need. I'm not sure why you're so angry...

I'm sure there are very legal and very cool reasons as to why, but the result is a hardware lock in to Windows.

I didn't buy it. It's a work laptop that I didn't have a choice in. But to that comment, many Linux users assume that ThinkPads are a solid mobile work horse. I certainly would have said so. But I would happily switch to a MacBook Pro from 2016. I would say that having to restart X any time you want to switch between battery saving on-the-go, and multiple monitors when you're at your desk, is a hard fail.

> Yes, ImgTec/PowerVR is getting back into the discrete GPU game!

Are FOSS drivers available? If not, ImgTec/PowerVR is worthless and they can come back from whence they came.

EDIT:

Their webpage for their current gpus list no drivers at all (where is a generic user supposed to find them?) and no mention of Linux at all.

That's not promising at all. If they want to become a failure again, they're on the right track.

Its funny you mention Intel and Img without mentioning AMD.

IMG 's drivers aren't exactly known for their quality and Intel GPU are / will be competing with a process node disadvantage.

I think it's fair to assume that most HN readers have heard of Nvidia's single existing competitor in the discrete GPU market. But many may not have heard that Intel and ImgTec are entering the market in the next year or two.

You're right that PowerVR drivers are likely to suck. However, you're wrong about Intel being at a process node disadvantage, because their GPUs are going to be fabricated by TSMC :-O

>because their GPUs are going to be fabricated by TSMC

Only one of their specific SKUs out of dozen are fabbed by TSMC, and it was a very late addition to the lineup. As long as Intel operate their own leading edge Fab, Intel's incentive is and always will be to fully utilise their own fab capacity as much as possible in order to gain economy of scale.

PowerVR drivers have been a lot worse than anything Nvidia ever released in the past. I don’t expect open drivers from them.

Interesting to see new players. I hope they can compete on the high end, Nvidia seems a bit lost with it's direction and power budgets right now. I would imagine Apple has the know-how to scale their mobile GPU chips in some ways too but they just want efficient chips for their own devices.

> I hope the upcoming discrete GPUs from Intel [1] and ImgTec [2] are competitive, because Nvidia desperately needs more competition.

What we need is a stable driver API in Linux.

Except that the incompatibility seems to be implemented by the kernel team (again), breaking the nVidia driver.

Is that deliberate to fuck with nVidia?

Probably not. If there is a hole in the wall, you'd expect that it's gonna be fixed at some point, and not claiming it's a feature of the wall.

nVidia probably saw this coming, but doesn't care that much to proactively work on it.

Most of those running ML applications don't have to update the kernel very promptly, and they only have to wait until mid-November, according to nVidia. This few months of delay couldn't possibly hurt nVidia to any meaningful degree.

Nice wording by Nvidia. Linux has an unstable/ever changing internal API and Nvidia need to update their out of tree driver for the new release, and probably every release.

Nvidia is trying to put the blame on Linux, but Intel and AMD don't have these issues because they open sourced and upstreamed their drivers (for AMD they mostly did), which is the way to work with open source.

Linux has always been fighting an uphill battle, but as it becomes more and more relevant it is becoming increasingly difficult to fight against it. Intel understands this, and AMD understands this.

The wording by Nvidia is telling for how they view Linux I think. In fairness it's probably very costly for them to go open source (one time cost at least).

Care to point out where in TFA Nvidia has been putting the blame on Linux?

The specific wording was "Linux Kernel 5.9+ is incompatible with current and previous NVIDIA Linux GPU drivers."

So it's not the driver that is incompatible, it is Linux. And that led to the grandparent comment asking if Linux people are "deliberate to fuck with nvidia".

If nvidia had said "our driver is incompatible with the newest Linux kernel" then we probably wouldn't been having this thread.

Reply on news.ycombinator.com