AMDs Semi-Custom Business Unit - Projekte, Partner und Chips

[BavarianRealist]

Die APUs mit "huma" stehen doch längst in der Leitung.
Ist es denn zu viel verlangt, sich noch ein paar Monate zu gedulden?

Ich bezweifle, dass Kaveri noch in 2013 kommt. Womöglich wird er erst zur CES im Januar 2014 präsentiert um dann im Frühjahr 2014 in Produkten aufzutauchen...

 

[FredD]

Dieser Thread handelt vordergründig über "Semi-Custom" Projekte, so die APUs für PS4 und XBox (gemeinsamer und kohärenter Speicher für GPU & CPU), welche durchaus 2013 noch das Licht des Tages erblicken sollten.
In welchem Fall auch immer, Kaveri oder NextGen-Spielkonsole, wäre es natürlich toll, wenn man schon in den Laden gehen und sich die Schachtel vom Regal ziehen könnte, und zwar jetzt gleich! Was ich ausdrücken wollte: so ein wenig Geduld vermittelt durchaus einen erwachsenen Eindruck. Gut, als Kind hatte ich auch kein Problem damit, eine ganze Hochzeitsgesellschaft in Aufruhr zu versetzen, weil ich mein Eis nicht bekam...
...macht uns das Internet wieder zu kleinen, ungeduldigen Quälgeistern, die sofort das Geplärre beginnen, wenn irgendetwas nicht in das Schema der unmittelbaren Bedürfnisbefriedigung passt? Und wies weiter geht seht ihr nach der nächsten Maus
.
EDIT :
.

Die Maßstäbe setzt auch mittlerweile hier zur Zeit Intel und deklassiert die Konkurrenz:
http://images.anandtech.com/graphs/graph6993/55300.png

Auch wenn es erstmal wie eine lahme Ausrede erscheinen mag, drängt sich von anderen Quellen der Verdacht auf, dass mit Luxmark noch Treiber/Software-Probleme bzgl. AMD Hardware bestehen. Insgesamt macht das OpenCL Benchmarking noch ein recht wackeliges Bild, insbesondere dann, wenn wie z.B. beim Winzip OpenCL Test des Core_i3217u durch Hinzunahme der iGPU eine Verschlechterung des reinen CPU-Ergebnisses auftritt.
http://techreport.com/review/24856/amd-a4-5000-kabini-apu-reviewed/6
Das soll keine Pauschalisierung sein ("jegliche OpenCL Software ist wacklig"), sondern lediglich darauf hinweisen, dass (1) analog zu Grafik-Treibern auch die durch GPU-Compute gezeigte Performance eine hohe Varianz bedingt durch das Vermögen der Software, die Hardware anzusprechen, aufweisen kann, daher (2) Einzelergebnisse nicht über-interpretiert werden sollten, und schließlich (3) noch einige Zeit verstreichen wird, bis die Software-Landschaft (im breiteren Sinne) auch auf diesen Ast aufsteigt. Zumindest die Richtung stimmt...

 

[mariahellwig]

Den Eindruck habe ich auch. Was wir zur Zeit sehen sind die ersten Erfahrungen die die Entwickler mit OpenCL gemacht haben. Da Intel mittlerweile auch auf diese Schnittstelle setzt, weil sie auf der x86 Ebene kaum noch Fortschritte machen, lässt hoffen dass auf allen Seiten mehr Energie in dieEntwicklung gesteckt wird. Auch Intel weiß, das sie ohne deutlichen Performancezuwachs auf Dauer ihre Margen nicht halten können.

Luxmark ist zur Zeit der meist verwendete OpenCL-Benchmark. Wenn es eine Unverträglichkeit gibt, hätte man bei AMD genügend Zeit gehabt für Abhilfe zu sorgen.

Ich habe manchmal den Eindruck AMD ist eine Spielwiese für Ingenieure die sich selbst verwirklichen wollen. Ob da irgendwann man fertige Produkte herauskommen scheint ihnen egal zu sein. Seit RR ist es etwas besser geworden.

 

[isigrim]

Luxmark ist zur Zeit der meist verwendete OpenCL-Benchmark. Wenn es eine Unverträglichkeit gibt, hätte man bei AMD genügend Zeit gehabt für Abhilfe zu sorgen.

