> > > > AMD Kaveri: Erstes Engineering-Sample aufgetaucht

AMD Kaveri: Erstes Engineering-Sample aufgetaucht

DruckenE-Mail
Erstellt am: von

AMD Logo 2013AMDs „Kaveri“-APUs sollen Anfang Dezember vorgestellt werden, aber erst im Februar des nächsten Jahres in den Handel kommen. Vermutlich wird AMD die CES 2014 Anfang Januar nutzen, um die Aufmerksamkeit auf seine neuen APUs zu ziehen und vermutlich auch im Zuge des Developer Summits, der am 11. November in San Jose starten wird, weitere Informationen preisgeben. Nun tauchte auf der chinesischen Webseite vr-zone.com ein erstes Foto eines Prototypen auf. Viel zu sehen gibt es allerdings noch nicht.

Die Aufschrift „Diffused in Germany, made in Malaysia“, weist lediglich darauf hin, dass das Globalfoundries-Werk in Dresden, erstmals für AMD 28-nm-High-Performance-Wafer produzieren und die APU in Malysia zusammengesetzt und verpackt werden wird. „Kaveri“ wird auf neuen „Steamroller“-CPU-Kernen und einem Grafikkern auf „GCN“-Basis, der der Radeon-HD-7000-Familie entstammt, aufbauen.

Zum Stapellauf von „Kaveri“ soll es zunächst drei Modelle geben: Zwei A10-APUs der High-End-Klasse und ein Modell der A8-Reihe des leistungsschwächeren Performance-Segments.

Social Links

Ihre Bewertung

Ø Bewertungen: 0

Tags

Kommentare (27)

#18
Registriert seit: 23.09.2009

Kapitänleutnant
Beiträge: 1917
Zitat fdsonne;21383283
Ja leider habe ich diese "Ahnung"... Deswegen scheint auch meine Sicht anders auf die Dinge zu sein, als bei so manchem Euphoriker :wink:
Und klar kanns der Compiler zum Teil richten... Ja und? Sag das nicht mir, sag das den Leuten, die die ganze Software auf den Markt gebracht haben...
Ich kann nix für, das die neuen CPUs von AMD ihre Leistung erst entfalten, wenn da FMA und Co. in use sind... Und ich kann ebenso wenig für, das diese eben scheinbar in der Leistung zurück liegen, wenn man es nicht macht genau so wenig wie ich dafür kann, das die APU stand heute nur dann die GPU mitrechnen lässt, wenn die Software dediziert diese anspricht.


Schau dir doch mal die Geschichte der Hard/-Softwareentwicklung an. Es kam noch nie vor, dass ein Feature von der Software genutzt wurde, bevor es spezifiziert oder die Hardware da war. Ein sehr gutes Beispiel ist wohl die FPU bzw. damals der Mathematische Co-Prozessor. Also warum soll es bei den APUs denn jetzt auf einmal anders ablaufen?

Zitat fdsonne;21383283

Erklär mir dochmal, warum ich mir dafür den Deckel aufsetzen lassen soll? Nur weil ich den Umstand anspreche? Und so nicht gut heißen kann? Sorry, aber was soll das?


Es ist jedem Bewusst, das es entsprechende Software braucht, du reitest nur andauern darauf herum. Im Prinzip verlangst du etwas von den APUs, dass es vorher noch nie gegeben hat, die Nutzung neuer Technik mit altem, schon compiliertem Code.

Zitat fdsonne;21383283

Was ich erwarte, ist doch völlig nebensächlich...
Mir ist das doch vollkommen egal, wer da auf dem CPU Deckel steht. Ich kaufe nach P/L. Und "L" definiert die Software die ich habe bzw. zu Benutzen gedenke. Also richtet sich die Kaufentscheidung einzig daran...

Und zum anderen, das ist auch schön so... Nur was macht dieses Wissen für einen Unterschied? Ohne Software, nix mehr Performance... Das Endresultat stand heute hat sich dahingehend nicht geändert. Oder steh ich auf dem Schlauch!?


