Kaveri - der Trinity Nachfolger

...

Ich glaube nicht, dass das technische "Probleme" sind, die werden die vorhandenen noch knappen Kapazitäten für die Konsolen einfach brauchen. Die müssen ja auch irgendwo vom Band laufen und das sind recht große Mengen. Die werden ja auch durch AMD gefertigt, weil AMD die x86-Lizenz nicht einfach abgeben kann. MS und Sony müssen die AMD-Chips dieses Mal kaufen, anders gehts nicht. Bei TSMC wird AMD dafür keine Kontingente bekommen, zudem sind es evtl. BD-Derivate (zumindest bei Sony), das geht also nur bei GloFo.

Ich frage mich in wie weit das ein Problem für die beiden darstellt. Microsoft hat ja die Prozessoren bei IBM entwickeln lassen und bei IBM (East Fishkill, New York) und Chartered (in Singapur) herstellen lassen. Chartered wurde in GloFlo eingegliedert. Außerdem arbeitet MS schon seit Jahren mit AMD zusammen.
Sony hat Zusammen mit Toshiba und IBM den Cell Prozessor (unter Leitung von IBM) entwickelt und dieser wird soweit wie ich weiss von IBM in East Fishkill, New York, hergestellt.
An sich müsste sich für beide nicht viel ändern, weil bisher Hauptentwicklung und Produktion von anderen übernommen wurde. Ich bezweifel auch mal dass beide eine große Entwicklungs- oder Produktionskapazitäten aufbauen wollen. Zumal die bisherigen jeweils ca 70 -80 Mio. verbauten Konsolen zuwenig dafür sind.

http://www.golem.de/0510/41222.html
http://www.heise.de/newsticker/meldung/ISSCC-IBM-und-Sony-praesentieren-Cell-Prozessor-132971.html
http://www.heise.de/newsticker/meldung/Sony-intensiviert-Chip-Kooperation-mit-IBM-und-Toshiba-57842.html
 
Hmm, stimmt, das klingt eigentlich schlüssig und somit eher schlecht als gut...
 
Hmm, stimmt, das klingt eigentlich schlüssig und somit eher schlecht als gut...

Wieso? Kaveri wurde für Ende des Jahres angekündigt, passt doch. Je näher die Softwareveranstaltung am Hardwareverkaufsstart ist, desto besser, können die Entwickler dann gleich ausprobieren und loslegen. Allen irgendwelche Prototypen zu geben, ginge wohl nur schwer.
 
Wieso? Kaveri wurde für Ende des Jahres angekündigt, passt doch. Je näher die Softwareveranstaltung am Hardwareverkaufsstart ist, desto besser, können die Entwickler dann gleich ausprobieren und loslegen. Allen irgendwelche Prototypen zu geben, ginge wohl nur schwer.


Das sagt nichts über den aktuellen Zustand aus.
 
Ob sich eine Software-API durchsetzt oder nicht hängt meiner Erfahrung nach von 3 Faktoren ab:

1. Die API muss einfach zu Handhaben und Zweckmäßig sein.
2. Gute Dokumentation und Tools.
3. Es muss ein Return of Investment da sein. Bedeutet, Aufwand und Nutzen müssen in einem vernünftigen Verhältnis stehen.

Aktuell ist der Nutzen nur in wenigen Anwendungsfällen vorhanden. Eine OpenCL Anwendung die GPU-Unterstützt ist nur geringfügig schneller als wenn der Code direkt auf der CPU ausgeführt wird. Oder durch Limitierungen müssen Qualitätseinbußen hingenommen werden.

Ich hatte das Bild schon mal gepostet, aber es zeigt das Dilemma sehr anschaulich
Ergebnis eines Profilers für einen Filter einer Bildbearbeitungssoftware:
execution_times.png

Gut 80% der benötigten Zeit sind Overhead, wie Speichertransfers in und aus dem VRAM. Die reine Rechenzeit beträgt gerade mal 12%.
HSA dürfte hier einen enormen Performancesprung bringen.
 