Wozu? Dade arbeitet schon an Version 3 des Benchmarks. Version 2 basiert noch auf einigen Gehversuchen für SmallLuxGPU. Inzwischen hat sich da sehr viel bei den Features getan und auch was die Integration in LuxRender angeht.
Auf einen Benchmark zu optimieren ist mMn schlichtweg Kundenverarsche, auch wenn´s inzwischen allgemein üblich ist.

Die Frage ist: Was hat das hier zu suchen?

 

[FredD]

Die Frage ist: Was hat das hier zu suchen?

So ganz fehlplatziert ist der Hinweis auf die altbekannte Henne-Ei-Problematik nicht: AMD mag zwar mittlerweile tolle Eier legen, aber wenn die Temperaturen nicht stimmen (oder seitens AMD nur ungenügend dazu beigetragen wird, dass die Eier an eine warme Stelle gelegt werden) schlüpft da einfach zu wenig, oder zu zögerlich. Ein "Hier ist die Hardware, jetzt macht mal" ist da oftmals ungenügend. Gute Gegenbeispiele gibt es im Gaming-Bereich, leider aber nicht oder kaum aus der Linux-Ecke.

 

[isigrim]

AMD macht schon viel bei opencl. Und mit gcn hat sich viel getan.

Das Problem ist allerdings, dass einiges (Z.B. Blender cycles) noch Probleme macht.
Mit Linux rollt Intel momentan das Feld auf...

 

[sompe]

@FredD
Bei deinem Beispiel würde ich die Henne eher in ein Kühlhaus setzen und sie dort versuchen lassen das Ei auszubrüten.
Wenn die Umgebung nicht passt gehen zuerst die Eier und später die Henne selbst ein.
Das AMD mit seiner APU Strategie alles andere als falsch lag zeigen Intels Bemühungen im GPU Bereich. Es interessiert bei der Software Entwicklung nur kaum jemanden was sie im Angebot haben und um dem wirkungsvoll entgegen zu wirken fehlen ihnen vermutlich schlicht der Einfluss und die finanziellen Mittel.

Vermutlich ist sogar für AMDs Produktpalette Intels Haswell sowas wie ein Motor bei der Software Entwicklung, da er schlicht die gleichen leistungskritischen Ansatzpunkte besitzt. FMA, AVX, eine leistungsfähigere GPU...alles softwareseitige Schwachpunkte die bei Nutzung eine ordentliche Mehrleistung versprechen.

 

[FredD]

Es interessiert bei der Software Entwicklung nur kaum jemanden was sie im Angebot haben und um dem wirkungsvoll entgegen zu wirken fehlen ihnen vermutlich schlicht der Einfluss und die finanziellen Mittel.

Ja, das wären die idealen Brutvoraussetzungen. Haswell mit AVX2 geht dagegen schon eher in Richtung Kuckucksei.

 

[sompe]

Vielleicht kann sich diese Problematik ja mit den Custom Designs ändern und man ist eher bereit die Eigenschaften ihrer Designs zu nutzen. Ruf ist ebend alles.

 

[isigrim]

Phoronix meldet, dass die PS4 mit einem modifizierten Free BSD 9 läuft.

 

[Stryki]

Ja wie die PS3 schon ein Free BSD hatte, irgendwo hatten wir die Frage schon muss ich morgen mal suchen.

 

[Bobo_Oberon]

Phoronix meldet, dass die PS4 mit einem modifizierten Free BSD 9 läuft.

Ah ja - Danke!

MFG Bobo(2013)

 

[isigrim]

Xbitlabs hat die bilder der geöffneten xbox one gefunden, die ich schon im eröffnunspost gepostet hatte, und ne nutzlose story daraus gemacht.

Dabei wird ohne grundlage über verbrauch und kosten gesülzt. Klingt nach: mäh, wir machen amd schlecht. Kein wunder dass sich weder amd noch microsoft zu derartigem zeug äußern.

 

[LinuS]

Man kann den Bericht auch überbewerten...

 

[FredD]

Der Schuss "höhere Fläche gleich mehr Energieaufnahme und mehr Abwärme" geht schnell nach hinten los, wenn man sich über die anliegenden Taktfrequenzen nicht klar ist. Gut, Grün durfte mal heulen, jetzt indirekt über das Sprachrohl xbit auch Blau.

 

[isigrim]