Ich denke schon, dass es wichtig ist, was du erwartest, sonst würdest du nicht immer auf der fehlenden Software rum reiten ;)

Zitat fdsonne;21383283

Es muss ja keine Perfekte Lösung sein ;)
Sprungvorhersagen beispielsweise gibts nicht erst seit heute... Und die laufen eben auchmal ins leere. Aber es gibt sie und ohne sie wäre der Speed wohl auch deutlich? schlechter als mit.


Du vergleichst Äpfel mit Birnen. Eine Sprungvorhersage muss nur nach ein paar speziellen Befehlen filtern. Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.

Zitat fdsonne;21383283

Im Endstadium von Fusion sollte das aber auch weniger eine Rolle spielen. Nämlich wenn ALUs beispielsweise der CPU so beiseite gestellt werden, das beispielsweise jegliche Gleitkommaoperationen auf diesen ablaufen.
Eventuell löst man sich so auch irgendwann vom klassischen "Core" CPU Konzept. So gibt es dann eben nicht mehr die klassichen CPU Cores oder auch CPU Module in CMT Bauweise, sondern es gibt nur noch Int Cores mit ner ganzen Latte von Gleitkommaprozessoren beispielsweise. Gepaart mit ner Einheit, die eben die Berechnungen in Hardware auf die ALUs verteilt...
Nur ist das alles Zukunftsmusik...


Ich würde sagen die GPUs sind zZ. noch zu langsam für einzelne FPU Berechnungen (geringer Takt) und zu simpel. Da müsste sich erst was tun bis sie die FPU ersetzten könnten. Ein Aufbohren würde aber so viel Fläche kosten, dass die schiere Masse verloren gehen würde. FPU und GPU rechnen zwar beide mit Gleitkomma zahlen, doch haben sie beide ihre Stärken und Schwächen. Wir werden also noch eine ganze Weile mit CPU, FPU und GPU leben müssen.

Zitat fdsonne;21383283

Heute bzw. Morgen sehen wir eine CPU mit zwei Modulen in Form von Steamroller Cores, der eine GPU auf GCN Basis beseite gestellt wird und zwischen welchen die Möglichkeit besteht auf einen gemeinsamen Speicherbereich zugreifen zu können. Mit Ausnahme der shared Memory Funktion bleibt die GPU aber GPU und der CPU Part eben CPU.
Und wie gesagt, mach mich bitte nicht dafür verantwortlich, ich kann da nix für :wink:


Wo mach ich dich denn dafür verantwortlich?

Nur mal so, in heutigen Prozessoren ist die FPU immer noch eine eigenständige Einheit, die neben den Integerkernen verbaut wird ;)
Man hat sie zwar immer weiter Integriert, mit einem gemeinsamen Decoder und eigenen Befehlssätzen, es ist aber immer noch eine eigenständige Einheit.
#19
customavatars/avatar84710_1.gif
Registriert seit: 10.02.2008

Admiral
Beiträge: 15048
Zitat why_me;21383916
Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.


Die Abschnitte kann der Entwickler ja auch markieren, so dass eingangs immer nur eine Abfrage stattfindet, man muss nicht den komplizierten weg gehen alles vorher zu analysieren. Du setzt dich ja auch in den Zug nach München, weil das Fahrtziel dadrauf steht und analysierst nicht erst ob der da auch wirklich hinfährt. ;)
#20
Registriert seit: 23.09.2009

Kapitänleutnant
Beiträge: 1917
Ich sag doch nichts anderes, der Compiler soll spezielle Befehle (eigenen Befehlssatz) oder irgend welche Flags setzten, .... Was fsdonne aber will ist, dass die Hardware das selbst entscheiden kann egal wie das Programm compiliert wurde und da bin ich der Meinung, dass das nie passieren wird.
#21
customavatars/avatar84710_1.gif
Registriert seit: 10.02.2008

