AMD Kabini APU / Jaguar CPU + Graphics Core Next GPU, 2-4 Kerne, 28nm TSMC, 2013

Opteron schrieb:
Ja jetzt, aber die Produktionsentscheidung hat man vor mind. nem Jahr gefällt.
Zum Vergrößern anklicken....

Zu einem Zeitpunkt also als GF noch keinen funktionierenden 28nm Prozess mit entsprechender Yield vorweisen konnte. Pferdewetten hatten in der Vergangenheit höhere Trefferquoten als Wetten auf GFs neue Prozesse.

Umgekehrt konnte TSMC vermutlich glaubhaft machen das zum Zeitpunkt X entsprechende Kapazitäten bereit stehen.

Übrigens ist noch die Frage wer da Kapazitäten reservieren musste. AMD ist Produzent, Sony Auftraggeber. Sony bezieht die Produkte nach meinem Verständnis von AMD, nicht von einer Foundry.
 
Zuletzt bearbeitet:
Markus Everson schrieb:
Zu einem Zeitpunkt also als GF noch keinen funktionierenden 28nm Prozess mit entsprechender Yield vorweisen konnte
Zum Vergrößern anklicken....
Jo, nachdem sie 28nm schon seit gefühlten "Urzeiten" offiziell im Programm und angeblich auch lieferbar haben, war die Wette darauf, dass sie es 2013 im Griff haben werden nicht übermäßig riskant.

Aber 100% glaub ich die Meldung trotzdem nicht, gibt für beides Argumente. TSMC hat ja auch gesagt, dass ab 2013 neue Fabs mit 28nm anlaufen und die Versorgungslage verbessern werden.
Ich würde mal sagen ... 50/50.
 
Mal was zur Double precision Leistung: Der Bobcat hat ja laut Agner Fogs instruction table für MULPD und ADDPD einen Durchsatz von 0.25 und 0.5. Die gesamte DP-Leitsung pro Kern (1.6Ghz) dürfte also bei:

(2*0.5+2*0.25)*1.6 = 2.4 GFLOPS

liegen. Die Verbreiterung von 64 auf 128 bit ist ja bekannt, aber weiß man schon, ob DP-MUL immer noch nur den halben Durchsatz im Vergleich zu DP-ADD hat?

Also
(2*1+2*0.5)*2.0 = 6 GFLOPS
oder
(2*1+2*1)*2.0 = 8 GLFOPS
 
Deine Frage sollte Folie 9 von der HC 2012 beantworten:


.
EDIT :
.
Keine Ahnung, ob das schon gepostet wurde. Hier gibt es übrigens das PDF von der ISSCC.
 
Ah ok, DP-MUL ist also immer noch halfrate. Ist für die Allerweltsperformance nicht wirklich von Bedeutung, aber da ich gelegentlich Simulationscodes auf meinem Notebook entwickle für mich schon interessant. Andrerseits machts wahrscheinlich auch für DP FP-dominierten Code kaum einen Unterschied, da machen doppelte Kernanzahl, mehr Takt, doppelt breite SIMDs und mehr Speicherbandbreite viel mehr aus.
 
Da sollte es für dich schon wichtiger sein, ob die GCN Kerne auf Kabini DP-MUL unterstützen.
Dank gemeinsamen Adressraum und Flat Speichermodell sollten schon ab geringen Datenmengen Berechnungen auf der GPU Vorteile haben gegenüber den Jaguar FPUs.
 
Kabini beherrscht noch kein HSA und somit auch keinen gemeinsamen Adressraum - erst Kaveri.
 
y33H@ schrieb:
Kabini beherrscht noch kein HSA und somit auch keinen gemeinsamen Adressraum - erst Kaveri.
Zum Vergrößern anklicken....

Kabini beherrscht HSA ebenso wie Temash. Und gemeinsamer Adressraum ist nur ein kommendes Feature von HSA das mit Kaveri eingeführt werden soll. Lies dich doch mal endlich in die Thematik ein und hör auf solche falschen Kommentare abzugeben.

