AMD hUMA to make significant improvement in parallel processing

[AMDforME]

The Register has a nice article on AMD's new heterogeneous unified memory access, (hUMA), and how it will significantly improve PC performance. Interestingly it will arrive soon where you least expect to find it. Kaveri will be the first APU offering this technology and it's slated to be released by the end of '13.

"AMD has released details on its implementation of The Next Big Thing in processor evolution, and in the process has unleashed the TNBT of acronyms: the AMD APU (CPU+GPU) HSA hUMA.

Before your eyes glaze over and you click away from this page, know that if this scheme is widely adopted, it could be of great benefit to both processor performance and developer convenience ? and to you.

Simply put, what AMD's heterogeneous Uniform Memory Access (hUMA) does is allow central processing units (CPUs) and graphics processing units (GPUs) ? which AMD places on a single die in their accelerated processing units (APUs) ? to seamlessly share the same memory in a heterogeneous system architecture (HSA). And that's a very big deal, indeed.

Why? Simple. CPUs are quite clever, speedy, and versatile when performing complex tasks with myriad branches, but are less well-suited for the massively parallel tasks at which GPUs excel. Unfortunately, they can't currently share the same data in memory..."

http://www.theregister.co.uk/2013/05/01/amd_huma/

[CrazyNutz]

Looks like a logical next step in tighter CPU/GPU integration. This will definitely speed things up and save on memory allocation.

[Tao~]

AMD always makes great plans, however the devil lies in the details (or the implementation)
This is a great news for GPGPU because the bulk of time is spent copying data between memories - however I think this will lead to more complicated memory accesses for the CPU with possibly increased latencies ( someone with more info please enlighten me :P: )

AMD are probably thinking about integrating a GPU ( which is like a MIMD (or multiple SIMD) I suppose ?) while their performance on scalar instructions is the real cause of concern for most people. They seem to be banking on something that has not yet been adopted and will require extensive programming paradigm rethinking for the required gains. I am not sure but can their logic actually find so many parallel instructions to feed a GPU in everyday code ?

[AMDforME]

Actually programming will become easier, which is why this new tech has already achieved considerable industry support. This isn't something AMD just dreamed up. They have been working on this technology since before 2006 when they bought ATI. They've already proven the worth and new products will be released with this tech in '13. Programs don't need to be rewritten to take advantage of the tech.

[phantomferrari]

do you think in the future HUMA will use the memory cube technology that micron and others are working on?

[lutjens]

I hope AMD has ensured adequate rights protection for this technology, so that it would be far less easy for Intel to simply do likewise. I remember when Intel decided to copy AMD's Hypertransport and call it QPI...and the resulting surge in the performance of Intel's processors that has played a significant role in making Intel the incredibly arrogant, progress-destroying pig that has become today.

I hope this technology gives AMD a real boost in terms of actual performance value of their hardware and encourages software development that takes advantage of it. The apparent ease in which this technology can be utilized by programmers is encouraging and will likely draw significant industry support. If they can pull this off, there may be a drastic turnaround in AMD's fortunes and may just kick Intel off its high horse and force them to actually put out a product that is actually fully enabled, for once in a long time.

[Lanek]

I hope AMD has ensured adequate rights protection for this technology, so that it would be far less easy for Intel to simply do likewise. I remember when Intel decided to copy AMD's Hypertransport and call it QPI...and the resulting surge in the performance of Intel's processors that has played a significant role in making Intel the incredibly arrogant, progress-destroying pig that has become today.

I hope this technology gives AMD a real boost in terms of actual performance value of their hardware and encourages software development that takes advantage of it. The apparent ease in which this technology can be utilized by programmers is encouraging and will likely draw significant industry support. If they can pull this off, there may be a drastic turnaround in AMD's fortunes and may just kick Intel off its high horse and force them to actually put out a product that is actually fully enabled, for once in a long time.

Well, this techno is part of HSA ..

Also, it's important to note that although AMD was the company to make the hUMA announcement and will be the first to release a hUMA-compatible chip with Kaveri, the specification will be published by the HSA Foundation, of which AMD is merely one of many members along with fellow cofounders ARM, Imagination Technologies, Samsung, Texas Instruments, Qualcomm, and MediaTek. Should some – all? – of these HSA Foundation members adopt the shared-memory architecture, hUMA goodness could spread far and wide..

[zir_blazer]

Actually programming will become easier, which is why this new tech has already achieved considerable industry support.

I don't think so. This looks like a low level feature that is totally invisible to the developer.



On x86 Assembler, you can't directly copy from one memory location to another. Say, if you want to move the value of mem_address1 to mem_address2, this will not work:

mov [mem_address2],[mem_address1]

