Carrizo - volles HSA, UVD6/VCE3.1/ACP2, HDMI 2.0 - und: SOC, aber immernoch DDR3?

[nazgul99]

Hiermit sei der Carrizo-Speku-Thread eröffnet
An dieser Stelle sei alles spekuliert, was die komplette APU inkl. GPU und HSA angeht, für die CPU-Kern-Architektur gibt's hier nen Excavator-Thread.


Computerbase hat hier eine angebliche AMD-Folie gepostet, welche Carrizos Features und Verbesserungen zusammenfasst:

Dass Carrizo das erste wirklich vollständige HSA-Design werden soll (was genau Kaveri noch fehlt, mag sicher jemand raussuchen, es gab mal Folien mit Jahreszahlen und den dann jeweils abzuschließenden Implementationsschritten). Interessant finde ich vor allem folgendes:

• Es wird ein SOC
• UVD6: 9-18x 1080p h.264 30fps Decodierung (=270-540fps?)
• VCE3.1: 9x 30fps 1080p h.264 Encodierung (=270 fps?)
• Leider von h.265 (noch?) nix zu lesen
• Leider keine Angaben zu Qualitätsverbesserungen beim Encodieren
• Audio Co-Prozessor ACP2, was auch immer daran besser wird
• Immernoch DDR3
• Display Controller DCE11 mit HDMI 2.0 (bis zu 3 Kanäle)
• Da SOC: PCIe 3.0 für Grafik nur noch 8x, sonstiges 4x
• Wireless Display (Miracast, kann Kaveri das schon?)
• Connected Standby, die andren Punkte dahinter sagen mir nix: STAPM, PPT/TDC/EDC tracking, BBB
• Wg. SOC auch hier nur noch 2 integrierte SATA-Ports
• Nur vom Lötsockel (BGA) die Rede, TDPs 12-35 Watt

STAPM oder die folgenden Kürzel könnten auf die im CPU-Träger integrierten Power-Regulatoren zutreffen, ich glaub bei Heise gab's mal ne Meldung, dass AMD hier Intels Beispiel folgen will. Das gibt vor allem die Möglichkeit für sehr niedrige (Connected) Standby- und Lowpower-Leistungsaufnahmen. Connected Standby könnte wie bei Mullins auch mittels eines integrierten ARM-Cores erledigt werden.

Ach ja, ~30% Performance-Verbesserung bei 15 Watt sind angesagt, wobei es nach meinem Wissensstand gar keine 15W-Kaveri gibt (die schnellsten haben 19 Watt). Ob damit die CPU-Kerne oder die Gesamtleistung inkl. GPU-Shader gemeint ist, bleibt unklar. Man darf tippen, dass AMD bei ner APU die Gesamtleistung inkl. GPU meint. FredD (wie oft soll ich denn noch danke sagen? ) hat recht, da steht klar, dass von den Excavator- (XV-)Kernen die Rede ist.

Ich finde das Paket insgesamt sehr gelungen, zumindest wenn man auf den Mobilsektor schaut. Ich begrüße die Ausführung als SOC! Klassische Desktop-Kunden dürften eher enttäuscht sein ob der beschnittenenen PCIe- und SATA-Lanes. DDR4 wäre natürlich ebenfalls wünschenswert, auch für's Notebook. Dass es ein separates Die für Desktops geben wird, halte ich für sehr unwahrscheinlich.

 

[Atombossler]

Hiermit sei der Carrizo-Speku-Thread eröffnet


Ach ja, ~30% Performance-Verbesserung bei 15 Watt sind angesagt, wobei es nach meinem Wissensstand gar keine 15W-Kaveri gibt (die schnellsten haben 19 Watt).

Marketingrechnung: 15% bessere Performance der Cores + 4Watt weniger Verbrauch, fertig sind die 30% Leistungsplus.

Ich finde das Paket insgesamt sehr gelungen, zumindest wenn man auf den Mobilsektor schaut. Ich begrüße die Ausführung als SOC! Klassische Desktop-Kunden dürften eher enttäuscht sein ob der beschnittenenen PCIe- und SATA-Lanes.

Die sollte eigentlich der Chipsatz übernehmen und die entsprechenden Teile im SOC deaktiviert sein.
So ist das wohl angedacht.

DDR4 wäre natürlich ebenfalls wünschenswert, auch für's Notebook. Dass es ein separates Die für Desktops geben wird, halte ich für sehr unwahrscheinlich.

 

[hoschi_tux]

