News Erscheint AMDs „Kaveri“ im ersten Halbjahr 2014?

[Daedal]

nebulein
Mit was man rechnen darf ist ein l3 cache beim Kaveri

Wie kommst du drauf? Hast du eine Quelle dafür, dass ein solcher geplant ist?
IMHO steht das in völligem Widerspruch zum HSA Konzept und gemeinsame Speicherbereiche für GPU und CPU. Ein weiterer Cache Level würde nur die Latenzen erhöhen und den Vorteil zunichte machen den man dadurch erhält, dass man sich das kopieren zwischen CPU und GPU Speicherbereichen spart.

Kabini (APU mit Jaguar Kernen) kommt mit einem gemeinsamen L2 Cache für alle Cores. Ich denke es geht viel eher in diese Richtung mit Kaveri und stellt somit deutlich mehr schnellen Cache für Singlethreaded Szenarien zur Verfügung, wo der L3 eben auch die grössten Vorteile bringt. Integration und gemeinsam genutzte ressourcen sind der Weg den AMD geht. Hier passt weder zusätzlicher L3 Cache rein noch stacked Memory für APUs.

 

[y33H@]

Kaveri wird vermutlich erneut einen großen L2 pro Modul bieten, aber keinen Cache für alle Module gemeinsam.

 

[pipip]

Die Wahrscheinlichkeit ist nicht gering. Wenn wird es Kaveri oder Excavator sein, einer von beiden wird aber wieder einen L3 Cache bekommen.
Eine allg Grund ist der hier :
http://news.ncsu.edu/releases/wmszhougpucpu/

In our model of fused architectures, the GPU and the CPU are integrated on the same die and share the on-chip L3 cache and off-chip memory, similar to the latest Intel Sandy Bridge and AMD accelerated processing unit (APU) platforms. In our proposed CPU-assisted GPGPU, after the CPU launches a GPU program, it executes a pre-execution program, which is generated automatically from the GPU kernel using our proposed compiler algorithms and contains memory access instructions of the GPU kernel for multiple threadblocks. The CPU pre-execution program runs ahead of GPU threads because (1) the CPU pre-execution thread only contains memory fetch instructions from GPU kernels and not floating-point computations, and (2) the CPU runs at higher frequencies and exploits higher degrees of instruction-level parallelism than GPU scalar cores. We also leverage the prefetcher at the L2-cache on the CPU side to increase the memory traffic from CPU. As a result, the memory accesses of GPU threads hit in the L3 cache and their latency can be drastically reduced. Since our pre-execution is directly controlled by user-level applications, it enjoys both high accuracy and flexibility. Our experiments on a set of benchmarks show that our proposed preexecution improves the performance by up to 113% and 21.4% on average.

Weiteres macht es auch Sinn einen L3cache anzubinden. Den selben Sinn wieso Intel einen l4 Cache integriert, nur dass vom L3 cache nicht nur die igp sondern auch die CPU-Part profitieren kann.

http://wccftech.com/amds-kaveri-bas...s-steamroller-cores-compatibility-fm2-socket/

AMD also seems to future proof its FM2 socket by allowing compatibility of the Richland APUs with the same socket motherboards with support for DDR3-2133MHz memory and a 4MB L3 Cache.

Read more: http://wccftech.com/amds-kaveri-bas...cores-compatibility-fm2-socket/#ixzz2H2dhM8f6

Wobei mit Richland hier eher von Kaveri die Rede ist (ähnlich wie bei Fudzilla). Ich schätze einmal dass llano und Trinity deshalb keinen l3 cache hatten, weil 1) noch kein wirklicher Nutzen davon da war und 2) die Die-Size wesentlich gestiegen wäre.
Wenn die CPU und GPU fähig ist, auf die selben Register und auf den selben L3 Cache zu zugreifen, wäre das schon sehr sinnvoll, oder täusche ich mich ?

 

[y33H@]

WCCF irrt, die 4M sind der L2 (zwei Module mit je 2M).

Excavator ist übrigens der Codename einer Architektur und nicht einer APU.

 

[pipip]

y33H@
Nein, das macht keinen Sinn, weil die l2 cache ja pro Modul sind, überlege doch mal, wieso ist bei Kabini ein shared l2 cache auf alle cores ? und nicht mehr pro core ein l2 cache wie es bei Bobcat war. Kabini soll ja schon sehr mit der igp verschmolzen sein.