Andrew Feldman hat sich bezüglich Semi-Custom-Chips für die großen Server-Betreiber geäußert. Gigaom: Forget servers; One day Facebook, Google and other web giants will make their own custom chips
Xbitlabs: AMD: Amazon, Facebook and Google Could Develop Their Own Server Chips

“This vast change in the cost and time to market opens the door for large CPU consumers (mega data center players) to collaborate with ARM CPU vendors – say by paying part of the cost of development – in return for including custom IP that advantages the Mega Data center owners software/offering. There are conversations underway on this topic with nearly every major megadata center player in the world. The mega data center owners are building warehouse scale computers. It is not surprising that they have ideas on custom IP that would advantage their own software and would like that IP embedded into a CPU – ARM makes this feasible by bringing down the cost and development time of CPU creation,”

Er sieht die Chance, dass durch die offene Struktur des ARM-Ökosystems deutlich mehr Third-Party IP in die Entwicklung einfließen wird, damit sich Firmen von anderen absetzen können.

Zu den großen Serverbetreibern dürfte nach Feldmans Aussage auch Geheimdienste zählen, wie hier erwähnt wird.
(von amdfanuwe im Prognose-thread gepostet. Danke dafür)

[...]and even what came out recently about the NSA and its operation that’s where our APUs shine.[...]

Data-Analyse und das Knacken von Verschlüsselungen ist ja tatsächlich etwas, wo APUs ziemlich brauchbar erscheinen.
Allerdings dürfte Intels Lobby in den USA zu stark sein, um AMD da ein großes Feld zu geben. Da werden wohl eher Xeon Phis für die Datenanalyse zum Einsatz kommen.

 

[BavarianRealist]

...und womöglich ist AMD der einzige, der neben den ARM-Cores auch noch kleine X86-Cores für die Custom APUs/SoC für Server anbietet. Da könnte sich vielleicht ein neuer Markt auftun, oder?

 

[Complicated]

Und was ich besonders interessant fand, war diese Info:

The high-ranking AMD executive estimated that one could build an entirely custom chip using the ARM architecture in about 18 months for about $30 million. By contrast, it takes three or four-year time frame and $300 million to $400 million in development costs required to build an x86-based server chip based on a new micro-architecture.

Das sind mal deultiche Anhaltspunkte wenn wir das nächste mal über Herstellungskosten und Releasezeiten spekulieren. Entsprechend schneller ist man auch mit günstigen Produkten in der Gewinnzone.

 

[Markus Everson]

Ich finde es auch immer wieder spannend wieviel ein Apfel im Verhältnis zu einer Birne kostet.

Aber wirklich interessant wäre es doch gewesen zu erfahren was ein 'entirely custom chip using the existing x86-based architecture' kostet und wieviel Zeit er benötigt. Jaguar wurde bekanntlich aus dem vorhandenen Bobcat entwickelt was den Vergleich der Kosten mit dem ARM-Chip nahelegen würde.

 

[unl34shed]

Seh ich auch so, Äpfel und Birnen:
Der ARM Core wird nur dazu gekauft und wohl nicht modifiziert. Das mit einem komplett neuen x86 zu vergleichen ist misst. Wenn dann müsste noch die Zeit von der Entwicklung des entsprechenden ARM Cores hinzu kommen. An den Kosten ändert das aber nichts, da die Lizenz gebühren an ARM relativ gering ausfallen sollten, die Entwicklungskosten werden ja von vielen Firmen getragen.

Würde AMD einen eigenen x86-Core entwickeln, dann nutzen ihn nur sie selbst und vllt. ein paar Custom-Designs. Preislich dürfte der x86 wohl teurer sein, aber von dem Zeitaufwand dürften sie sich nichts nehmen. Beim x86 dürfte der Vorteil bestehen, dass AMD ihn besser anpassen kann, weiß nicht ob sie am ARM was modifizieren.

 

[isigrim]

Die Frage ist, wie weit AMD kommt, wenn man nicht selber auch die ARM-Cores weiterentwickelt.
Man sieht derzeit wie gut sich Qualcomm eben deshalb schlägt, weil sie sich nicht darauf verlassen haben, dass ARM schon was ordentliches bieten wird.