Ich weiß nicht was ich von dem halbierten L2 Cache halten soll..
Steamroller hat ggü. Richland 50% Cachebandbreite dazugewonnen und jetzt wird Carrizo wieder beschnitten?
Wie ist der Cache jeweils getaktet? Ganzer oder halber CPU Takt?
Dazu gibts auch nur eine PCIe3 x8 Anbindung für dGPU.
Entweder das sind wirklich beschnittene Laptopmodelle, optimiert für wenig Energieverbrauch (halber Cache etc. pp.), oder Excavator wird im Vergleich zu Steamroller keine Butter vom Brot ziehen.

 

[ONH]

Oder was viel wahrscheinlicher ist, die Folie ist ein Fake, alleine die DDR3 Blöcke sprechen dafür.

Dazu kommt noch der unlogische Versionssprung der uvd, ich würde das ganze nicht umbedingt für voll nehmen.

Dennoch danke für den Carrizo Thread nun wird der xv thread hoffentlich nicht mehr mit nit cpu sachen vollgespamt.

 

[nazgul99]

ONH, da ist was dran. Hab mich auch schon über UVD3 -> UVD6 gewundert, aber letztlich kann da auch irgend ein Marketing-Unsinn dahinter stecken.

Atombossler, ein SOC, der für den Desktop-Gebrauch teil-deaktiviert wird und diese Teile werden dann aufgebohrt in nem FCH zur Verfügung gestellt? Hmm ... Aber man würde trotzdem deutlich mehr PCIe-Lanes benötigen, um über den Chipsatz dann eben so viele zur Verfügung stellen zu können. Gut, man könnte die Leitungen der SATA-Ports umnutzen und vielleicht noch ein paar andre, aber ich hab zumindest meine Zweifel, dass da genügend zusammenkomen. Aber denkbar ist es.

 

[Ge0rgy]

Wieso wird hier wieder Größe mit Bandbreite zusammengeworfen? - Man kann auch den halben Cache z.B. mit doppeltem Takt betreiben...
Die Jaguar haben doch AFAIK auch shared L2 Caches. - Wobei sich hier wiederum die Frage stellt ob das ein generelles Architekturmerkmal von Excavator wird oder ein Spezialfall der Implementation als Carizzo.
Insgesamt klingen die Erweiterungen erstmal interessant. Was genau als "Full HSA" gemeint ist, weiß ich allerdings auch nicht. Offiziell galt doch schon Kaveri als "die HSA-APU".
Dass der 15W - Bereich ausgebaut wird, ist nur konsequent angesichts des Rückzugs aus der Highend-Battle mit Intel. Wobei 15W mir relativ wenig vorkommen, das ist doch schon fast Katzen-Territorium, also Jaguar/Puma basierende APUs, egal ob man nun Kabini, Beema o.ä. anführt.
Das aller, aller wichtigste wird sein dass AMD zeitnah liefern kann und dass sie es endlich schaffen die APUs in kaufbare Produkte abseits der Rentner-Netbooks mit 17-Zoll Display (kann man bei 1024x768 auch ohne Brille bedienen) unterzubringen.
Ich meine, selbst Kaveri ist schon ein recht guter Allrounder, die kleinen APUs lassen die ATOMs alt aussehen... und dennoch findet man kaum ein brauchbares Produkt im Handel. In Deutschland schon garnicht. Komischerweise geht sowas in Polen und Nachbarländern. Das hat nichts mehr mit Produktpolitik zu tun sondern ist schlichte Wettbewerbsverzerrung wenn man mich fragt.
Alles in Allem, ein inkrementelles Update für die Kaveris. Nungut. War ja so zu erwarten.
Dass DDR4 noch nicht kommt, ist auch irgendwie naheliegend, das dürfte preislich in der Klasse noch nicht wirklich passend sein. - vielleicht gibts dann später nen Refresh mit DDR4-Controller.

 

[FredD]

Dass Carrizo das erste wirklich vollständige HSA-Design werden soll (was genau Kaveri noch fehlt, mag sicher jemand raussuchen, es gab mal Folien mit Jahreszahlen und den dann jeweils abzuschließenden Implementationsschritten).

Steht doch alles auf den Folien
Graphics Preemption und (GPU Compute) Context Switch, siehe auch http://en.wikipedia.org/wiki/Preemption_(computing)

Abseits ausschweifiger Marketing-Sprechblasen, z.B.

Spoiler

GPU compute context switch and GPU graphics pre-emption:
GPU tasks can be context switched, making the GPU in the APU a multi-tasker. Context switching means faster application, graphics and compute interoperation. Users get a snappier, more interactive experience. As UI's are becoming increasing more touch focused, it is critical for applications trying to respond to touch input to get access to the GPU with the lowest latency possible to give users immediate feedback on their interactions. With context switching and pre-emption, time criticality is added to the tasks assigned to the processors. Direct access to the hardware for multi-users or multiple applications are either prioritized or equalized