http://wccftech.com/amd-richland-ap...nching-2013-kabini-apu-radeon-hd-8000-series/

amd_2013_roadmap.jpg


In addition, the new HSA features would also be introduced in Kabini and Tamesh 28nm ULP (Ultra Low Power) APUs.
Zum Vergrößern anklicken....

Auch Trinity beherrscht HSA ohne den gemeinsamen Adressraum zu haben.
 
Wieso ist demnach IvyBridge HSA fähig? Ich kann deiner Logik nicht folgen.

Trinity besitzt kohärenten Adressraum - das ist ein HSA Feature.
Trinity HSA Performance:

slide-19-1024.jpg
 
Du meinst einen kohärenten Speicher, oder? Gemeinsamer Adressraum kommt ja erst später.
 
So geil. Wieder eine amd-folie mit fehler. 2,3 Mhz (turbo 3,2 ghz) ;D
Kriegen die das irgendwann mal gebacken?
 
Zuletzt bearbeitet:
Twodee schrieb:
Du meinst einen kohärenten Speicher, oder? Gemeinsamer Adressraum kommt ja erst später.
Zum Vergrößern anklicken....
Ich verstehe deine Frage nicht. Oder habe ich kohärent falsch geschrieben?

Zu der Performance Folie hier auch die erklärung was dort zu sehen ist:
http://developer.amd.com/resources/...hat-is-heterogeneous-system-architecture-hsa/
Multiple compute tasks can work on the same coherent memory regions, utilizing barriers and atomic memory operations as needed to maintain data synchronization (just as multi-core CPUs do today).

The HSA team at AMD analyzed the performance of Haar Face Detect, a commonly used multi-stage video analysis algorithm used to identify faces in a video stream. The team compared a CPU/GPU implementation in OpenCL™ against an HSA implementation. The HSA version seamlessly shares data between CPU and GPU, without memory copies or cache flushes because it assigns each part of the workload to the most appropriate processor with minimal dispatch overhead. The net result was a 2.3x relative performance gain at a 2.4x reduced power level*. This level of performance is not possible using only multicore CPU, only GPU, or even combined CPU and GPU with today’s driver model. Just as important, it is done using simple extensions to C++, not a totally different programming model.

HW Configuration

4GB RAM; Windows 7 (64-bit); OpenCL™ 1.1
APU: AMD A10 4600M with Radeon™ HD Graphics
CPU: 4 cores @ 2.3 GHz (turbo 3.2 GHz)
GPU: AMD Radeon HD 7660G, 6 compute units, 685MHz
Zum Vergrößern anklicken....
 
Natürlich sind das zwei verschiedene Dinge, doch spielt das in meiner Ausführung zu HSA keine Rolle. Kohärenter Speicher bedeutet zusammenhängend und nicht getrennt. Das ist immer noch etwas anderes als gemeinsamer Speicher (oder präzise gemeinsame Speicheradressierung) von CPU und GPU. APUs verwenden ja gemeinsamen physischen Speicher und die Adressierung ist kohärent.

Die gemeinsame Speicheradressierung der HSA fähigen GPU und CPU Hardware bezeichnet getrennte Speicher auf dem Mainboard und z.B. GDDR5 Speicher auf der GPU, welche in einen gemeinsamen Adressbereich verwandelt werden und der CPU eben direkten Zugriff auf den GPU GDDR5 Speicher ermöglichen und umgekehrt.

Siehe: http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf

Coherent memory regions
. In traditional GPU devices, even when the CPU and GPU are using the same system memory region, the GPU uses a separate address space from the CPU, and the graphics driver must flush and invalidate GPU caches at required intervals in order for the CPU and GPU to share results. HSA embraces a fully coherent shared memory model, with unified addressing. This provides programmers with the same coherent memory model that they enjoy on SMP CPU systems. This enables developers to write applications that closely couple LCU and TCU codes in popular design patterns like producer-consumer.