Admiral
Beiträge: 15048
Da würde ich einfach mal die Entwicklung abwarten, "smarter" dürfte die Hardware mit der Zeit definitiv werden. Nur wie schnell das geht oder wie "smart" die werden, steh wohl in den Sternen. ;)
#22
customavatars/avatar108198_1.gif
Registriert seit: 08.02.2009
München
Flottillenadmiral
Beiträge: 4354
Zitat Mick_Foley;21384381
Da würde ich einfach mal die Entwicklung abwarten, "smarter" dürfte die Hardware mit der Zeit definitiv werden. Nur wie schnell das geht oder wie "smart" die werden, steh wohl in den Sternen. ;)


Anscheinend wird der Bedarf an smarten Lösungen nur gezielt gefordert z.B. bei Berechnung und Entschlüsselung von großen Daten, also eher in Produktion und Forschung des Profibereichs. Da AMDs Kaveri auf den Desktopmarkt zielt, wäre ich nicht zu optimistisch, dass sich demnächst ein großes Momentum entwickelt. Zumindest kenne ich im Konsumerbreich aus der näheren Umgebung niemanden, der sich dafür interessiert, dass irgendwelche Apps oder Softwarelösungen signifikant beschleunigt werden.
#23
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31558
Zitat why_me;21383916
Schau dir doch mal die Geschichte der Hard/-Softwareentwicklung an. Es kam noch nie vor, dass ein Feature von der Software genutzt wurde, bevor es spezifiziert oder die Hardware da war. Ein sehr gutes Beispiel ist wohl die FPU bzw. damals der Mathematische Co-Prozessor. Also warum soll es bei den APUs denn jetzt auf einmal anders ablaufen?

Wie lange gibts GPGPU nun schon?
Ich denke, das dürfte gegen Mitte 2007 mit CUDA seitens NV losgegangen sein... AMD folgte etwas später mit Stream.
Und was ist jetzt mit der Software? Ich sehe neben ein paar wenigen dedizierten Spezialfällen nix. Keine Alltagssoftware nutzt die GPU. Bzw. wenn, dann macht es die Sache nicht dadurch zum "Renner" und es geht genau so auch ohne... (Browser mit GPU Beschleunigung)
Das ist der Punkt... Das es erst eine Hardware geben muss, um überhaupt die Software darauf zu entwickeln sollte logisch sein, wurde auch von mir nirgends angezweifelt. Nur es gibt eben die Hardware seit Generationen schon... Nur wird sie überwiegend nicht ausgenutzt (bis auf den CPU Teil)...

Der Unterschied zwischen unseren Meinungen scheint einzig daran zu hängen, das ich eben aufgrund der bisherigen Software auf Hardware Anpassungen und dem Ansprechverhalten stark bezweifle, das die ganze Sache für AMD aufgeht. Mit dem Bulldozer ist man auf die Nase gefallen und das Ding ist viel zu langsam im Schnitt gegen die Konkurenz -> so das man das Ding mit hohen Taktraten, hohen Spannungen und vor allem viel zu niedrigem Preis anbieten muss.
Das APU Konzept selbst ist nicht verkehrt. Nur als Zugpferd (da will doch AMD aktuell hin mit APUs only für Sockel FMx in Zukunft) sehe ich die notwendig zu meisternden Hürden von externen Firmen als viel zu hoch an, dass da am Ende für AMD das rauskommt, was sie eigentlich bräuchten -> nämlich endlich mal wieder ein Produkt, was am Markt richtig gut platziert ist und wo man auch mit den Preisen mal nicht im Keller agieren muss.

Zitat why_me;21383916
Es ist jedem Bewusst, das es entsprechende Software braucht, du reitest nur andauern darauf herum. Im Prinzip verlangst du etwas von den APUs, dass es vorher noch nie gegeben hat, die Nutzung neuer Technik mit altem, schon compiliertem Code.

