Hacker News Reader

Comment by digikata | Hacker News Reader

That's funny, I just built my first new home Linux desktop in maybe 7-8 years, and installed an AMD RX 480 GPU into it, because the increased openness in their devices is finally really allowing for a first class open source driver for Linux to be written for this generation of GPU. At this point it really seems to be just starting to pay off in the performance & stability departments. If they keep it up, there will be good reason (at least on Linux) to favor AMD video cards.

Here's to hoping the new AMD CPU does well too, it's good for the market that Intel has competition.

View on HN

AMD is much more open. We've been building on top of their APIs. It was so much easier than supporting the opaque APIs of Nvidia.

AMD has definitely caught my interest with the steps they've taken towards embracing open-source software recently. I run Linux full time, and the open source movement is really important to me, but I went with Intel and Nvidia when I built my new computer last year.

My last rig was all AMD, and while it was really powerful for the time it was built, it was basically a space-heater. The power supply on my current machine wouldn't even run my old computer at idle. I have a philosophical issue with the way that Nvidia and Intel handle their Linux drivers and interact with the open-source community, but after 7 years with a computer that sounded like a jet engine, I just wanted silence.

I know it seems disingenuous to compare a 7 year old computer to a modern one, but the TDP of AMD products has not improved much during that time. Plus, my computer spends most of it's time near-idle, and Intel and Nvidia look better the lower the utilization. The fans in my new rig don't even spin up unless I'm doing something rather resource intensive, like playing game.

So, despite my misgivings about Intel, there was no chance I was going to with AMD. The Bulldozer architecture is terrible. Bulldozer hasterrible performance, regardless of whether you measured actual performance, or performance per watt. The only reason I considered AMD was because they enable virtualization on all of their processors (or at least the ones I was considering), whereas Intel only allows virtualization on Xeon and K-series processors.

My biggest issue right now is that Nvidia takes steps to prevent their non-Quadro cards from working in VFIO passthrough. I could have just as easily gone AMD, which I understand works much better with VFIO; the main reason I went with Nvidia for graphics was because I got the 970 for a song. Plus, after years of using AMD with Linux, I don't really trust AMD drivers to work. Nvidia drivers might be closed-source, but they work as long I wait a week to upgrade after a new driver is released.

The Zen architecture seems like it will hit all the right notes for me, as long as AMD maintains their welcoming approach to virtualization.

> whereas Intel only allows virtualization on Xeon and K-series processors.

I'm not an expert on Intel CPU market segmentation, but I do work for Intel on the i965 Mesa driver. I don't think your statement is true.

See http://ark.intel.com/search/advanced?s=t&VTX=true

That's a list of all Intel CPUs with VT-x. It's really easy to narrow down the selection from there. FWIW, I see lots of Skylake i3, i5, and i7s with VT-x.

He probably means VT-d since he mentioned passthrough. VT-x is just the virtualization extensions needed for many hypervisors, while VT-d lets your VMs directly access the actual physical hardware. Like dedicating a physical GPU or NIC to a VM.

I'm not sure which modern CPUs and motherboards support that. I know back in the Core2 days when VT-d was first introduced, it was a nightmare to find the right combination. Looking from the outside, Intel also seems to play a lot of marketing games with their CPU features. Sometimes top-of-the-line CPUs will be missing features that others have. Like selling a $6K Xeon CPU manufactured this quarter without virtualization support. (http://ark.intel.com/products/95831/Intel-Xeon-Phi-Processor...) Supposedly they want to get that feature in there at a later date, but that's not something we like to trust in with computer components.

Your VT-x search returns 1459 products, while the VT-d search returned only 788. Here's a list of things that say they support VT-x but not VT-d (http://ark.intel.com/search/advanced?s=t&VTX=true&VTD=false). Pretty sure some entries on it are wrong, but Intel is also terrible about keeping old technology names on newer spec sheets. Maybe they folded VT-d into VT-x without telling the world?

FWIW, it appears that all of the i3, i5, and i7 Skylakes support both VT-x and VT-d.

I agree that this has been confusing in the past (as evidenced by the mix of Atom, Celeron, Pentium, i3, i5, i7, Xeon in your link), but I think at least in VT-* it's been greatly simplified.

I thought I was going crazy, because I thought only the newest Haswell K-series processors supported VT-d, but I found this link which indicates it is available on basically everything now:

http://www.tomshardware.com/answers/id-2031324/4770k-virtual...

From April 2014: Craziest thing. The i7-4770K NOW does support vt-d. It didn't used to, but went on their site today....