Ein shared l2 cache würde ja bei dem Module Design doch keinen Sinn machen oder ?
Weiteres 4mb l3 cache klingt sehr nach den FX. Hier sind ja auch 2 Module und ein l3 cache. 4 Module mit 4 x 2mb l2 cache und 4 x 2 mb l3cache (wobei der als 8mb l3 cache shared verwendet werden kann).

 

[Daedal]

Die Wahrscheinlichkeit ist nicht gering. Wenn wird es Kaveri oder Excavator sein, einer von beiden wird aber wieder einen L3 Cache bekommen.
Eine allg Grund ist der hier :
http://news.ncsu.edu/releases/wmszhougpucpu/

[...]

http://wccftech.com/amds-kaveri-bas...s-steamroller-cores-compatibility-fm2-socket/

WCCF irrt, die 4M sind der L2 (zwei Module mit je 2M).

Excavator ist übrigens der Codename einer Architektur und nicht einer APU.

Excavator ist der Codename einer CPU-Architektur wie y33H schon schreibt:
Bullodzer->Piledriver->Steamroller->Excavator
und die bisher erschienenen haben alle L3 Cache erhalten als FX Produkte (ohne GPU) und nicht als APUs.

Und WCCF hat einen einfach einen Tipfehler gemacht. 4 MB entsprechen der Größe des L2 Caches.

Dein erster Link bezieht sich nur auf den L3 Cache bei Sandy Bridge Designs, da bei Intel der L3 Cache zur Kommunikation zwischen CPU und GPU dient. bei AMD APUs wird die selbe Technik über das gemeinsam genutzte Systemmemory (RAM) genutzt. Mehr Details dazu hier:
Es geht um HPC und CPU assisted GPGPU Computing http://www4.ncsu.edu/~yyang14/hpca2012.pdf

Recent examples
include Intel's sandy bridge [21], on which CPUs and
GPUs are on one chip with a shared on-chip L3 cache,
and AMD accelerated processing unit (APU) [26] on
which both on-chip CPUs and GPUs share the same
off-chip memory

Also es funktioniert sowohl mit L3 Cache Designs, als auch mit Gemeinsamem System RAM Designs. Das bedeutet nicht dass es APUs gibt mit L3 Cache, oder dass es diese geben wird. Verwendet wurde eine E2-3200 APU die garantiert keinen L3 Cache besitzt. Das ist auf Seite 2 des Papiers beschrieben.

Der "shared" L2 Cache macht beim Modul Design keinen Sinn bzgl. Performance, doch ist es von Vorteil beim Stromsparen. Pro Modul können zukünftig der L2 Cache in 25% Schritten deaktiviert werden wenn keine Last drauf ist.
Siehe: http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture/2

Finally on the caching front, Steamroller introduces a dynamically resizable L2 cache. Based on workload and hit rate in the cache, a Steamroller module can choose to resize its L2 cache (powering down the unused slices) in 1/4 intervals. AMD believes this is a huge power win for mobile client applications such as video decode (not so much for servers), where the CPU only has to wake up for short periods of time to run minor tasks that don’t have large L2 footprints. The L2 cache accounts for a large chunk of AMD’s core leakage, so shutting half or more of it down can definitely help with battery life. The resized cache is no faster (same access latency); it just consumes less power.

Genauso verhält sich der L2 Cache bei Kabini (Jaguar Architektur) der für alle kerne "shared" ist, sich jedoch auch dynamisch abschalten kann wenn nicht gebraucht.

 

[Theo371]

Ui, ich habe hier gar nicht mehr reingeschaut und bin doch ein wenig verwundert, welche Lawine ich mit meiner kleinen Aussage losgetreten habe. Einige scheinen mir doch etwas überempfindlich zu sein.

Erst einmal zu dem Vorwurf, ein Fanboy zu sein. Da ich mir dieses Jahr den ersten Intel Prozessor (I5-3570K) meines Lebens gekauft habe, weise ich den mal aufs Schärfste zurück. Und in meinem ersten Rechner befand sich ein AMD Am486DX-40, also bin ich nicht mehr wirklich taufrisch und hatte schon einige PCs! :-)

y33H@ hat Recht. Das Kaveri verschoben wurde, ist an mir vorbeigegangen. Meine letzte Information diesbezüglich war H1/2013.

Da der GPU Part von Richland noch auf ein VLIW4 Design beruht, kommt der Chip für mich nicht in Frage. Die Bildqualität von GCN ist deutlich besser. Das konnte ich zumindest zwischen meiner alten HD6950 und meiner jetzigen Grafikkarte HD7950 feststellen.

Also, immer locker bleiben! :-)

LG

Theo