Genau hier zum Beispiel machst du mich dafür verantwortlich... Ich reite nicht auf der Software rum, ich spreche den Umstand an, weil der immer wieder verdrängt wird.
Ein Ansprechen des Umstandes wäre absolut nicht notwendig, wenn es allseits bekannt wäre... Ist es aber scheinbar nicht. Man schaue sich die Kommentare hier und in anderen APU Threads an, speziell eben zum Thema Fusion und Co. -> da denken sich scheinbar einige, das die Hardware auf einmal rasend schnell wird ohne irgendwelches zutun.
Beispiel gefällig:
http://www.hardwareluxx.de/community/f11/amd-kaveri-erstes-engineering-sample-aufgetaucht-987618.html#post21380793
Aus dem Zitat ist zu entnehmen, das die APU nun Berechnungen auf dem GPU Part ausführen kann... Wird dediziert erwähnt und hervorgehoben? Warum? Ja scheinbar legt man da Wert drauf... Und ich sage daraufhin -> ja schön und gut, aber du brauchst du die Software, die es sogut wie gar nicht gibt. Und wie die Vergangenheit zeigt, die sich bestenfalls mäßig schleppend an soetwas anpasst. Siehe Llano Vergleich. CPU Seitig noch langsamer als die aktuellen APUs, und die GPU bekommt auch nach 2,5 Jahren fast keine Aufgaben zu tun.

Zitat why_me;21383916
Ich denke schon, dass es wichtig ist, was du erwartest, sonst würdest du nicht immer auf der fehlenden Software rum reiten ;)

Nochmal, ich reite nicht drauf rum... :wink:
Ein Ansprechen des Umstandes, der von anderen vergessen, verdrängt oder einfach durch unwissenheit nicht beachtet wurde ist kein "rum reiten".

Zitat why_me;21383916
Du vergleichst Äpfel mit Birnen. Eine Sprungvorhersage muss nur nach ein paar speziellen Befehlen filtern. Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.

Es gibt immer Mittel und Wege sein Ziel zu erreichen...
Auch ist es nicht meine Aufgabe, die APUs zu entwerfen oder den Jungs bei AMD irgendwelche Tips zu geben... Zumal ich mir das wohl nichtmal selbst anmaßen würde, zu tun.
Die wissen schon was sie machen.
Heist also, wie sie diesen Umstand entgegenwirken (oder ob überhaupt) kann bestenfalls spekuliert werden.
Und wenn es eben in Hardware nicht geht, muss es halt in Software gelöst werden. Wie Mick sagte... Oder man fährt bei der Entwicklung gleich mehrgleisig und entwickelt gewisse Funktionen usw. speziell angepasst für die Hardware X oder Y
Oder lässt gar dem User am Ende die Wahl usw. usf.

Zitat why_me;21383916
Ich würde sagen die GPUs sind zZ. noch zu langsam für einzelne FPU Berechnungen (geringer Takt) und zu simpel. Da müsste sich erst was tun bis sie die FPU ersetzten könnten. Ein Aufbohren würde aber so viel Fläche kosten, dass die schiere Masse verloren gehen würde. FPU und GPU rechnen zwar beide mit Gleitkomma zahlen, doch haben sie beide ihre Stärken und Schwächen. Wir werden also noch eine ganze Weile mit CPU, FPU und GPU leben müssen.

deswegen schrieb ich von Zukunftsmusik...



Zitat why_me;21383916
Wo mach ich dich denn dafür verantwortlich?

Nur mal so, in heutigen Prozessoren ist die FPU immer noch eine eigenständige Einheit, die neben den Integerkernen verbaut wird ;)
Man hat sie zwar immer weiter Integriert, mit einem gemeinsamen Decoder und eigenen Befehlssätzen, es ist aber immer noch eine eigenständige Einheit.


zum ersten, siehe oben beispielsweise... Jedesmal wenn ich mich hier kritisch über eine Sache äußere, kommen scheinbar immer die selben Leute und meinen da irgendwas dran aussetzen zu müssen.
Es macht den Eindruck, als wäre ich dran schuld, weil ich den Umstand anspreche... :wink:
Sollte es so nicht gemeint gewesen sein, ist auch OK ;)

