7 ms·
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
by digikata 10y ago
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.
- boxerbk 10y agoAMD 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.
- philippnagel 10y agoSeconded. 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.
- maksimum 10y agoI'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.
- aidenn0 10y agoI 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?
- wjnc 10y ago16.04 is a LTS-version (long term support) while .10 is not - https://wiki.ubuntu.com/LTS https://wiki.ubuntu.com/LTS
- vetinari 10y ago16.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.
- paulmd 10y agoSlightly 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.
- toss1941 10y agoLTS 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.
- vetinari 10y agoLTS release comes every two years; but it is not the last release ever. See this: https://www.ubuntu.com/info/release-end-of-life https://www.ubuntu.com/info/release-end-of-life
- daveguy 10y agoTo 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).
- digikata 10y agoI 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.
- Symmetry 10y agoAt the very least AMD doesn't tend to selectively fuse off functions in their CPUs for marketing reasons.
- jsheard 10y agoAMD 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.
- dnautics 10y agoI 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.
- ensignavenger 10y agoI'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.
- lettergram 10y agoAMD 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.
- snuxoll 10y agoAMD 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.
- digikata 10y agoI think that was infrastructure to support the closed driver, not the open driver.
- nhaehnle 10y agoYou'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.
- yeukhon 10y agoThe 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...
- paulmd 10y agoAnyone 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.
- keldaris 10y agoI 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.
- rockdoe 10y agoThe 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).
- pjmlp 10y agoOpenCL 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.
- keldaris 10y agoThere 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.
- Twirrim 10y agoThese 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)
- appleflaxen 10y agoExactly! 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.
- Declanomous 10y agoAMD 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.
- mattst88 10y ago> 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 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.
- itodd 10y agoI just upgraded to a RX480. From an R9 390. Not much gain, but wanted to support the company that is committed to being open.
- bisby 10y agoYeah. 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.
- ams6110 10y agoI 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.