Interview mit Manju Hedge

gibt es auch ein paar handfeste Informationen dazu, z.B.:

http://rtos.com/images/uploads/Preemption_Threshold.pdf

oder

Spoiler

1 What is the difference between "preemption" and "context switch" ?

Preemption is the act of interrupting a process without its involvement. In this context, that probably means a timer interrupt will fire. The word comes from a legal concept of preemption: the act or right of claiming or purchasing before or in preference to others. For your purposes, that means that when the timer interrupt fires, that the interrupt service routine (ISR) has preference over the code which was previously running. This doesn't necessarily need to involve a kernel at all; you can have code running in any ISR which will run preemptively.

A context switch is what happens when the OS code (running preemptively) alters the state of the processor (the registers, mode, and stack) between one process or thread's context and another. The state of the processor may be at a certain line of code in a one thread. It will have temporary data in registers, a stack pointer at a certain region of memory, and other state information. A preemptive OS can store this state (either to static memory or onto the processes' stack) and load the state of a previous process. This is known as a context switch.

2 What are the key differences between a preemptive and nonpreemptive kernel ? What all work is required from a programmer to make the kernel preemptive ?

In a preemptive kernel, an interrupt can fire in between any two assembly instructions (known as 'sequence points'). In a non-preemptive kernel, the running process must call a yield() function to allow the other threads to run. Preemptive kernels are more complex, but provide a better illusion of concurrency. Non-premptive kernels can be done very simply with setjmp.h, but each thread must regularly call yield() or the other threads will not run.

When a function like yield() is called, the state of the processor is stored automatically. When you want to make your OS preemptive, you must store this information manually.

http://stackoverflow.com/questions/11602395/difference-between-preemption-and-context-switch

oder hier noch das passende Patent:
http://www.google.com/patents/US20120194524

 

[Ge0rgy]

War das nicht schon ein Compute-Feature von GCN an sich? - oder bin ich da aufm falschen Dampfer. Ich war der Meinung dass schon die GCN-Karten unter anderem mit besserer GPGPU-Eignung durch eben jene Context-switching Fähigkeit beworben wurden. Also wäre das ja nicht wirklich neu - Kaveri hat ja auch schon GCN GPU-Teile

 

[nazgul99]

Ge0rgy, FredD (danke!), ich suchte nach der entsprechenden Folie und hab eine Variante davon (es gab verschiednene) hier gefunden:

Da steht zwar 2014, aber Kaveri war ja auch für (Anfang, Mitte, Ende ...) 2013 angekündigt. Was auf der Folie unter "2014" steht, müsste dann Carrizo sein. Trotzdem danke

---------- Beitrag hinzugefügt um 13:21 ---------- Vorheriger Beitrag um 13:18 ----------

Das wären dann: 2011: Llano, 2012: Trinity & Richland, 2013: Kaveri, 2014: Carrizo.

Dass Kaveri noch nicht die volle geplante Ausbaustufe sein würde, war mir jedenfalls (u.a. durch diese, immer wieder leicht variierte, Folie) bekannt.

 

[gruffi]

Ach ja, ~30% Performance-Verbesserung bei 15 Watt sind angesagt, wobei es nach meinem Wissensstand gar keine 15W-Kaveri gibt (die schnellsten haben 19 Watt). Ob damit die CPU-Kerne oder die Gesamtleitung inkl. GPU-Shader gemeint ist, bleibt unklar.

Naja, die schreiben es ja explizit bei CPU hin. Also wird's wohl auch für die CPU gelten. Allerdings müsste man auch wissen, wie es bei 45W oder 65W ausschaut. Ansonsten lässt sich die Zahl schlecht einordnen. Bei kleineren TDPs kann man viel durch die Einsparung von ein paar Watt gewinnen.


Ansonsten fällt der halbierte L2 auf. Vielleicht ein Ergebnis der Jaguar/Puma+ Architektur? Die kommt ja auch lediglich mit 2 MB L2 daher. Allerdings mit Halbtakt, um Energie zu sparen. Wollen wir hoffen, dass Carrizo seine TDP auch mit vollem L2 Takt erreicht. Für singlethreaded Workloads sollte die Cachegrösse eh keine allzu grosse Auswirkungen haben. Da sind selbst 2 MB noch ordentlich. Anders schaut es allerdings bei Volllast auf allen Kernen aus. Dann stehen pro Thread nur noch 0,5 MB Cache zur Verfügung. Das gab es das letzte mal abseits der Cat Architektur vor 5 Jahren bei Propus. Der sich trotzdem recht gut schlug und im Schnitt maximal messbar hinter Deneb lag. In einigen Cache intensiven Szenarien allerdings klare Performancenachteile hatte.

 