The coherent memory heap is the default heap on HSA and is always present. Implementations may also provide a non-coherent heap for advance programmers to request when they know there is no sharing between processor types.
[...]
2.2.
Unified Address Space
HSA defines a unified address space across LCU and TCU devices. All HSA devices support virtual address translation: a pointer (that is, a virtual address) can be freely passed between devices, and shared page tables ensure that identical pointers resolve to the same physical address.

Internally, HSA implementations provide several special memory types (some on chip, some in caches, and some in system memory), but there is no need for special loads or stores. A TCU memory operation (including atomic operations) produces the same effects as a LCU operation using the same address. All memory types are managed in hardware. An HSA-specific memory management unit (HMMU) supports the unified address space. The HMMU allows the TCUs to share page table mappings with the CPU. HSA supports unaligned accesses for loads and stores; however, atomic accesses have to be aligned.

Many compute problems today require much larger memory spaces than can be provided by traditional GPUs, whether we are discussing the local memory of a discrete GPU or the pinned system memory used by an APU. Partitioning a program to repeatedly use a small memory pool can require a huge programming effort, and for that reason large workloads often are not ported onto the GPU. Allowing the HSA throughput engine to use the same pageable virtual address space as the CPU, allows problems to be easily ported to an HSA system without extra coding effort. This significantly increases computational performance of programs requiring very large data sets.
Zum Vergrößern anklicken....

Hier nochmal präziser zusammengefasst:
http://www.extremetech.com/computin...i-will-fully-share-memory-between-cpu-and-gpu
Trinity, the company’s latest APU available to consumers, beefs up the GPU and CPU interconnects with the Radeon Memory Bus and FCL connections. These allow the GPU access to system memory and the CPU to access the GPU frame buffer through a 256-bit and 128-bit wide bus (per channel, each direction) respectively. This allows the graphics core and x86 processor modules to access the same memory areas and communicate with each other.

Kaveri will take that idea even further with shared memory and a unified address space.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Warum schreibst du dann, "Trinity besitzt kohärenten Adressraum", oder war das nur ein Vertipper?
 
Weil der Adressraum für die GPU kohärent ist. Die CPU greift über den GPU Framebuffer auf deren Daten zu. Das ist die Vorstufe zum komplett gemeinsamen Adressraum für CPU und GPU der mit Kaveri kommt und den Umweg über den Framebuffer beseitig.
 
Hmmm, hatte das bei Trinity anders im Kopf.

EDIT
Jupp, AMD sagte auf dem AFDS12, Kaveri wird der erste HSA-Chip ... in den Presse-Decks zu Trinity war von HSA iirc nie direkt die Rede, nur in den Dev-PDFs.
 
Zuletzt bearbeitet:
y33H@ schrieb:
Hmmm, hatte das bei Trinity anders im Kopf.

EDIT
Jupp, AMD sagte auf dem AFDS12, Kaveri wird der erste HSA-Chip ... in den Presse-Decks zu Trinity war von HSA iirc nie direkt die Rede, nur in den Dev-PDFs.
Zum Vergrößern anklicken....
Das könnte daran liegen, dass HSA=Fusion. Llano war der erste Fusion (HSA) APU-Chip. Es gibt genügen Folien und Docs die noch von FSA sprechen statt HSA. (Fusion System Architecture)
 
Zu HSA gehört doch noch mehr als nur ein gemeinsamer Adressraum. Ich habs so verstanden, dass Kaveri HSA voll unterstützt mit austauschbaren Pointern und Multithreading. Das ist bei Trinity noch nicht der Fall, soweit ich weiß. Und erst bei Sea Island wird von der GPU API ein Flat Memory Modell unterstützt. Wegen der Aussage von Sony zur PS4 APU und einiger Folien die HSA Features bei Kabini erwähnen, nahm ich an, dass bei Jaguar GCN der Sea Island Befehlssatz unterstützt wird.
Es gibt doch auch diese Folie, auf der die verschiedenen Phasen zu HSA aufgeführt ist.
file.php
 