You have to copy it first to a CPU Register, THEN copy from that Register to memory. This should work:

mov eax,[mem_address1]
mov [mem_address2],eax

I don't really know how the CPU and GPU interacts between them, but I can theoryze about it, as some of the memory from devices like the Video Cards seems to be directly mapped on the CPU memory addressing space. This was the reason why in 32 Bits, the more devices you had, the less RAM you were able to see. For example, with the integrated Radeon 4200 from the AMD 785G Chipset set to only use the Motherboard Sideport, I saw 3.5 GB RAM of my 4 GB, with that 4200 and a Radeon 5770 with 1 GB VRAM, 3.25 GB (It takes 256 MB), and with the 4200 and two 5770s, 2.87 GB (The second 5770 takes 384 MB, don't know exactly why it takes more).
I suppose that the CPU should be able to directly write data into the memory of a device like the Video Card's RAM by simply doing a mov in the memory address where a device got mapped, however, in the case of the Video Cards, the CPU just see a mere part of the that RAM, as I lose 256 and 384 MB respectively versus the full 2 GBs that the Video Cards have. The GPU should be aware than some of its RAM is visible to the CPU but the rest is not, so its VRAM should possibily be partitioned into a sort of receiving buffer that the CPU can write to, and one for GPU exclusive internal usage.

For an APU, as the physical RAM of the GPU side is exactly in the same RAM pool than the CPU side could potentially see and use, you can forget what I said in the last paragraph, as on a discrete Video Card, the CPU should be forced anyways to move/copy data to the Video Card RAM as you want that data in another physical RAM space, but on an APU is not the case. But it should still be partitioned into two spaces, for the CPU and the GPU. So basically, on a current APU, when it wants to send data to the GPU, it STILL needs to make that mov from memory to a register then back to memory.
What AMD seems to have achieved, is that there will be effectively just one partitioned space of the system RAM for both the CPU and GPU instead of two, as now the GPU will be able to read and write to it without needing the CPU to do the two-step mem-to-mem operation.

[Sparky]

I hope AMD has ensured adequate rights protection for this technology, so that it would be far less easy for Intel to simply do likewise. I remember when Intel decided to copy AMD's Hypertransport and call it QPI...and the resulting surge in the performance of Intel's processors that has played a significant role in making Intel the incredibly arrogant, progress-destroying pig that has become today.

I hope this technology gives AMD a real boost in terms of actual performance value of their hardware and encourages software development that takes advantage of it. The apparent ease in which this technology can be utilized by programmers is encouraging and will likely draw significant industry support. If they can pull this off, there may be a drastic turnaround in AMD's fortunes and may just kick Intel off its high horse and force them to actually put out a product that is actually fully enabled, for once in a long time.

To be fair, Intel has squat when it comes to GPU power. They've managed to totally fail at GPU anything up to this point, and I really don't see that changing too soon.

x86 they can do, but that's about it!

[Evantaur]

this will be aweosme

[VulgarHandle]

It will be awesome.

If it hasn't sunk in that it will be awesome, think about this. AMD has done wonders with the combination of CPU, from AMD, and GPU from what was ATI. Now add hUMA, work no doubt aided by Samsung.

Still not some awesome sauce? Ok, think about adding in specialized ARM processor.

Now think about why the console kings went with AMD. Reason? Programing, pure and simple. And we're not talking just gaming here, we're talking server farms and mobile handheld devices, too.

It will be awesome. In the meantime, all I'd like to know is, if Kaveri will be compatible with current A85X based socket FM2 motherboards.
This is the only thing I haven't received a solid answer on.

[LordEC911]

do you think in the future HUMA will use the memory cube technology that micron and others are working on?

Sooner than one might think...

[Piledriver]

There is a clue about performance in the article.

PS4 chief architect Mark Cerny said that the console would have a "supercharged PC achitecture," and that "a lot of that comes from the use of the single unified pool of high-speed memory" available to both the CPU and GPU.

[LordEC911]

It will be awesome. In the meantime, all I'd like to know is, if Kaveri will be compatible with current A85X based socket FM2 motherboards.
This is the only thing I haven't received a solid answer on.

Won't be confirmed until a wild sample wanders into some friendly hands.
It sounds like it will be backwards compatible with FM2 but is designed around FM3 for the new features/performance.

[Final8ty]

youtube-amd-intro-to-bolt-bolt-hello-world-simplified-programming-for-hsa

http://www.youtube.com/watch?v=Pz6YwH8m8Hc
http://www.youtube.com/watch?v=p1eWgRa-JQE

"Bolt" is created for simplifying parallel and programming for HSA, is this the realization of programmers dream involving HSA and will "Bolt" ease the painfulness of parallel programming?

