AMD's Hidden Strategy
seekingalpha.com
seekingalpha.com
> Welcome to Seeking Alpha, please complete your setup with our FREE app
Do the metrics really say that these approaches gain more users than they lose?
On the server, AMD is making a security play w/ EPYC arch.
- AMD not vulnerable to Meltdown
- SEV allows encryption of a VM’s memory, further mitigating read attacks
On the consumer side, AMD is selling on-package Vega to Intel. This should increase market penetration, and thus get more games optimized for the AMD arch.
Let say AMD makes a profit on their Vega Chip sold to Intel.
Intel will now have to sell this CPU+Vega chip ( Raw Cost ) @ Intel Margin.
So Intel either sell a very expensive package, or sell it at the same cost ( or slightly higher ) to customer as if they were to buy them separately, which hurts Intel margin. ( Because Intel earn less on Vega )
And it has been a long time Intel dont care about margin at all.
But yes, even still, Kaby-G is a very expensive part. I've heard ballpark like $500-600 for just the package. You can pretty much buy a whole Ryzen 2500U laptop for just that one item on the BOM. But it's also much faster - roughly 4x as fast as a 2500U.
Intel has already made a move to rework their GPU development by effectively starting over(see: recruiting Raja Koduri to work in the same kind of leadership position he had at AMD previously while developing Vega). But they need a stopgap for the coming years, and this is one way to attack.
The Vega M package is a technically interesting product(size, integration, possible economies of scale), but it's primarily a win for market share because Intel can cram it down the throat of OEMs to stop them from using Nvidia. They would happily cut their margins to do so.
Let hope they do.
SeV will not help in this regard.
Games are already optimized for AMD GPUs and pretty darn well due to consoles I’m not entirely sure how much difference would the KBL-G provide considering that at least in the mobile space it’s going after the MX150 it needs 100W to compete with the 1050 so that would be on desktop only.
Spectre is also much much harder to mitigate against Meltdown sucked but it was easily fixed and it will also be easily fixed in silicon Spectre especially variant 1 will be with us for a long time and no one knows what still is lying hidden.
AMDs main advantage is that none of the researchers really bothered reversing their branch predictor so none of the BP training reliant PoCs work on their hardware but there is nothing in their design that mitigates against Spectre specifically.
And judging by the guide they’ve released for how to manage branch prediction post Spectre at least the technical team is worried about what would happen when someone starts paying attention to them.
This would also be a pretty straightforward mitigation for Intel, so the whole "they need to redesign the whole core from the ground up!" thing may be a bit overblown. Cache behavior will need to change a bit, for sure, but we probably don't need to smash the looms and go back to using non-speculative ARM cores.
I tend to think AMD probably has some vulns lurking in their uarch as well, the difference is that Intel has a massive amount of marketshare in the server world and their hardware gets shaken down first as a result. I'm just a random internet nobody but Anders Fogh said the same thing in an interview with Gamers Nexus: Spectre is not much less severe for AMD than Intel, these are the opening shots of a whole new class of attacks and there are more to come now that we are looking for them.
This is incorrect. Spectre works at a cache level, memory is decrypted by that point - if it were encrypted you couldn't use it for the good kind of speculation either. This means SEV doesn't do anything in particular here, effectively the victim is decrypting its RAM for you.
The point of SEV is to make memory inaccessible after shutdown, whether that's physical (cold boot attacks) or virtual (VM instances reusing host memory). Not for Spectre.
Even the print trick doesn't work, it just prints the current page, so for a 6-page article you'd have to print 6 times (and each virtual page probably takes up 1 full paper page + 1 line of a 2nd paper page...). Although, who still prints articles anyway?
Guess whose article won't be read past page 1...
Here's Tensorflow for it: https://github.com/ROCmSoftwarePlatform/hiptensorflow
I have no experience so can't comment on how production-ready it is.
The bigger problem has always been middleware. Effectively, HIP needs to duplicate everything that NVIDIA provides, 1:1, and it doesn't. More complex libraries (particularly ones that touch hardware features like texture units/etc) cannot be insta-converted with HIP either.
It's impractical, for the most part. I've always been of the opinion that what AMD needs is something like GPU Ocelot that can transpile PTX rather than working at a source level. Unfortunately I'm sure that would be legally frought for AMD.
The problem is the middleware - i.e. when you go to write a program, you want to write your financial simulation or whatever, not a RNG library. Once that stuff gets written, OpenCL will be perfectly viable. It's just sort of a slog now, vs a huge amount of stuff available for CUDA, both from NVIDIA and from others.
Another, more general problem is that OpenCL is not really a GPGPU language, it's a general framework for dispatching tasks to heterogeneous processors. You can hypothetically use OpenCL to dispatch tasks to a FPGA or a DSP or anything else. This means there's a relatively silly amount of boilerplate compared to CUDA, which is stylistically annoying but not really complex. But in general it's also up to the vendor to implement their own SDK, compiler, etc, and there's no guarantee that what runs on one OpenCL platform will run on another. What is commonly referred to as "OpenCL" is actually the AMD APP SDK and the NVIDIA OpenCL SDK, which both implement their own version of parallel C++ dispatched according to the OpenCL function interface/semantics.
So in other words, OpenCL suffers from a bit of Architecture Astronaut syndrome. AMD solved the problem of making a framework that can dispatch tasks to any coprocessor that implements their interface, NVIDIA solved the problem of making a GPGPU language. As such, AMD sometimes struggles to fulfill the cross-platform promise of their language and suffers in conciseness.
For learning CUDA, I really like the Thrust language. You can write GPGPU programs that are literally 10 lines or less. It looks like regular C++ STL but you can execute it on the GPU. You can easily call __device__ functions using functors iterating across your dataset, or get raw_pointers into a device_vector and then pass them into a normal kernel launch, so there's a lot of flexibility there to tune stuff as you want to make it more complex.
http://docs.nvidia.com/cuda/thrust/index.html
For a non-trivial program, here's my master's thesis, which I did in Thrust. Not really machine learning but at least you can see what you're getting into.
https://github.com/pholvs/PandemicThrust
For AMD, there is supposedly an equivalent called "Bolt Framework" but I have not used it personally. As is customary for AMD's libraries, after release it was abandoned and it has not been updated in several years, best of luck.
I agree AMD needs to do this badly, but don't think it will take much convincing as long as it works. You can read reddit/etc ml forums and see people are desperate for some alternative (AMD or otherwise) due to Nvidia's abuses of its monopoly.
(I'm thinking of years past when Broadcom wifi etc were a problem under Linux.)