amdfanuwe schrieb:
Wegen der Aussage von Sony zur PS4 APU und einiger Folien die HSA Features bei Kabini erwähnen, nahm ich an, dass bei Jaguar GCN der Sea Island Befehlssatz unterstützt wird.
Zum Vergrößern anklicken....
HSA ist v.a. von der Uncore/Northbridge abhängig. Im Moment hatten da ja alle APUs getrennte Speicherkontroller, nur der DRAM-Kontroller war auf einfach ausgeführt. Was jetzt AMD mit kabini macht und Sony für die PS4 geordert hat, muss nicht zwangsläufig das gleiche sein. Man weiss, dass die PS4 Jaguar-Kerne hat - ja - aber die Kerne sagen nichts übers Uncore aus.
Es gibt doch auch diese Folie, auf der die verschiedenen Phasen zu HSA aufgeführt ist.
Zum Vergrößern anklicken....
Da gibts mittlerweile die aktualisierte Version, da haben sie statt der Jahreszahlen die Chipnamen mit dran geschrieben:

slide-33-638.jpg

http://de.slideshare.net/AMD/amd-isscc-keynote

War mir für ne Extra-Meldung aber zu dünn. Für die aktuelle Diskussion ist aber wohl der untere Bildteil mit den verschiedenen Speichersetups interessant.
 
Dass nur die "großen" APUs aufgeführt sind, lässt Raum zur Spekulation, dass die kleinen bezüglich HSA doch noch etwas hinterherhinken; anders gesprochen, dass der Speichercontroller der PS4 mehr HSA-Ähnlichkeit mit dem von Kaveri besitzt, als jener in Kabini/Temash.
 
FredD schrieb:
Dass nur die "großen" APUs aufgeführt sind, lässt Raum zur Spekulation, dass die kleinen bezüglich HSA doch noch etwas hinterherhinken; anders gesprochen, dass der Speichercontroller der PS4 mehr HSA-Ähnlichkeit mit dem von Kaveri besitzt, als jener in Kabini/Temash.
Zum Vergrößern anklicken....
Jupp, gänzlich ausschließen kann mans aber wohl nicht. Das könnte auch nur Prestige-Denken sein, man will schließlich mit seinen tollen High-performance CPUs angeben, und nicht mit den low-power Tablet-Teilen mit ein paar wenig Shaderunits werben *lol*

Bin mir z.B. sicher, dass Ontario das gleiche Setup wie Llano/Trinity hat, halt 2 Speicherkontroller für CPU+GPU, obwohl er nicht aufgeführt wird. Was sollte der Chip auch sonst haben.

Große Preisfrage bei der Sache ist nun, woher der neue, gemeinsame HSA-Speicherkontroller kommt. Ist das eher ein CPU-Speicherkontroller, der nun auch die GPU bedienen kann, oder stammt er aus der GPU-Abstammungslinie ab und die CPU kommt nun auch damit klar? Falls Letzteres, dann könnte man davon ausgehen, dass die GNC-APUs den gemeinsamen Speicherkontroller haben, und somit auch Kabini 100% HSA kompatibel wäre. Ein Extra-Design würde sich wohl kaum lohnen aber da die zwei GPU-Compute-Units keine großen GPGPU-Sprünge erlauben, wirbt man halt nicht damit.

Aber man weiss halt nix.
 

Ähnliche Themen

pipin
AMD Takes High-Performance Datacenter Computing to the Next Horizon
Antworten
0
Aufrufe
965
pipin
pipin
Onkel_Dithmeyer
AMD Redefines High-Performance Computing with New Processor and Graphics Products Preview at CES 2018
Antworten
0
Aufrufe
2K
Onkel_Dithmeyer
Onkel_Dithmeyer
Dr@
News Gamescom 2013: Playstation 4 unterstützt hUMA, Xbox One jedoch nicht [2. Update]
2
Antworten
49
Aufrufe
12K
Opteron
Opteron
I
AMDs Semi-Custom Business Unit - Projekte, Partner und Chips
15 16 17
Antworten
413
Aufrufe
82K
sompe
S
Nero24
News Packard-Bell Notebook mit AMD Kabini APU auf dem Markt
2
Antworten
26
Aufrufe
7K
mmoses
mmoses
Zurück
Oben Unten