Zum anderen, ja, aber was spielt das zur Sache?
Ich spreche mit meiner Software üblicherweise Programmiert in irgend ner Hochsprache nicht direkt die FPU an.
Das muss ich aber stand heute mit der GPU machen. -> und das ändert sich mit Kaveri genau Null, auch nicht durch HSA und hUMA. Oder habe ich hier nen Denkfehler?
#24
customavatars/avatar43164_1.gif
Registriert seit: 18.07.2006
Halle (Saale)
Kapitänleutnant
Beiträge: 1865
Das Problem liegt mMn eher bei den Entwicklern und deren "Trägheit". Ich selbst schreibe meine Programme seit knapp 2 Jahren wenn irgend möglich so, dass die GPU die Aufgaben bekommt (Aparapi, OpenCL und APP-SDK). Vorteil meinerseits ist einfach die Entwicklungszeit und der Entwicklungsaufwand (verhältnismäßig kleine Programme für explizite Kundenanforderungen).
Wenn man aber erst ne ganze Menge an fertigen Modulen hat, nutzt man, was man hat und fertig ist. Also bleibt es beim Berechnen über Standardcompiler und somit bei der CPU...
Das wird sich auch nicht wirklich ändern, außer ein Treiber oder ein Zusatzchip kümmert sich in naher Zukunft darum, in Echtzeit die Entscheidung dafür treffen zu können, was an die Graka gehen kann und was nicht bzw. kümmert sich um die entsprechende Vorbereitung des Codes.
Wäre ja schon ein riesiger Fortschritt, wenn die VMs/Laufzeitumgebungen der höheren Programmiersprachen nativ auf der Graka laufen würden...
#25
Registriert seit: 06.05.2010

Stabsgefreiter
Beiträge: 362
Zitat fdsonne
Zum anderen, ja, aber was spielt das zur Sache?
Ich spreche mit meiner Software üblicherweise Programmiert in irgend ner Hochsprache nicht direkt die FPU an.
Das muss ich aber stand heute mit der GPU machen. -> und das ändert sich mit Kaveri genau Null, auch nicht durch HSA und hUMA. Oder habe ich hier nen Denkfehler?

Deshalb versucht AMD ja die OpenCl Verbreitung zu steigern. z.B. LibreOffice: [Phoronix] LibreOffice Lands A Ton Of GPU OpenCL Functions. Hm kommt ein Monat zu spät. Ich hätte schon gerne gesehen, ab welcher Projektgröße das was bringt. Auch der Multicore Support ist interessant: [Phoronix] LibreOffice Getting Better Multi-Threaded Goodness
freut mich ich nutze LibreOffice.
Viel wichtiger sind die Kompiler:
Heterogeneous Queuing: AMD will CPU und GPU enger zusammenarbeiten lassen | heise online
Mal sehen ob alte Javaprogramme davon auch profitieren.
Zitat smoothwater
Das wird sich auch nicht wirklich ändern, außer ein Treiber oder ein Zusatzchip kümmert sich in naher Zukunft darum, in Echtzeit die Entscheidung dafür treffen zu können, was an die Graka gehen kann und was nicht bzw. kümmert sich um die entsprechende Vorbereitung des Codes.

Meiner Meinung würde es ausreichen wenn der Kompiler das übernimmt. Ich stell mir das einfach in Echtzeit nicht so performant vor, wobei das in Java oder einer anderen Programmiersprache, deren Kompilat nicht direkt auf der Hardware ausgeführt wird, wahrscheinlich ginge.
Schön wäre es wenn gcc oder ein anderer Open-Source Kompiler dies könnte. Dann dauert das Kompilieren zwar länger, aber man müsste die Entscheidung nicht in Echtzeit treffen.
#26
customavatars/avatar43164_1.gif
Registriert seit: 18.07.2006
Halle (Saale)
Kapitänleutnant
Beiträge: 1865
Wenn das Programm direkt an dem System erstellt wird, wo es letztlich ausgeführt wird, stimme ich dem zu. Ansonsten sind wieder zuviele Hardwareabhängigkeiten drin, die bei der Code-Erstellung beachtet werden müssten (oder aber es wird direkt in OpenCL gewandelt, weil das alle Großen unterstützen). Java geht ja schon in die Richtung (Java 9 / Aparapi).
#27
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31558
Zitat neuli;21388958
Deshalb versucht AMD ja die OpenCl Verbreitung zu steigern.