Zuletzt bearbeitet:
Gut 80% der benötigten Zeit sind Overhead, wie Speichertransfers in und aus dem VRAM. Die reine Rechenzeit beträgt gerade mal 12%.
HSA dürfte hier einen enormen Performancesprung bringen.

Das ist hier recht anschaulich dargestellt mit einem Trinity:
slide-32-1024.jpg
 
Kann jemand erklären, was man da nun genau sieht?
 
Kann jemand erklären, was man da nun genau sieht?
Na auf der linken Y-Achse sind die nötigen Codezeilen (Lines of Code) aufgezeichnet auf der Rechten die Leistung. Man sieht also, dass man mit HSA Bolt am wenigstens Code schreiben muss, um am meisten Leistung herauszuholen. Mit OpenCL-C ist wohl noch etwas schneller, aber der Aufwand rechnet sich überhaupt nicht.
 
Obwohl bei Grafiken etwas anderes ausdrücken.
Complicated zeigt den Codierungsaufwand, wieviele Zeile Code ich benötige um die Aufgabe zu erledigen. In Relation dazu den Performancegewinn.

Meine Grafik zeigt wieviel Zeit zur Laufzeit mit welchen Aufgaben verbracht werden. Und da nimmt das hin- und herkopieren 80% der benötigten Zeit ein, die eigentliche Aufgabe lediglich 12%. Code benötige ich dafür aber wenig, deshalb sind die gelben Bereiche so schmal. Und dieses Hin- und Herkopieren kann den Performancegewinn unter Umständen wieder auffressen.

Beide Grafiken ergänzen sich sehr gut.
 
Gut 80% der benötigten Zeit sind Overhead, wie Speichertransfers in und aus dem VRAM. Die reine Rechenzeit beträgt gerade mal 12%.
HSA dürfte hier einen enormen Performancesprung bringen.
Wobei das keine allzu grosse Neuigkeit ist. Es war eigentlich von Anfang an klar, dass die Speicheranbindung einer der entscheidenden Faktoren ist. Der gemeinsame Adressraum wird hier zweifelsohne eine der wichtigsten Neuerungen mit HSA sein. Der Casus Knacksus liegt für mich trotzdem bei der Software. Nur wenn die HSA Programmierung transparent von der Hardware erfolgt, wird es sich durchsetzen. So wie seinerzeit mit Hochsprachen wie C die Programmierung transparent erfolgte und man nicht mehr mit Assembler für eine bestimmte CPU entwickelte. Bolt schaut da auf jeden Fall interessant aus, da man es nutzen kann wie die C++ STL. Für meinen Geschmack geht das allerdings noch nicht weit genug. Eigentlich müssten die Programmiersprachen selbst nativen Support für HSA bieten.
 
Zuletzt bearbeitet:
Das zeigt aber die Grafik von Complicated sehr schön: Der Programmierer kann sich mit HSA wieder voll auf die eigentliche Aufgabe konzentrieren und hat nichts mehr mit dem copy, compilieren und initialisieren der GPU zu tun. Mit HSA (rechts) hat er den gleichen Aufwand wie seinerzeit bei einem Single Core (links) Programm.
 
Aber halt nur, wenn die entsprechenden Bibliotheken zur Verfügung stehen. Mit der Auswahl und Flexibilität bisheriger Lösungen ist das noch nicht vergleichbar.
 
Wieso? Kaveri wurde für Ende des Jahres angekündigt, passt doch. Je näher die Softwareveranstaltung am Hardwareverkaufsstart ist, desto besser, können die Entwickler dann gleich ausprobieren und loslegen. Allen irgendwelche Prototypen zu geben, ginge wohl nur schwer.