I checked the edit history for the Haswell architecture on Wikipedia, and it appears that VT-d was supported by all i5s and i7s, except the K series, save for the 4790k and it's i5 counterpart since at least August of 2014. I'm not sure where I got the idea is was more limited. I had been speccing a computer for a couple of years at that point, so I wouldn't be surprised if I'm digging up irrelevant information.

I'm getting ready to build a new Linux Desktop- and I am thinking about an AMD CPU, but a Nvidia GPU- from everything I have read, Nvidia's performance on Linux is far better than AMDs? Is that information out of date, or are you just forecasting future improvements by AMD? I do really appreciate the open source driver efforts by Nvidia, but I'm not sure I am willing to sacrifice that much performance at this point.

The new RadeonSI Mesa driver is a massive improvement over the previous generation drivers. My R9 290 only gets better every 6 months when I upgrade to a new Fedora release, and it's all because AMD publishes specification documents while the majority of nouveau development is still based on reverse engineering. If you care about performance, the Volcanic Islands cards and newer are all supported by AMD's proprietary AMDGPU-PRO driver which is still better than the open source ones, but I expect that gap to continue closing a lot faster than the past as the Gallium-based RadeonSI driver is a lot easier for developers to work on.

Still, comparing NVidia's current lineup to AMD isn't apples to oranges. If you want a 1070 or 1080 just get one, Vega is still months away and while we see AMD stomping in Vulkan and DX12 benchmarks compared against similarly priced cards (RX480 vs GTX 1060) they don't have a proper answer for the higher end cards until Vega is out.

Otherwise, don't let driver support deter you, the whole design behind AMDGPU-PRO is much like NVidia's proprietary drivers - it lets AMD reuse the majority of their Windows drivers to keep parity between platforms; and, again, the open source drivers only keep getting better at a rapid pace.

I do have to say that my experience between the OLDER fglrx driver (for an R9 285 card (GCN 1.2)) and the mesa 13/13.1 releases (amdgpu driver) has been that the fully open stack is MUCH MORE STABLE. It isn't perceptibly slower, but it is a lot less likely to have some weird corner case bug in random games.

nvidia raw performance is better, but requires installing a proprietary driver (like you would on windows).

amd is a bit lower, but you can use the built in open source driver and get roughly the same performance as the proprietary driver (From what i understand, the proprietary driver is going to only be there to support their direct clients, and in general, they are working on getting all generic improvements into the open driver).

From what i understand, this means kernel updates mean you have to re-build the nvidia drivers, whereas with AMD, the new drivers are included in the new kernel.

either way, I went with an AMD rx480 this month because i dislike nvidia's closed off business practices (especially in comparison to AMD's open practices). it runs everything I want it to run just fine, so its not like i suddenly cant play some game because i went AMD.

AMD was trying to push code into the linux kernel to speed up performance. However, it was recently rejected, publicly, and rather harshly.

With the push to the linux kernel AMD GPU's would be better than Nvidia... that being said, I wouldn't hold my breath.

AMD wasn't pushing code for better performance, they were pushing a janky abstraction layer for their devices to make porting their Windows driver easier, that basically did what NVidia does and skipped a lot of the existing DRM infrastructure in the kernel.

If you want to write a kernel driver that's effectively a Russian train toilet nobody will stop you, and you can feel free to maintain the engineering effort on it - but it's not going to be accepted into the mainline Kernel and you'll have to maintain it out of tree.

If AMD wants a shim to make it easier to port their Windows drivers over that's perfectly acceptable, but they need to work with the existing DRM infrastructure and the people that maintain it to get a kosher driver that everyone can be happy with.

Actually, it was rejected only in its current state. AMD is still iterating on that driver to get it in the kernel, and is working with the kernel team to get that in there.

That said, they were warned 6 months before the rejection that abstraction layers in the kernel would probably get rejected. The rejection wasn't news in any sense - Dave Airlie just decided to be more direct about it because the warning from half a year ago was ignored. No one knew that was what they were doing because AMD did all the development in private and then just handed over the code. Had they been more open and engaging with the kernel developers, they could have saved a lot of time.

There were a few emotional responses, and then it was made clear that they weren't done yet, and were still willing to work together. So everybody calmed down and got back to work. This all happened within a few days of the initial rejection, so you really shouldn't push the "it's never going in the kernel" narrative. Because much of it will probably be in there by the middle of next year.

I think that was infrastructure to support the closed driver, not the open driver.