Und das ist genau das was ich oben sagte... Man versucht den Markt dort hin zu entwickeln, wo es einem selbst am besten nutzt.
Unterm Strich natürlich nicht primär ein Problem. Aber AMD ist leider der kleinere der beiden. Und hat auch entsprechend weniger Marktmacht für solche Spielereien.

Das ganze stelle ich mir im OpenSource Bereich sogar noch ganz praktikabel vor. Für so einige Projekte mit halbwegs anständiger Marktdurchdringung gibts ja heute schon teils angepasste Versionen, bzw. wenigstens spezielle "Kompilate" für die verschiedenen Hardwareansatze (auch im x86 Bereich)
Nur fehlt das aus meiner Sicht quasi vollständig in der kompletten Windows und OSX Welt... Letztere baut halt native auf Intel mittlerweile, also nicht verwunderlich. Aber die Windows/Linux Welt jenseits von irgendwelchen kleineren OpenSource Projekten scheint davon wenig bis nix wissen zu wollen... :wink:
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Test: Intel Xeon E3-1230 v5 (Skylake)

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/XEON-E3-1230V5/LOGO_XEON

Vor ein paar Tagen stellte Intel die Xeon-Prozessoren mit Sockel 1151 aus der Skylake-Familie vor. Diese sind hauptsächlich für den Workstation- und Entry-Level-Server-Bereich gedacht, die Vorgänger-CPUs fanden sich aber auch in vielen PCs unserer Leser wieder. Der Clou der Prozessoren ist das... [mehr]

Skylake richtig einstellen: Was man machen sollte, was man lassen sollte

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/XEON-E3-1230V5/LOGO_XEON

Intels Skylake-Chips wurden vor nunmehr vier Monate vorgestellt und sind leider immer noch nur spärlich verfügbar. Nach unserem Test der Core i7-6700K- und Core i5-6600K-Prozessoren zum Launch haben wir uns bereits diverse Z170-Boards angesehen, die Mobilversionen getestet und sind aufs... [mehr]

Core i7-6950X im Test: Dicker Motor, alte Karosse

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/6950X/6950X-LOGO

Intels letzter CPU-Launch ist schon eine Weile her - Ende Oktober 2015 testeten wir den Xeon E5-1230v5 auf Skylake-Basis, seitdem war zumindest im Desktop-Bereich nichts neues mehr vom Marktführer zu hören. Am heutigen Tag aktualisiert Intel endlich die High-End-Plattform und bringt mit dem Core... [mehr]

Intel 'Kaby Lake': Die siebte Core-Generation im Detail vorgestellt

Logo von IMAGES/STORIES/LOGOS-2016/INTEL_7TH_CORE_GEN

Im Zuge der kommenden "Kaby Lake"-Plattform, deren breite Verfügbarkeit für das erste Quartal 2017 erwartet wird, nutzt Intel heute die Gelegenheit, die siebte Core-Generation offiziell im Detail vorzustellen und bereits ein paar Prozessoren auf den Markt zu bringen. Wir konnten uns bereits vor... [mehr]

So schnell ist Kaby Lake: Erste eigene Benchmarks zum i7-7500U

Logo von IMAGES/STORIES/REVIEW_TEASER/INTEL_KABY_LAKE

Offiziell vorgestellt hat Intel die 7. Generation der Core-Prozessoren bereits Ende August, doch erst jetzt ist Kaby Lake in Form des ersten Notebooks verfüg- und damit testbar. Dabei handelt es sich um das Medion Akoya S3409 MD60226, in dem ein Core i7-7500U verbaut wird. Während das Notebook... [mehr]

Delid Die Mate im Test

Logo von IMAGES/STORIES/IMAGES/STORIES/GALLERIES/REVIEWS/2016/DDM/DDM

Seit der Ivy-Bridge-Generation verlötet Intel Die und Heatspreader nicht mehr miteinander, was leider in deutlich schlechteren Kern-Temperaturen resultiert. Abhilfe dagegen schafft nur das Delidding (das sogenannte „Köpfen“) der CPU sowie der anschließende Austausch der Wärmeleitpaste durch... [mehr]