[FredD]

Auf der ersten Seite des Kaveri Threads ist noch die Ur-Variante dieser Fole (FSA-Roadmap): http://cdn.overclock.net/0/04/600x385px-LL-04c21593_hsa.png zu finden.

Wir dürfen in diesem Zusammenhang auch auf den letzten Punkt gespannt sein "Extend to discrete GPU". Wenn sich das gut zusammenreimt, könnten die kommenden GPUs (Tonga und wie sie alle heißen) dann regelrecht als verlängerter Arm der (voll-HSA-fähigen) APU arbeiten, in der Art und Weise feinkörniger und vom Umfang weit über das bisher bekannte Spektrum von Switchable Graphics / Enduro und hybrid Crossfire hinaus.

 

[hot]

Der L2-Cache ist sicherlich aus performancegründen halbiert. Der wird dafür einfach deutlich schneller sein. Interessant wär viel mehr der L1D$.
AMD hat sich da ne ganz schöne eierlegende Wollmilchsau zusammengebaut.

 

[isigrim]

Der Vergleich 15 Watt mit Kaveri hinkt doppelt, weil der 17 Watt Kaveri ja auch noch einen nicht so sparsamen FCH mitschleppt, während der bei Carrizo integriert ist. Dafür bräuchte man zum Vergleich wahrscheinlich einen 10 Watt Kaveri.
@nazgul
Danke für´s Zusammenschreiben!

 

[nazgul99]

Gern geschehen isigrim

Golem berichtet ebenfallsund verweist am Ende auf etwas, das ich übersehen habe:

Wie bereits berichtet, wird Carrizo auch als Desktop-APU für den Sockel FM2+ erscheinen.

Wenn AMD die Pläne entgegen den Ankündigungen für Sockel FM2+ nicht doch wieder ändert, müsste Carrizo also tatsächlich auch mit einer Southbridge genutzt werden können. Falls das mit dem OSC für Notebooks stimmt, würde ich am ehesten tipen, dass einige Lötpads des Dies je nach Konfiguration entweder oder für z.B. SATA oder PCIe nutzen lassen. Gegeben hat es sowas ja schon. Gäbe es keine Doppelnutzung, müsste Platz für die zusätzlichen Lötpads verschwendet werden. Ein zweites die für den Desktop halte ich nach wie vor für sehr unwahrscheinlich.

---------- Beitrag hinzugefügt um 20:10 ---------- Vorheriger Beitrag um 20:03 ----------

Im SA-Forum hat noch jemand diese Folie gepostet:

Da steht ebenfalls DDR3 ... Die Folie bezieht sich auf den Desktop, also ist natürlich auch FM2+ µPGA angegeben. DDR3 ist mit diesem Sockel natürlich auch zwingend.

 

[Ge0rgy]

Interessanterweise steht da sowohl bei Kaveri als auch bei Carizzo "Full HSA programming model"

 

[nazgul99]

Dachte mir, dass das kommt Dass das Programmiermodell bei beiden gleich sei, bedeutet ja nicht unbedingt, dass die Hardware-Features bezüglich HSA es auch sind.

 

[FredD]

Ein weiteres (und wie ich meine sogar wichtigeres) Patent, um GPU Context Switches zu optimieren, wurde erst diesen Juni veröffentlicht (beantragt Nov. 2012). Wie wir aus dem Thread zu Compiler- und Software entnehmen können, nehmen Context Switches samt Preemption mal gerne mehrere Hunderte, wenn nicht sogar im Bereich von 1000 CPU Zyklen in Anspruch. Strategien zu finden, den Overhead zu reduzieren, aber auch benötigte Context Switches zu minimieren (siehe verlinktes Dokument von rtos), ist da ein ziemlich wichtiger Beitrag auf dem Weg zu heterogenem Computing.

http://www.google.com/patents/US20140157287

oder hier noch das passende Patent:
http://www.google.com/patents/US20120194524

 

[Ge0rgy]