You're thinking about the display code. That code is not that important for performance; it's about detecting and driving displays connected to your graphics cards, managing page flips and so on.

It only interacts with performance in that driving displays requires memory bandwidth and consumes power.

These last two generations of GPUs, I've gone Nvidia, after being sick and tired of fighting AMD graphics drivers, and especially fglrx.

I'm glad they're increasingly open, and it's good to see the excellent work happening in the radeon drivers et al. I've just been burned enough by them that my aversion has become quite deep seated. That and so many things favour CUDA instead of OpenCL for acceleration, which is incredibly annoying (especially as it's possible to leverage even inbuilt Intel GFX for that in addition to the main GFX card)

Exactly! They made exactly the same claims about increasing the openness of their driver in the past, but never made good on their promise.

You can only believe the same promises up to a point.

I'm also using a RX 480 on my Ubuntu 16.04 machine. We only got free-sync support very recently, and there is no overclocking/fan control or GUI of any kind.

Also, as far as I understand the open source driver is only included with Linux Kernels 4.7+ while Ubuntu 16.04 is on 4.4 (16.10 is on 4.8). So if you want to use the open source driver you have to pick your distribution carefully.

I loaded Ubuntu 16.10 into my build for just that purpose, though really it wouldn't be difficult to bump the 16.04 kernel up to 4.8+. There are also 16.04 and 16.10 ppas with different levels of mesa driver that are built and tested ahead of the main repositories (stable and nightly). If you're not interested in being that close to the bleeding edge I understand, so some of the improvements at the front-edge are maybe 6-12 months out from wider distribution.

I don't use Ubuntu, so I'm curious; is there a reason someone wouldn't upgrade from 16.04 if 16.10 is out and has drivers they need?

16.04 is a LTS-version (long term support) while .10 is not - https://wiki.ubuntu.com/LTS

16.04 is long-term support, 16.10 is not. The difference is, that 16.10 will be supported for 9 months, while 16.04 for 5 years.

If you like reinstalling every few months, the non-LTS release is fine. Most people don't, so they prefer the LTS release.

Slightly OT but why is the .10 release always the short-term release and .04 the LTS? You would intuitively think higher number => more stable and that you would avoid major breaking changes on a minor release number, but they do exactly the opposite.

To put it a little more explicitly. Ubuntu names their releases for the YY.MM of release 16.04 was released in the year 2016 (16) in April (04). So those are date based releases rather than semantic versioning (semantic is x.y.z with x major, y minor, z patch).

They release a LTS version every two years in April: 12.04, 14.04, 16.04 and the next will be in 2018, 18.04. They do add a "patch" version after that, but the YY.MM are the major releases. 16.04 is an older version than 16.10, but it will be supported with patches for a longer period of time (major versions of individual software packages will stay the same).

LTS releases are in April where non-LTS come out in October. Doesn't explain your question exactly, but at least that's what the numbers mean.

LTS release comes every two years; but it is not the last release ever. See this:

https://www.ubuntu.com/info/release-end-of-life

No reinstalling needed, you can just do a dist-update to the next distro release whenever it's out. There are reasons to favor the LTS release, but I don't really see that as one of them.

Provided nothing breaks, then yes, do-release-upgrade can do the job. (dist-update does not upgrade to a new release in Ubuntu).

I have a bad experience with this, especially upgrading one LTS to another LTS. Clean install was much more reliable.

I have never had a problem on a release upgrade. It's one of the reasons to like Debian based distros IMHO. I suppose that may in part be because I typically waited for a while after a new major platform release to move the the next release.

The 10.04 to 12.04 upgrade has broken audio on my xbmc (now Kodi) box. Audio is pretty fundamental thing on a such box. I've spend a day trying to fix it, until I threw in a towel and reinstalled it from scratch.

The 12.04 o 14.04 upgrade was also broken. I don't remember details, it booted, but the dependencies went weird. I wasn't trying to fix it anymore, just straight reinstalled from scratch.

I haven't upgraded it to 16.04 yet. I will try, what will happen, once Kodi stops supporting 14.04.

You should use the upgrade system provided by Ubuntu ('update-manager'), it knows more about the changes than the standard 'dist-upgrade'. You can also run it to test what changes it will make.

Second, if you are using PPA's you are much more likely to have problems. There's no way to test all the inter-relations between packages that are outside the central archive. If you have packages that have upgraded fundamental packages in Ubuntu's Main archive then it's likely to break.

I mention this because you're talking about multi-media.

In general, it's best to remove PPA software before you launch the upgrade, in fact it's a good opportunity to remove anything from the system that you don't really need: for example for my 16.04 upgrade I removed the C++ environment as I'm not using it.

The only third-party ppas were team-xbmc and nvidia driver. I think that the more likely reason for breakage was, that it is not the desktop installation from live cd, it is minimal installation from the mini cd and then hand-picked packages. It has X11, but no desktop environment, for example.

I guess no-one (or fewer people) were testing that configuration. I wonder if you could use a VM or similar to at least test the upgrade before you do it. I do quite a bit of cleaning before an upgrade, but hitting the button to 'do it' is always a bit of a stressful moment!

Lots of third party code is tested only on the latest LTS version, so using LTS often makes everything easier.

Seconded. A few months ago I built my first desktop computer in ages. An Intel i7 6700K and AMD RX 480 run smoothly under Ubuntu 16.04 ever since.

At the very least AMD doesn't tend to selectively fuse off functions in their CPUs for marketing reasons.

AMD are in no position to fuse off functions in their CPUs - they're barely relevant even with all the functionality enabled.

If you look to the GPU market where AMD is in better shape, they do fuse off features like FP64 and ECC unless you pay for the heavily marked up FirePro versions.

I presume when they are fusing off these functions, they are also skipping QC on them, so they effectively have higher batch yields on that silicon.

I just upgraded to a RX480. From an R9 390. Not much gain, but wanted to support the company that is committed to being open.

Yeah. I'm definitely more loyal to AMD's GPU products than I am their CPU products. I am hoping to get a new zen cpu, but if it flops, I wont hesitate to go intel... I'll definitely avoid nvidia though.

The thing that stops me from getting AMD GPU for GPU programming is CUDA seems to be more widely used. OpenCL I really want to like it but hopefully the open standard AMD is pushing will gain more traction...

Not sure how much use it will be, but AMD's GPUOpen initiative recently released a tool[1] that translates native CUDA code to portable C++ that can be recompiled into either CUDA or OpenCL. I haven't played with it at all so I can't verify how well it works.

[1] https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

The difference between the kernel languages is minimal, many kernels can be translated with basic search & replace.

The difference is in the scaffolding (CUDA is easier but less flexible), and pre-existing libraries on offer.

If you're going to be writing the kernels yourself then it is easy to maintain both versions and it if it is for learning it doesn't matter at all (but I prefer the standard that works on all my machines).

OpenCL doesn't do Fortran, C++, Haskell or .NET.

Well, OpenCL 2.1 does do some C++ (not as much as CuDA with Pascal), but isn't widely available anyway.

There are plenty of zero-cost C++ wrappers available, including the official bindings. Most people who use OpenCL from C++ tend to accumulate their own convenience wrappers over time. The rest of those languages have fairly easy interoperability with C code and therefore access to the C api, though some may also have established convenience libraries. I wouldn't suggest .NET or Haskell for most serious GPGPU work, but Python, Julia, Fortran and others are frequently used. The PyOpenCL library is particularly excellent.

If you were referring to the kernel language (a restricted subset of C99), I don't find that to be a disadvantage in practice. While CUDA supports a fairly useful subset of C++ (most notably, templates), I still find host-side metaprogramming to generate kernel code to be a much more useful approach in most cases. Of course your preferences may vary, but I haven't seen many experienced GPGPU people express dissatisfaction with this point.

False. The official wrappers support C++ from OpenCL 1.0 on. Maybe this isn't obvious because the C++ bindings were introduced later, but they're backwards compatible and you can set the target API level. (And of course you use 1.2 if you need to support lagging vendors such as NVIDIA)

I have no idea about the other languages but surely other bindings must exist?

No one is speaking of wrappers here, rather C++ kernels, which is what matters, a full C++ experience.

> I have no idea about the other languages but surely other bindings must exist?

Yeah, the usual poor man's solution of generating C code, thus introducing two compilation steps, without any debugger support.

Anyone know whether GPU Ocelot actually works well? In theory that should allow you to run CUDA on your AMD hardware via OpenCL.

I always wanted to try it, but on the flip side the fact that AMD was starting their own project to do the same thing doesn't fill me with confidence that GPU Ocelot is worth my time.

I haven't used it myself, because I looked at it and saw that it's been unmaintained for over a year, has no adoption and requires ancient versions of CUDA and LLVM. The concept is interesting, but at this point the project seems dead to me.

I have the same GPU card in a new desktop, waiting for OpenBSD to pick it up. Since they don't support Nvidia on principle, AMD cards are all I ever look at.

Reply on news.ycombinator.com