So AMD's going full steam ahead with their rebel branding. Not sure how would that appeal to HPC types. dose quotes on "Open Source" and "Deep Learning" though...
Anyway I'm sure many will be glad to see someone jumping in on better and more open tooling. There's also potential for other vendors and tinkerers to generate code for their ISA, even for games if that's the same one they use for their consumer cards.
So why is "open source" in quotation marks? Looks like "not really open source"?
And on a side note, it is a good thing that AMD is making a lot of SOFTWARE improvements lately, however I kinda wish it was more than damage control due to the lack on the HARDWARE side.
Going by their usage in the rest of the text, the quotes seem to emphasize the fact that the words refer to a proper noun. Their lawyers probably made them do it to stop some suit happy class action lawyer inferring all sorts of things from the words. The hazards of being a public company.
they are preparing their software stacks for the arrival of the new hardware (Vega en Zen) to make sure the new hardware comes out swinging when it's released.
"Support only non-packed float16"? All my understanding of OpenCL (mostly read with an eye on Nvidia capability, since that's what I currently have) implies that OpenCL tends to be highly biased toward aligned reads (meaning that non-packed shorts are weird, special cased oddities). Granted this is more a nvidia thing (nvidia can do reads to arbitrary registers of 32 aligned values, AMD reads 256 bytes and can assign them to arbitrary ports (although I'm sure they need to be aligned, but smaller values allow more choices)).
It sounds harder to *not* support packed16 than to support it. This is certainly an exaggeration, but I doubt that fixing this is all that hard. I still have to wonder where all the money for this is coming from, AMD hasn't even been selling video cards lately.
Here "packed" means something different from C packed structs (structs without any padding). It is more akin SSE when you execute things on vectors of two 16-bit FPs instead of scalars (which are then executed natively as 64-vectors of 2-vectors, but that's beyond the point).
It is most apparent from FP16 throughput, which is most often 2x FP32 throughput for packed FP16 and 1x FP32 throughput for unpacked.
however, "FP16 throughput, which is most often 2x FP32" - that's not really true, in many instances FP16 is actually slower than FP32, believe it or not, which begs the question, why even bother, when you can do as much and even more in higher precision. And several uarchs don't, they promote it to FP32 implicitly.
On a gtx 1080 FP16 is actually twice as slow as the already severely crippled FP64. "Stupid" would be a compliment to anyone running FP16 number crunching on that hardware.
There is nothing particularly surprising with the ARM support. ARM architecture with the coming new vector extensions will become a part of the European and Japanese exascale efforts.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
11 Comments
Back to Article
OEMG - Monday, November 14, 2016 - link
So AMD's going full steam ahead with their rebel branding. Not sure how would that appeal to HPC types. dose quotes on "Open Source" and "Deep Learning" though...Anyway I'm sure many will be glad to see someone jumping in on better and more open tooling. There's also potential for other vendors and tinkerers to generate code for their ISA, even for games if that's the same one they use for their consumer cards.
nathanddrews - Monday, November 14, 2016 - link
Given the number of Che Guevara T-shirts I saw last time I was in the bay area, I think AMD's marketing team did their research quite well.ddriver - Monday, November 14, 2016 - link
So why is "open source" in quotation marks? Looks like "not really open source"?And on a side note, it is a good thing that AMD is making a lot of SOFTWARE improvements lately, however I kinda wish it was more than damage control due to the lack on the HARDWARE side.
prisonerX - Monday, November 14, 2016 - link
Going by their usage in the rest of the text, the quotes seem to emphasize the fact that the words refer to a proper noun. Their lawyers probably made them do it to stop some suit happy class action lawyer inferring all sorts of things from the words. The hazards of being a public company.The_Countess - Monday, November 14, 2016 - link
they are preparing their software stacks for the arrival of the new hardware (Vega en Zen) to make sure the new hardware comes out swinging when it's released.at least that's my optimistic reasoning.
wumpus - Monday, November 14, 2016 - link
"Support only non-packed float16"? All my understanding of OpenCL (mostly read with an eye on Nvidia capability, since that's what I currently have) implies that OpenCL tends to be highly biased toward aligned reads (meaning that non-packed shorts are weird, special cased oddities). Granted this is more a nvidia thing (nvidia can do reads to arbitrary registers of 32 aligned values, AMD reads 256 bytes and can assign them to arbitrary ports (although I'm sure they need to be aligned, but smaller values allow more choices)).It sounds harder to *not* support packed16 than to support it. This is certainly an exaggeration, but I doubt that fixing this is all that hard. I still have to wonder where all the money for this is coming from, AMD hasn't even been selling video cards lately.
Bigos - Monday, November 14, 2016 - link
Here "packed" means something different from C packed structs (structs without any padding). It is more akin SSE when you execute things on vectors of two 16-bit FPs instead of scalars (which are then executed natively as 64-vectors of 2-vectors, but that's beyond the point).It is most apparent from FP16 throughput, which is most often 2x FP32 throughput for packed FP16 and 1x FP32 throughput for unpacked.
ddriver - Monday, November 14, 2016 - link
aka scalar vs vectorhowever, "FP16 throughput, which is most often 2x FP32" - that's not really true, in many instances FP16 is actually slower than FP32, believe it or not, which begs the question, why even bother, when you can do as much and even more in higher precision. And several uarchs don't, they promote it to FP32 implicitly.
ddriver - Monday, November 14, 2016 - link
On a gtx 1080 FP16 is actually twice as slow as the already severely crippled FP64. "Stupid" would be a compliment to anyone running FP16 number crunching on that hardware.TeXWiller - Monday, November 14, 2016 - link
There is nothing particularly surprising with the ARM support. ARM architecture with the coming new vector extensions will become a part of the European and Japanese exascale efforts.Threska - Wednesday, November 16, 2016 - link
Promising, although one wonders just how much will trickle-down into the consumer space, and what difference would it make?