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.
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.
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?
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.
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.
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.
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.
With the push to the linux kernel AMD GPU's would be better than Nvidia... that being said, I wouldn't hold my breath.
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.
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.
It only interacts with performance in that driving displays requires memory bandwidth and consumes power.
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)
You can only believe the same promises up to a point.
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.
If you like reinstalling every few months, the non-LTS release is fine. Most people don't, so they prefer the LTS release.
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).
I have a bad experience with this, especially upgrading one LTS to another LTS. Clean install was much more reliable.
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.
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.
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.
[1] https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP
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).
Well, OpenCL 2.1 does do some C++ (not as much as CuDA with Pascal), but isn't widely available anyway.
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.
I have no idea about the other languages but surely other bindings must exist?
> 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.
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.
Here's to hoping the new AMD CPU does well too, it's good for the market that Intel has competition.