juanrga :
Thanks by the answer to my question.
If HT/HTX breaks hUMA then I don't think this has future at AMD. In my opinion, hUMA is part of the HSA specification, because all the properties of hUMA (cache coherency is only one of them) coincide with the properties of the memory model of the copy of the HSA specification that I have. AMD presents hUMA
in the following terms:
Hypertransport (HTX) doesn't break hUMA. Besides hUMA is not yet part of HSA standards, just there is nothing to specify really beyond IOMMU and cache coherency, just read
http://hsafoundation.com/standards/
OTOH IOMMU v2 (2.5) is an "official HSA standard". That is the part, based on what is specified
"same *virtual memory*", is what it does. And since
this IOMMU specification is based on some Hypertransport internals (JUST READ THE PDF), i think
cache coherency is facilitated, and that was always intention of AMD to "push" for cache coherency.
So any cache coherency reference implementation only have to follow what is already in IOMMU, even if no other HSA member adopts the Hypertransport protocol, its facilitated. Neither there will be any *hardware* "cache coherency" standard or coherency protocol standard( i think), and there is no need to,
others only have to adapt their *CC hardware implementations* to work with IOMMU (minor tweak), and even if they don't have CC, they only need IOMMU that the rest can be implemented in software
So for now hUMA is an AMD thing, which doesn't prevent others HSA followers to have identical, even having different hardware CC implementations.
In AMD case all is more facilitated, since *EVERY* CPU and APU of AMD, have for the Xbar/Northbridge inside those chips, an *Hypertransport switch*... yes since the Athlon64, every CPU and now APU is the same for that internal (system request interface/Xbar/Northbridge/possible several I/O HT links)... its a master work of Jim Keller among others... even if there is additional PCIe onboard controller for PCIe links, one doesn't invalidate the other, APU inside *core to core* communication including the GPU, is not PCIe, but HT protocol based ( the why the IOMMU). Besides everything is tremendously facilitated for integrating PCIe, since HT data transmission mapping is the same of PCIe but in reverse, that is, one is from pin 1 to 20 (example), the other the pin 20 is the 1 to 20 (which is 1 on the other)... understand ?... a packet only have to have the order reversed and that is it(which is fast and furious).. lol
That is what makes possible for a same slot to have PCIe and HTX, the link PHY only has to detect what type and reverse the order. The catch HTX needs an additional sideband interface for control and with that : PCIe/HTX ____________ + sideband_____ (same row) you have a "combo HTX +PCIe" slot, that could function with boards of both kinds(one at a time of course)... understand ?
So HTX comes very natural, even for hUMA, better is needed for hUMA for discrete adapters, PCIe doesn't do, doesn't have cache coherency. *IF* AMD will ever implement this is another story.
juanrga :
The HSA Foundation has released a new multicore architecture specification called hUMA or heterogeneous uniform memory access. hUMA allows CPUs and GPUs to share the same memory in a heterogeneous system architecture (HSA). hUMA makes it easier for developers to create apps that use the individual powers of CPUs and GPUS and is compatible with mainstream programming languages like Python, C++ & Java. You'll soon be able to see hUMA in action in AMD’s Kaveri processors.
I don't know the rumour about Kaveri that you mention. I only know an old rumour (latter discredited) that said that Kaveri was coming with a
dual memory controller with support for DDR3 and GDDR5. However, the controller only could run one type of memory or the other but not both at the same time. Either all the main memory was DDR3 (like in a Trinity APU) or all the memory was GDDR5 (as in PS4 APU). This restriction makes sense, because an arbitrary mixture of DD3+GDDR5 breaks hUMA (in the above sense).
I think that is a misunderstanding. PS4 is different, and in terms of cost never did any sense to have only GDDR5 for a mainstream APU, a DIMM format for this, would drive price of memory trough the roof, very different of having GDDR5 devices soldered to a PCB... and the added latency of a DIMM approach would hurt the CPU part notoriously. (Tough it can have it, GDDR5 simple was not designed with DIMMs in mind...).
So to be, to me was always identical to intel, a pool for CPU and a GDDR5 pool for the GPU, but "interposed in the socket subtract", like some mobile GPU parts of AMD have
http://www.techpowerup.com/img/11-05-03/17a.jpg
Replace that GPU with an APU, and put there connections for DDR3 channels.
It still can have GDDR5 in a Kaveri revision... but since is only 512sp, i think ESRAM is a better bet, even Wuii has it, and it surely will be cheaper, and provides the GPU with a whole lot of more bandwidth than that provided by the DDR3 channels. In XBone supports 768 sp, for 512sp it would be greater the effect... yet the DDR3 channels could still be hUMA( which in XBone isn't).