[Lanek]

As Bolt have been released some times ago allready, i just push the link for it, for access the dedicated forum you need to apply on Bolt group. http://developer.amd.com/tools-and-s...plate-library/

[VulgarHandle]

Won't be confirmed until a wild sample wanders into some friendly hands.
It sounds like it will be backwards compatible with FM2 but is designed around FM3 for the new features/performance.

I got my confirmation, it will be backwards compatible with FM2. Confirmation came with an asterisk, that being whether or not the motherboard manufacturer provides a BIOS update. When I followed up on that I was told it's no different than any updates done in the past, like AM2+ motherboards getting an update when AM3 CPUs came out, or the current update manufacturers are providing for FM2 ahead of Richland's release.

So, YAY!

[LordEC911]

So, YAY!

Nice thanks for the confirmation.

[The Stilt]

I got my confirmation, it will be backwards compatible with FM2. Confirmation came with an asterisk, that being whether or not the motherboard manufacturer provides a BIOS update. When I followed up on that I was told it's no different than any updates done in the past, like AM2+ motherboards getting an update when AM3 CPUs came out, or the current update manufacturers are providing for FM2 ahead of Richland's release.

So, YAY!

Confirmation?
From where and from who?

Currently Kaveri desktop parts (KV-A0 & KV-B0) only exist for FM3 socket.
I find it odd if they would actually be backwards compatible after such major changes.

[Mechanical Man]

Confirmation?
From where and from who?

Currently Kaveri desktop parts (KV-A0 & KV-B0) only exist for FM3 socket.
I find it odd if they would actually be backwards compatible after such major changes.

I would not be suprised for limited bwc. Like not all mem controllers awailable etc... ?

[VulgarHandle]

Confirmation?
From where and from who?

Currently Kaveri desktop parts (KV-A0 & KV-B0) only exist for FM3 socket.
I find it odd if they would actually be backwards compatible after such major changes.

Umm, a birdy? Sorry, hope you weren't expecting a serious answer. I will say they're not in the marketing division, lol.

I was given no reason for the compatibility, only that it will of course be optimized for the next socket.

[SEA]

Yes, there was news about FM2 and kavery awhile ago:
AMD Kaveri APU will use FM3 Socket but supports FM2

[VulgarHandle]

Yes, there was news about FM2 and kavery awhile ago:
AMD Kaveri APU will use FM3 Socket but supports FM2

That article references a claim, and a rumor. I'm just saying, I was given a firm answer, and I'm sharing that with you all.

[The Stilt]

It would be great news to the customers if Kaveri would be FM2 compatible.
However that is unlikely to be the case, atleast with the higher end models.
The features would have to be heavily neuterized.

This is just pure speculation, naturally

The GNB (GPU) on Kaveri is physically larger (albeit the 28nm process) than on any of it's predecessors and MUCH more complex.
And so are the UNB(s) and the memory controller(s). The link between the APU and the FCH might have some differences
too when moving from Hudson to Bolton FCH. The memory controller(s) will naturally be intra-die, however I am not certain if the "re-arrangements" can be done without changes to the socket / motherboard signaling. DDR4 is not pin compatible with DDR3 however that is not what I am talking about, ahem...

Even if AMD could make atleast some of the Kaveri variants compatible with FM2 socket, still one BIG issue remains:

When a new socket is introduced the motherboard vendors will release their new lineups based on the new socket.
At this point (at latest) supporting the 'old' models becomes a burden and nothing but a big expense, from their point of view.
It may sound harsh but that is exactly what it is. After all they are no salvation army, they are in the business to make money.
If for any reason, they do it for PR not for profits.

APUs are so much more complex than any of the CPUs currently available.
They do require atleast twice the support from the bios to make everything work correctly.
For example, the AGESA code alone for 15h APUs is over 33% larger than the code for 15h CPUs.
A top of that, the APUs require a vast amount of "vendor" specific configuration.

If you do remember how "well" the 15h CPUs were supported on AM3 motherboards you can imagine how well would a Kaveri APU be supported on a EOL FM2 platform, which requires much more work than the 15h CPU support for AM3 socket ever did.

As far as I know, the newest thing that ever existed for FM2 or FM2r2 was "something" Komodo based.
And Komodo is six feet under, unless those samples which once dwelled in the dark corners of the labs are counted in
After that, anything I do ... speculate of is for FM3 socket. Atleast for desktop.

[VulgarHandle]

The Stilt:

You assume socket "FM3" will be out by Kaveri's release. If it's not, the motherboard manufacturers will have to support Kaveri on FM2.

FM3-based boards are rumored to support PCIe 3.0, which is of course available, but also DDR4, which isn't.