Wenn die Veranstaltung nach hinten verschoben wird, ist das deshalb eher schlecht als gut, wenn man darauf spekuliert, dass irgendetwas zum früheren Zeitpunkt noch nicht verfügbar gewesen wäre. Das muss natürlich nicht sein, aber zumindest kann man jetzt nicht direkt einen positiven Aspekt vermuten.
 
Das steht übrigens bei DICE bzw das Bild ist von Johan Andersson.
 

Viel wird noch nicht dazu gesagt. Hier mal das Google-Translate von prohardver.hu

more interesting news is that AMD's APU prototype Kaveri began to spread among the developers , which is strange, because the desktop version did not arrive until November candidate. This is believed to be behind the rush to the new structure, that of the CPU and IGP fully coherent shared memory and address space of a single, major challenge for developers.
und
Johan Andersson, DICE [engine programmer, posted] an interesting picture of the split on Twitter , on which nothing can be seen as the prototype of a new generation of AMD APUs. Even in the dead of last week, rumors that AMD started shipping Kaveri APU development version, and it looks like it was true. Certainly was not only the DICE branded phone, but the rest of Gaming Evolved partner, but no specifics.

Basically, it's no secret that companies are well ahead of the forthcoming send hardware to software developers, but the desktop version of the Kaveri APU is only projected to arrive in November , and three-quarter years before prototypes are not removed from the norm. Some of the hardware is far from definitive, it may still contain errors, which make it more difficult for software development.
Schön zumindest zu sehen, dass derartige dev-kits bereits herausgegeben werden.
Das wären dann die gemeinten "präsentierfähigen samples" (gegeben die Bildüberschrift stimmt). Im Gegensatz zu der Stimmungslage von Nov'12 über einen Projekt-Abbruch ein gewaltiger Umschwung (was aber nicht ausschließt, dass nicht doch eine Kaveri-Version gecancelt wurde).
 
Zuletzt bearbeitet:
Xbit berichtet unter Berufung auf BSN, dass Kaveri auch GDDR5 unterstützt.
Wäre für Notebooks durchaus interessant.
 
Oder Sideport-Memory *lova*
 
"consisting of four 32-bit memory channels."

Na klar doch..

Edit: "Currently most commonly deployed chips only feature 2 GBit capacity, which translates to 256MB per chip."

Das dürfte dann die Erklärung dafür sein warum man Desktops doch lieber mit DDR3/4 bauen mag. Allerdings frage ich mich wie die 8 GB der PS4 zustande kommen sollen. 32 GDDR5-Chips auf dem Mainboard?
 
Zuletzt bearbeitet:
Xbit berichtet unter Berufung auf BSN, dass Kaveri auch GDDR5 unterstützt.
Wäre für Notebooks durchaus interessant.
Von den Datenraten her ist das mMn eher ein Hinweis auf DDR4. QDR 800 ist DDR4-3200 und das soll ja einer der Startgeschwindigkeiten sein. Ist jetzt die Frage, was da im PDF stand. Stand da nur QDR oder stand da explizit GDDR5?
GDDR5 mit 1,6 Ghz ist eigentlich Kinderkram, das wird doch fast nicht mehr angeboten, die niedrigsten Datenraten sind schon 900 Mhz = 3,6 GT/s:
http://www.samsung.com/global/busin...t/graphic-dram/detail?productId=7495&iaId=759
Übersicht:
http://www.samsung.com/global/business/semiconductor/product/graphic-dram/catalogue

Aktuell sind 7 GT/s also mehr als das Doppelte der angegebenen 3,2 GT/s.

@Markus:
Die haben veraltete Infos, wenn Du oben auf meinem Übersichtslink klickst, dann siehst Du Folgendes:
Partnumber Density Organization Speed Package Refresh Interface Production Status

K4G41325FC 4Gb 128Mx32 28, 03, 04 170FBGA 16K/32ms POD_15 MassProduction

Ist halt schwer mal schnell bei Samsung auf die GDDR5-Übersichtsseite zu klicken ;)
 
Zurück
Oben Unten