Zwar dürfte big.LITTLE für die kommenden SoCs und die ARMv8-Kerne besser funktionieren als bisher und läuft dann auch assymetrisch, aber das ändert nichts daran, dass man sich auf Dauer in diesem Bereich wohl nur halten kann, wenn man auch bei den CPU-Kernen am Ball bleibt und nicht wartet, bis ARM entsprechende Designs fertig hat.
So ein GTS wäre für x86 auch endlich mal nett....müsste man mal sehen, ob der Linux-Scheduler das theoretisch auch für x86 kann. Bei Windows braucht man auf sowas ja eh nicht zu hoffen...

Aber der Vorteil für AMD bei dieser Strategie ist halt erstmal, dass der Risikofaktor sehr klein ist und das Ganze dennoch verspricht, bei wenig Investition hohe Gewinne abzuwerfen. Wenn das funktioniert, wird man da wohl auch investieren.

Eine andere Frage an die vielen Leute hier mit einem tieferen Verständnis für CPUs:
Inwiefern kann AMD sein Knowhow bzw. schon vorhandene Technologie nutzen, um High Performance-ARM Kerne zu bauen? Also wieviel muss man an einem aktuellen Bulldozer-Kern ändern, damit er als ARM-Chip taugt? Muss da nur ein anderer Dekoder davor?
Das wäre ja die Exit-Strategie schlechthin um aus der x86-Gletschespalte zu kommen. Gleichzeitig hätte man dann zukünftig die Möglichkeit, via dem oben erwähnten GTS sehr dicke Kerne mit den kleinen, einfach zu lizensierenden ARM-Kernen zu kombinieren und so sehr flexible CPUs/APUs zu bauen.

 

[Crashtest]

Wer sagt, dass man bigLittle auf x86 vergessen kann ? AMD soll bereits seit 2Jahren mit Microsoft dran basteln (Bobcat & Orochi) ....

 

[miriquidi]

Inwiefern kann AMD sein Knowhow bzw. schon vorhandene Technologie nutzen, um High Performance-ARM Kerne zu bauen? Also wieviel muss man an einem aktuellen Bulldozer-Kern ändern, damit er als ARM-Chip taugt? Muss da nur ein anderer Dekoder davor?

ARM ist ja eigentlich schon RISC-Befehlssatz, während der x86-Befehlssatz in den Dekodern in etwas RISC-ähnliches (µOps) umgewandelt wird. Also einen Dekoder vor der x86-Dekoder zu schalten wäre dumm, aber vielleicht daneben? Nur muss man dann auch die x86-Dekoder entsprechend umgestalten.

Ein spezielles Problem beim Bulldozer bzw. allen 'großen' x86er Kernen (Core, K8, K10, BD) ist die immense Fläche. Allein den Kern an die Spannung zu schalten (ohne dass Software drauf läuft), erzeugt mehr Verlustleistung, als so manche kleinen ARM-Kerne beim Rechnen unter Vollast brauchen. Man hätte dann nur etwas was langsamer als ein Intel Atom ist, aber viel Strom verbraucht.

 

[isigrim]

Mit "davor" meinte ich schon statt des x86-Dekoders.
Wie verhält sich denn der interne RISC-Prozessor bei Bulli oder anderen dicken x86-Przessoren hinter dem x86-Dekoder im Verhältnis zu ARMs RISC? Kann da jemand was dazu sagen?

 

[tex_]

Standard Befehle wie Add liesen sich denke ich noch einfach übernehmen, aber in x86 gibt es mittlerweile ja auch viele Funktionen die vom ARM Befehlsatz gar nicht ausgenutzt werden können. Als einfaches Beispiel mal AVX und FMA die dann unnötig viel Fläche brauchen. Auch die Verwendung der Register stelle ich mir Problematisch vor, da diese ja teils feste Funktionen haben.
Und ob mit x86 auch wirklich alle ARM Befehle abgedeckt sind wage ich auch erst mal zu bezweifeln. Mein Assemblerkenntnisse sind da leider aber auch stark begrenzt...
Den ganzen Instruktionsfetch müsste man vermutlich aber auch erst noch optimieren und da die Sprungvorhersage ebenfalls vor den Dekodern sitzt wären dort Anpassungen wahrscheinlich auch nötig.

In einem synthetisierbaren Design wären aber die Änderungen vermutlich noch deutlich weniger aufwändig als ein komplettes ARM-Neudesign. Ob die ganze Grundlage bei ARM aber noch Sinn macht ist eine andere Frage.