Wobei hier angemerkt sei, dass die angenommenen 1000 Takte nur eine Seite der Medallie sind und auch stark Architekturabhängig, viel schwerwiegender ist in der Praxis wohl das Phänomen, dass diverse caches bzw. cachezeilen bei jedem Contextwechsel "ungültig" werden, genau wie Daten durchs Prefetching, sogar die Sprungvorhersage muss komplett von vorne anfangen.
GPUs sind anders aufgebaut was cache-Hierarchien betrifft, sowie meistens deutlich neidriger getaktet als CPUs. Das muss alles betrachtet werden. Trotzdem sit natürlich die grundsätzliche Fähigkeit begrüßenswert und jede Optimierung willkommen.
Auch in Hinblick auf heterogeneous queueing oder wie man das schreibt. Also das gegenseitige "zuschieben" von Arbeit zwischen CPU und GPU.

 

[tomturbo]

Naja so schlimm kann ein Contextswitch nun auch wieder nicht sein, denn unser Boot zum Beispiel hat eine durchschnittliche Contextswitch-Rate von 1600/sek über den Tag gerechnet. Unsere CPUs sind zwar gut ausgelastet aber so schlimm kann es nicht sein denn immerhin geht noch was am Server.

 

[Ge0rgy]

"Schlimm" ist relativ. 1000 Takte sind im Zeitalter der Gigahertz-Prozessoren keine besonders lange Zeit, ich meine, ein einzelner Takt dauert grade eine Nanosekunde bei 1Ghz. Das bedeutet wenn ein Contextswitch grob mit 100 Takten veranschlagt wird, sind wir immernoch bei einer Mikrosekunde. das bdeutet 1000 Kontextwechsel in einer millisekunde und 1 mio in einer Sekunde. Theoretisch möglich.
Wenn du nun aber betrachtest, dass selbst teure Maschinenoperationen wie Divisionen usw. meistens (deutlich) unter 50 Takten brauchen, von Additionen, Multiplikationen etc. die quasi in einem Takt durchgehen mal ganz zu schweigen, dann ist 1000 Takte ausgesprochen teuer.
Mit Features wie den tagged TLBs und dergleichen ist das auch inzwischen ein wenig besser geworden, weil der Prozessor nicht mehr bei jedem Kontextwechsel sämtlichen Bezug zu den alten Daten verliert (TLB-Flush würde bedeuten er wüsste nach dem zurückwechseln zum alten Tread alle Speicheroffsets neu berechnen)
Es ist also nicht so als wäre da nicht Arbeit investiert worden. Dennoch können zu viele Threadwechsel tatsächlich negativ auf die Performance schlagen, wenn man alle Effekte, wie die berüchtige "cache Pollution" mit einrechnet. Davon dass die Pipeline komplett leerlaufen muss etc. mal ganz zu schweigen.
Also wie soll ich das am besten ausdrücken. Technisch gesehen eine ziemlich teure Operation, die inzwischen allerdings durch Moores Law soweit entschärft wurde dass es praktisch keine allzu große Rolle spielt.
Der springede Punkt ist aber, dass tehoretisch jeder weitere Kern das Problem auf mehrfache Weise lindert. Nicht wegen der 1000 Takte in denen die CPU nichts sinnvolles rechnet. Ich behaupte bei modernen Prozessoren ist der roh-Befehlsdurchsatz der Pipeline eh in den meisten Fällen zweitrangig, viel heftiger schlagen Wartezeiten ins Kontor, bis der lahme Arbeitsspeicher endlich die Daten anliefert etc. - und genau das muss er wenns dumm läuft nach einem Contextswitch, weil die Daten im Cache inzwischen vom neuen Thread überschrieben wurden und alles nach dem zurückwechseln neu geholt werden müssen.
Das ist hier allerdings halbwegs OT.

 

[Atombossler]

Post Carrizo Ära:
amd-mit-stacked-memory-und-pim-bei-zukunfts-apus

 

[WindHund]

Post Carrizo Ära:
amd-mit-stacked-memory-und-pim-bei-zukunfts-apus

Ave Cesar!
Lustig zu wissen, die Italiener haben .it als Endung.

 

[ndrs]

Bei der ganzen Kotext-Switching-Geschichte wäre noch wichtig zu wissen, wie die Scheduling-Intervalle der Betriebssysteme sind. Bei unseren Versuchen, einige Low-Power-ARM-Boards (Panda-Board usw.) mit Linux als Real-Time-Maschinen zu nutzen habe ich noch irgendwas mit 125µs in Erinnerung. Erst mit dieser Angabe kann man ja beurteilen, wie oft so ein Kontextswitch passiert und damit, wie teuer die benötigte Zeit tatsächlich ist.

 

[Ge0rgy]

Die Contextwechsel-Diskussion haben wir in den Software-Thread verlagert

 

[ndrs]

Wo? Ich find's nicht