3DCenter Forum - AMD - Kabini - 28nm Low-End-APU mit bis zu 4 Kernen Jaguar-Kernen - FS1b Pin-Sockel H1/14

M4xw0lf · 2013-05-23, 10:39:07

Ich hab immer noch keine Ahnung was die ACEs tun. Was tun sie?

Locuza · 2013-05-23, 10:57:50

Da könnte Gipsel das auf Deutsch genauer erklären.
Wenn es technisch wird und dann noch auf Englisch verfasst ist, versteht man als Laie ja wenig.

Soweit ich das verstanden habe können sie Compute-Workload an die Shader-Arrays weiterleiten.
Der Command-Processor nimmt global alle Befehle entgegen, ob für Grafik-Berechnungen oder für Compute-Berechnungen.
Die ACEs sind im Grunde abgespeckte Command-Prozessoren, welche nur für Compute zuständig sind. ( Der Command-Processor besteht glaube ich selber aus zwei Teilen, dem GFX-Command-Processor und den Compute-Command-Processor)
Somit ist es z.B. möglich eine feste Anzahl der CUs für Compute festzulegen und gleichzeitig auf anderen CUs Grafik zu berechnen.
Ohne ACEs muss alles durch den Command-Processor gelöst werden.
Ich habe auch irgendetwas gelesen, dass man die GFX-Pipeline pausieren sollte, um möglichst maximalen Compute-Durchsatz zu erhalten.
Mit den ACEs wäre parallel beides möglich, Grafik und Computing gleichzeitig betreiben ohne das sich irgendetwas gegenseitig in die Quere kommt.
Da in dem Fall getrennte Manager für getrennte Arbeitsgruppen existieren.
HyperQ von Nvidia soll so ähnlich funktionieren.

Was mich aber wundert, eine CU ist ja ein Verbund aus 4 SIMDs, je 16 ALUs.
Jede SIMD setzt eine Wavefront (Arbeitspaket, 64 Threads) ab und braucht dafür 4 Takte.
Mit einer ACE können selbstständig Compute-Wavefronts verschickt werden.
Jetzt verstehe ich nicht so ganz, aus was eine Queue genau besteht?
Jede ACE kann bei Sea Island 8 Queues verschicken, wie wird das an die CUs/SIMDs gereicht?
Wird hier flexibel an SIMDs verschickt oder feste Pakete an eine CU für 4 SIMDs?
Da steht auch irgendetwas von 8 Stück können maximal gleichzeitig aktiv sein.
Also von 4x8 = 32 Queues darf ich mich nur für 8 Stück entscheiden?
Ich frage mich halt, ob 4 ACEs für 128-ALUs bei Kabini nicht oversized sind?
GCN1 hat 2 ACEs mit je einer Queue.
Das macht es gerade als Laien kaum möglich zu verstehen, wo die richtige Balance einzuschätzen wäre.

robbitop · 2013-05-23, 11:01:46

Hm GCN bringt Takt- und Einheitenbereinigt nur knappe 10 % mehr Leistung im Kabini. Ich vermute mal, dass das an der Bandbreitenlimitierung liegen könnte (Single Channel 64 bit).

Gipsel · 2013-05-23, 17:57:16

Es ist nicht nur die Speicherbandbreite. Da die TMU- und ROP-Anzahl nicht gestiegen ist (die Geometrierate ebenso wenig), unterschätzt man mit einer Normierung auf die ALU-Anzahl den GCN-Vorteil. Bei Brazos kam auf 10 ALUs (2 VLIW-Gruppen) eine TMU oder auf 20 ALUs (4 VLIW-Gruppen) eine ROP-Einheit. Bei Temash/Kabini kommen auf 16 ALUs eine TMU bzw. auf 32 ALUs ein ROP.
Normierst Du die Leistung auf die ALU-Anzahl (und Takt), erreicht Kabini dann knapp 10% höhere Leistung/ALU mit 37,5% weniger TMUs, ROPs und Setup-/Rasterleistung. Die Leistung pro TMU, pro ROP oder pro Rasterleistung ist also offenbar um gute 70% gestiegen.

=======================
Edit: Zu den ACEs

Wenn ein Programm Kommandos an die GPU absetzt, also z.B. zur Ausführung eines Kernels aber auch zum Kopieren von Daten über PCIe oder was auch immer, dann landen die zuerst in einer Art Warteschlange (englisch Queue, das ist ein FIFO oder auch Ringbuffer [ein Ringbuffer ist eine beliebte Möglichkeit, einen FIFO zu bauen, die Bezeichnung ist also hier austauschbar]). Meist sind die Kernel ja von irgendwelchen vorher auszuführenden Aktionen abhängig (z.B. ein anderer Kernel der Daten schreibt, die mein Kernel benutzen will oder ein Buffer muß erst noch in den VRAM kopiert werden). Quetscht man jetzt alles in eine Queue, dann bekommt man schnell Probleme, wenn mehrere Programme gleichzeitig auf die GPU zugreifen wollen (oder auch ein Programm mehrere verschiedene Dinge gleichzeitig machen will). Außerdem kann ein Task, der z.B. noch auf das Kopieren von einem Buffer wartet, einen später abgesetzten, für den schon alles bereit ist, aufhalten. Hier bietet es sich an, mehrere Warteschlangen (die sich von der API-Seite, also von der Software her einrichten lassen) auch in Hardware auf unterschiedliche Queues zu legen (und nicht alles in eine Hardware-Queue zu quetschen). Damit kommen sich die dann nicht mehr so in die Quere und mehrere Anwendungen können parallel auf die GPU zugreifen, ohne das es zu künstlichen und unnötigen Blockierungen kommt. Trotzdem können auch zwischen Kerneln in unterschiedlichen Queues immer noch Abhängigkeiten festgelegt werden, die einzelnen Queues können also zum Zwecke der Synchronisation auch miteinander kommunizieren, falls das nötig ist (auch über die ACEs hinweg, nicht nur in einer ACE).

NVidia vermarktet so ein Feature im GK110 (die kleineren können es nicht, die haben nur genau eine Queue) übrigens unter dem Namen "HyperQ" (maximal 32 Queues). AMD bietet mit allen Southern-Islands-GPUs im Prinzip 3 Queues: den Command-Prozessor (der die Queue für Grafik-Kommandos sowie für Compute-Shader/Kernel enthält) und die beiden in den ACEs (eine ACE ist ein abgespeckter Command-Prozessor, der nur Compute-Queues verwalten kann, keine für Grafik). Die ACEs enthalten alles, was zum Verwalten der Queues und Abarbeiten von Compute notwendig ist. Mit mehreren ACEs (also allen SI-GPUs) wird deswegen auch eine Art statische Aufteilung der GPU unterstützt, was OpenCL seit 1.2 (unter 1.1 gab es das bereits als Extension) als sogenanntes "device fission" oder "device partitioning" unterstützt (zumindest prinzipiell, AMDs OpenCL-Treiber kann es noch nicht, so daß das bisher nur auf CPUs nutzbar ist; dort kann man z.B. eine 8 Kern-CPU in 2 Subdevices mit je 4 Kernen aufteilen oder auch 2+6 oder wie man gerade lustig ist). Man kann sich also mit dieser Aufteilung mehrere logische GPUs (also OpenCL devices, das können ja auch CPUs sein) "erzeugen", die sich komplett wie unabhängige GPUs (devices) verhalten. Die Aufteilung der Rechenleistung kann man dabei auf verschiedene Art und Weise festlegen (z.B. einfach durch Angabe der Anzahl der CUs oder man teilt in gleich große Teile). Die Kernel, die man an einso erzeugtes Subdevice schickt, werden dann nicht mehr auf der ganzen GPU ausgeführt, sondern nur noch auf den zum Subdevice gehörenden CUs. Man betreibt damit also einen statischen Split, während ohne Device Fission (also nur mehrere Queues benutzt) die Hardware selbst dynamisch festlegt, wie die Kernel auf die komplette Hardware verteilt werden (GCN unterstützt dazu prinzipiell das Vergeben von Prioritäten, aber da kommt man bisher auch noch nicht dran). Man kann maximal so viele Subdevices erzeugen, wie es ACEs gibt (man kann also keinen ACE aufteilen).

Mit "GCN1.1"/C.I. wird diese Fähigkeit jetzt aufgebohrt. Ein zwischenzeitlich mal auf der AMD-Seite verfügbares Manual dazu sprach von 8 Queues pro ACE und bis zu 8 ACEs pro GPU (also dann 64 Compute-Queues). Dies ist genau das, was wir bei Kabini sehen, eben nur mit 4 ACEs (und damit bis zu 32 Queues, genau wie GK110). Die PS4 (ist ja auch eine etwas größere GPU mit 18 CUs statt Kabinis 2 CUs) hat dann den vollen Satz von 8 ACEs und 64 Queues, die man dann auch für die etwas größeren diskreten GPUs der nächsten Generation erwarten kann (die PS4 hat allerdings auch zwei Grafik-Command-Prozessoren: einen "normalen" mit Grafik+Compute-Queue wie man das kennt und dann noch einen "high priority/VSHELL" Command-Prozessor, der nur Grafik- aber keine Compute-Kommandos annehmen kann und offenbar für das Betriebssystem reserviert ist; die Abarbeitung der Kommandos dort hat Vorrang vor dem vom Spiel genutzen Command-Prozessor).

Locuza · 2013-05-23, 19:41:13

Und wie sieht das mit den 8 maximal aktiven Queues aus?
Wenn es bei Kabini 4 ACEs gibt, dann kann ich z.B. von

ACE 0 2 Queues verschicken.
ACE 1 1 Queues ...
ACE 2 3 Queues ...
ACE 3 2 Queue ...

oder z.B. auch

ACE 0 8 Queues
ACE 1 0
.
.
.

?

Und jetzt zu einer weiteren Frage. Sind 4 ACEs mit 32 Queues nicht oversized für 2 CUs, 8 SIMDs und 128 ALUs?

VooDoo7mx · 2013-05-23, 19:52:22

Unglaublich 1,5GHz Quadcore gewinnt gegen 2 Jahre alten Intel 1,1GHz Dual Core wo künstlich nochmal massiv Cache, HT und so gut wie alle Features beschnitten sind.
Das ist doch mal nen Freundentanz wert für die Fanboys.

Dafür ist beim Kabini der Chipsatz integriert.

Notebookcheck hat nur Pullermark getestet. NEEEEEEEEEEEEEXT

Nightspider · 2013-05-23, 20:01:50

@Gipsel: Bringen die zusätzlichen ACEs /Queues einen merkbaren Vorteil bei der Programmierung bzw. für die Effizienz die Fähigkeiten und die max. Leistung aus so einem Chip herauszuholen?

Ich bin in Hinsicht auf die PS4 eh gespannt ob die Differenz zwischen theoretischer Hardwareleistung und tatsächlich nutzbarer Hardwareleistung zwischen Konsole vs. PC größer wird.
Gerade auch durch die imense Bandbreite durch GDDR5 und den möglichen Vorteil durch die nahe GPU Anbindung (SoC) und vielleicht eben auch durch die zusätzlichen ACEs/Queues.

PS: Hast du meine schöne ACE-Power Flasche gelöscht?

Knuddelbearli · 2013-05-23, 20:08:16

@VooDoo7mx

Sandy ist nicht der eigentliche Gegner sondern Atom der wird aber Meilenweit geschlagen also muss man sich eben andere Gegner suchen

Undertaker · 2013-05-23, 20:13:52

Das ist wahr, in dem Punkt zieht Intel erst mit den Haswell-ULVs wieder gleich.

Da gibt's doch auch ne ganze Reihe an Spielen. Wenn man mal die höchsten Einstellungen (d.h. die mit dem stärksten GPU-Limit) mit ein paar HD 4000 Werten vergleicht, kommt das (HD 8330 etwas unter ULV HD 4000) schon hin.

Allerdings ist das CPU-Limit in der Praxis wohl fast immer so stark das man mit einem Pentium/Celeron auf ähnliche fps kommt.

Locuza · 2013-05-23, 20:36:15

Hat Torchlight 2 eine MT-Skalierung auf bis zu 4 Kerne?
Und ja, ich finde es ist toll das ein kleines Unternehmen einen Multi Mrd. Konzern mit einem Produkt das Wasser reichen kann, wenn der Fertigungsnachteil mal zur Ausnahme nicht besteht.
Der Sandy-Bridge hat immerhin größere Ausführungsfenster, einen µop-cache, Caches @ Core-Speed, 3 Integer-ALUs usw.
Der Temash mit 1 Ghz steht ja im Vergleich auch nicht schlecht da.
Und durchaus erkenne ich auch, dass der Celeron alt ist, aber es ist noch einmal schön zu sehen das AMD nicht meilenweit weg ist.

dildo4u · 2013-05-23, 20:42:17

AMD füllt ne Lücke die Intel nicht bedient,in dem Preis/Watt Bereich wird's vermutlich nur 22nm Celerons mit na krüppligen GPU geben.(Intel HD Graphic)Alle Win 8 Tablet Hybriden um 500€ haben eigentlich nur AMD als Option.

samm · 2013-05-23, 21:14:38

Hätten sie, ja. Mal sehen, wie sich die OEMs diesmal drum drücken, bei Trinity / Richland tun sie es ja erfolgreich. Wollte meinem Arbeitskollegen, der ein kleines ProBook sich zutun wollte aufgrund meiner Zufriedenheit mit dem 6465b ein aktuelles Trinity-Gegenstück empfehlen, aber alles, was davon mit AMD erhältlich ist, sind A4-Versionen mit HDD.

VooDoo7mx · 2013-05-23, 21:27:18

Gegen einen Sandy oder Ivy Bridge Dual Core wo alle Features aktiviert sind, hat ein Quadcore Kabini keine Chance.

Und wenn wir schon Vergleiche ziehen, dann sollten wir auch im gleichen Formfaktor bzw. Verbrauchsbereich bleiben.

Der Temash A4-1200 2Cores/2Threads mit 1GHz ist auch nicht schneller als ein Clovertrail Atom Z2580 2Cores/4Threads mit 1,8GHz. Und das bei doppelten Stromverbrauch auf der AMD Seite. Und bevor jetzt jemand wegen Fertigungsvorteil rumheult, Clovertrail wird in 32nm gefertigt.
Ok die 3D Einheit ist besser, aber wirklich viel Spaß wird man mit 225MHz 2CU GCN mit single Channel DDR3-1066 auch nicht haben.
Ein aktueller Cedar Trail Atom N2600 auf 1,6GHz hat 3,5W TDP. Vergleichbare Kabini sind da schon weit über 10W.

Wenn Ende des Jahres Baytrail kommt, ist Intel dann eh wieder für 5 Jahre konkurrenzlos.

Sicher toll das nen Kabini bei 4fachen Stromverbrauch schneller als ein Atom ist. Jucheee. Aber ein 4770K ist auch schneller als A4-5000.
Merkst du was? Äpfel mit Birnen vergleichen und so.

Überhaupt und sowieso finde ich es sehr schade, dass es von AMD nur eine sehr langsame SKU gibt die man vom Verbrauch auch tatsächlich in lüfterlose Tablets packen kann. Ich hab da echt mehr erwartet.

samm · 2013-05-23, 21:41:22

Ehm... grob doppelter Takt und doppelte Anzahl Threads seitens Intel, und du wertest "nicht schneller" tatsächlich negativ?

Zitat:

Und das bei doppelten Stromverbrauch auf der AMD Seite.

TDP != Stromverbrauch. Oder beziehst du dich auf einen konkreten Test? Bei Anandtech sieht ja sogar der A4-5000 gut aus im Vergleich.

2013-05-23, 22:46:01

Ja das wäre es in der Tat. Gerade mal so schnell wie der in-order Uraltatom im für Intel alten 32nm Prozess, ist kein Glanzstück.

VooDoo7mx · 2013-05-24, 00:09:45

Für mich als Konsumenten zählt die Leistung die hinten rauskommt und besonders bei einen mobilen Gerät wie viel Strom dabei verbraucht wird.
Da ist es sowas von scheiß egal wie das erreicht wird. Ob nun viele Kerne, wenig kerne, hohe Taktfrequenz, niedrige Taktfrequenz, hohe IPC, niedrige IPC alles scheiß egal.

Das nun Temash und Kabini deutlich mehr Leistung bei gleicher Frequenz als ein aktueller Atom bietet streitet keiner ab. Nur ist bei gleicher Frequenz der Verbrauch 4-5 so hoch Auf AMD Seite.
SKUs vergleicht man immer danach in welchen Form Factor sie eingesetzt werden und da ist der Verbrauch maßgebend. Und wenn da die vergleichbare Intel SKU trotz 80% mehr Takt, 50% weniger Strom verbraucht und insgesamt auch noch schneller ist, ist dies einfach das bessere Produkt. Da gibt es nix zu diskutieren.

Ach echt jetzt? Tatsächlcihe Verbrauchsmessungen der letzten intel Generationen zeigen fast immer auf, dass deren CPUs meist unter TDP verbrauchen, während AMD CPUs dies aufs Maximum ausnutzen.
Eigentor?

time_me · 2013-05-24, 00:31:17

Einerseits sagst du Taktfrequenz, Kernzahl und IPC sind dir vollkommen gleichgültig und andererseits redest du wieder über den höheren Verbrauch von Temash / Kabini bei Taktgleichheit mit dem genannten Atom-Derivat

1. 4-5 facher Verbrauch sind spekulativ
2. Hat der Atom einfach eine extrem krüppelige GPU, welche nichts kann und entsprechend auch, übertrieben gesagt, nichts an Strom braucht.

2013-05-24, 07:04:03

Zitat von VooDoo7mx:

Nur ist bei gleicher Frequenz der Verbrauch 4-5 so hoch Auf AMD Seite.

Ich frag mich echt was du da für nen Unsinn verzapfst.

Sorge lieber mal für Quellen die deine abenteuerlichen Aussagen stützen.

2013-05-24, 08:26:11

lol, welcher Kabini ist denn für dich mit einem Cedar Trail vergleichbar?

Kabini ist sowohl in punkto CPU als auch GPU (Features!) meilenweit vor jedem Atom.

Atom ist für einen anderen Verbrauchsbereich konzipiert, dementsprechend hat er natürlich niedrigere Verbrauchswerte. Genau so gut könnte man fragen wie viel ein Atom wohl verbrauchen würde wenn man ihm hoch genug prügelt um mit einem Kabini mithalten zu können. Solche Vergleiche bringen gar nicht.

Kabini bedient erfolgreich eine Lücke die Intel nicht bedienen kann. Weder mit Atom (zu langsam) noch mit ULVs (zu teuer).

VooDoo7mx · 2013-05-24, 08:51:35

Versuch mal den Text zu verstehen. Die eine Aussage hat mit der anderen gar nichts zu tun. Gerade aus den Grund habe ich einen neuen Absatz mit einer leeren Zeile dazwischen begonnen.
Deutsch Ausdruck 5. Klasse.

Atom N2600 1,6GHz 3,5W ; E2-3000 1,65GHz 15W.
Mathematik Grundschule.

Dem stimme ich zu. Die Aussage ist nicht einmal übertrieben. Die GPU kommt ja aus dem SFF Smartphone Bereich und ist für "richtige" Computer unterdimensioniert. Nur wie ich schon gesagt hab, mit einer Radeon 8180 wird man auch nicht viel Spaß in Battlefield 3 haben. Ergo ist beides zum zocken ungeeignet.

Das ist Quatsch. Temash ist der direkte Konkurrent zu Clovertrail und Cedartrail. Genauso wie es die Vorgänger Hondo und Ontario waren.

Hat auch schon Zacate gemacht.
Wenn Intel dann mit Baytrail anrückt, kann AMD dann nur noch wieder mit Ramschpresien von der Resterampe punkten.

2013-05-23, 10:39:07	#621 (im Thread / einzeln)
M4xw0lf Insane Member Registriert: 2010-12-21 Beiträge: 17.867	Re: Kabini - 28nm Low-End-APU mit bis zu 4 Kernen - Bobcat_v2-/Jaguar-Kernen Zitat von Locuza http://www.computerbase.de/artikel/p...abini-im-test/ Kabini mit 15 Watt gewinnt deutlich gegen Brazos mit 18 Watt TPD und gegen den Celeron Dual-Core Sandy-Bridge mit 17 Watt. Und Wow: http://www.planet3dnow.de/photoplog/...hp?n=24466&w=o Kabini hat 4 ACEs mit jeweils 8 Compute Queues pro ACE! Damit verdient sich die iGPU wahrlich das technische IP-Level GCN1.1 Ich hab immer noch keine Ahnung was die ACEs tun. Was tun sie? 3DCenter. Aber normal.

2013-05-23, 10:57:50	#622 (im Thread / einzeln)
Locuza Admiral Member Registriert: 2010-11-13 Beiträge: 2.879	Re: Kabini - 28nm Low-End-APU mit bis zu 4 Kernen - Bobcat_v2-/Jaguar-Kernen Da könnte Gipsel das auf Deutsch genauer erklären. Wenn es technisch wird und dann noch auf Englisch verfasst ist, versteht man als Laie ja wenig. Soweit ich das verstanden habe können sie Compute-Workload an die Shader-Arrays weiterleiten. Der Command-Processor nimmt global alle Befehle entgegen, ob für Grafik-Berechnungen oder für Compute-Berechnungen. Die ACEs sind im Grunde abgespeckte Command-Prozessoren, welche nur für Compute zuständig sind. ( Der Command-Processor besteht glaube ich selber aus zwei Teilen, dem GFX-Command-Processor und den Compute-Command-Processor) Somit ist es z.B. möglich eine feste Anzahl der CUs für Compute festzulegen und gleichzeitig auf anderen CUs Grafik zu berechnen. Ohne ACEs muss alles durch den Command-Processor gelöst werden. Ich habe auch irgendetwas gelesen, dass man die GFX-Pipeline pausieren sollte, um möglichst maximalen Compute-Durchsatz zu erhalten. Mit den ACEs wäre parallel beides möglich, Grafik und Computing gleichzeitig betreiben ohne das sich irgendetwas gegenseitig in die Quere kommt. Da in dem Fall getrennte Manager für getrennte Arbeitsgruppen existieren. HyperQ von Nvidia soll so ähnlich funktionieren. Was mich aber wundert, eine CU ist ja ein Verbund aus 4 SIMDs, je 16 ALUs. Jede SIMD setzt eine Wavefront (Arbeitspaket, 64 Threads) ab und braucht dafür 4 Takte. Mit einer ACE können selbstständig Compute-Wavefronts verschickt werden. Jetzt verstehe ich nicht so ganz, aus was eine Queue genau besteht? Jede ACE kann bei Sea Island 8 Queues verschicken, wie wird das an die CUs/SIMDs gereicht? Wird hier flexibel an SIMDs verschickt oder feste Pakete an eine CU für 4 SIMDs? Da steht auch irgendetwas von 8 Stück können maximal gleichzeitig aktiv sein. Also von 4x8 = 32 Queues darf ich mich nur für 8 Stück entscheiden? Ich frage mich halt, ob 4 ACEs für 128-ALUs bei Kabini nicht oversized sind? GCN1 hat 2 ACEs mit je einer Queue. Das macht es gerade als Laien kaum möglich zu verstehen, wo die richtige Balance einzuschätzen wäre. Geändert von Locuza (2013-05-23 um 11:00:28 Uhr)

2013-05-23, 11:01:46	#623 (im Thread / einzeln)
robbitop 3DCenter Registriert: 2001-11-01 Beiträge: 37.106	Re: Kabini - 28nm Low-End-APU mit bis zu 4 Kernen - Bobcat_v2-/Jaguar-Kernen Hm GCN bringt Takt- und Einheitenbereinigt nur knappe 10 % mehr Leistung im Kabini. Ich vermute mal, dass das an der Bandbreitenlimitierung liegen könnte (Single Channel 64 bit). Konsolen: Playstation 4 PC: siehe Systeminfo, iPad Pro 10.5 256 GB 2017

2013-05-23, 17:57:16	#624 (im Thread / einzeln)
Gipsel Moderator Registriert: 2003-04-24 Ort: Hamburg Beiträge: 15.403	Re: Kabini - 28nm Low-End-APU mit bis zu 4 Kernen - Bobcat_v2-/Jaguar-Kernen Zitat von robbitop Hm GCN bringt Takt- und Einheitenbereinigt nur knappe 10 % mehr Leistung im Kabini. Ich vermute mal, dass das an der Bandbreitenlimitierung liegen könnte (Single Channel 64 bit). Es ist nicht nur die Speicherbandbreite. Da die TMU- und ROP-Anzahl nicht gestiegen ist (die Geometrierate ebenso wenig), unterschätzt man mit einer Normierung auf die ALU-Anzahl den GCN-Vorteil. Bei Brazos kam auf 10 ALUs (2 VLIW-Gruppen) eine TMU oder auf 20 ALUs (4 VLIW-Gruppen) eine ROP-Einheit. Bei Temash/Kabini kommen auf 16 ALUs eine TMU bzw. auf 32 ALUs ein ROP. Normierst Du die Leistung auf die ALU-Anzahl (und Takt), erreicht Kabini dann knapp 10% höhere Leistung/ALU mit 37,5% weniger TMUs, ROPs und Setup-/Rasterleistung. Die Leistung pro TMU, pro ROP oder pro Rasterleistung ist also offenbar um gute 70% gestiegen. ======================= Edit: Zu den ACEs Wenn ein Programm Kommandos an die GPU absetzt, also z.B. zur Ausführung eines Kernels aber auch zum Kopieren von Daten über PCIe oder was auch immer, dann landen die zuerst in einer Art Warteschlange (englisch Queue, das ist ein FIFO oder auch Ringbuffer [ein Ringbuffer ist eine beliebte Möglichkeit, einen FIFO zu bauen, die Bezeichnung ist also hier austauschbar]). Meist sind die Kernel ja von irgendwelchen vorher auszuführenden Aktionen abhängig (z.B. ein anderer Kernel der Daten schreibt, die mein Kernel benutzen will oder ein Buffer muß erst noch in den VRAM kopiert werden). Quetscht man jetzt alles in eine Queue, dann bekommt man schnell Probleme, wenn mehrere Programme gleichzeitig auf die GPU zugreifen wollen (oder auch ein Programm mehrere verschiedene Dinge gleichzeitig machen will). Außerdem kann ein Task, der z.B. noch auf das Kopieren von einem Buffer wartet, einen später abgesetzten, für den schon alles bereit ist, aufhalten. Hier bietet es sich an, mehrere Warteschlangen (die sich von der API-Seite, also von der Software her einrichten lassen) auch in Hardware auf unterschiedliche Queues zu legen (und nicht alles in eine Hardware-Queue zu quetschen). Damit kommen sich die dann nicht mehr so in die Quere und mehrere Anwendungen können parallel auf die GPU zugreifen, ohne das es zu künstlichen und unnötigen Blockierungen kommt. Trotzdem können auch zwischen Kerneln in unterschiedlichen Queues immer noch Abhängigkeiten festgelegt werden, die einzelnen Queues können also zum Zwecke der Synchronisation auch miteinander kommunizieren, falls das nötig ist (auch über die ACEs hinweg, nicht nur in einer ACE). NVidia vermarktet so ein Feature im GK110 (die kleineren können es nicht, die haben nur genau eine Queue) übrigens unter dem Namen "HyperQ" (maximal 32 Queues). AMD bietet mit allen Southern-Islands-GPUs im Prinzip 3 Queues: den Command-Prozessor (der die Queue für Grafik-Kommandos sowie für Compute-Shader/Kernel enthält) und die beiden in den ACEs (eine ACE ist ein abgespeckter Command-Prozessor, der nur Compute-Queues verwalten kann, keine für Grafik). Die ACEs enthalten alles, was zum Verwalten der Queues und Abarbeiten von Compute notwendig ist. Mit mehreren ACEs (also allen SI-GPUs) wird deswegen auch eine Art statische Aufteilung der GPU unterstützt, was OpenCL seit 1.2 (unter 1.1 gab es das bereits als Extension) als sogenanntes "device fission" oder "device partitioning" unterstützt (zumindest prinzipiell, AMDs OpenCL-Treiber kann es noch nicht, so daß das bisher nur auf CPUs nutzbar ist; dort kann man z.B. eine 8 Kern-CPU in 2 Subdevices mit je 4 Kernen aufteilen oder auch 2+6 oder wie man gerade lustig ist). Man kann sich also mit dieser Aufteilung mehrere logische GPUs (also OpenCL devices, das können ja auch CPUs sein) "erzeugen", die sich komplett wie unabhängige GPUs (devices) verhalten. Die Aufteilung der Rechenleistung kann man dabei auf verschiedene Art und Weise festlegen (z.B. einfach durch Angabe der Anzahl der CUs oder man teilt in gleich große Teile). Die Kernel, die man an einso erzeugtes Subdevice schickt, werden dann nicht mehr auf der ganzen GPU ausgeführt, sondern nur noch auf den zum Subdevice gehörenden CUs. Man betreibt damit also einen statischen Split, während ohne Device Fission (also nur mehrere Queues benutzt) die Hardware selbst dynamisch festlegt, wie die Kernel auf die komplette Hardware verteilt werden (GCN unterstützt dazu prinzipiell das Vergeben von Prioritäten, aber da kommt man bisher auch noch nicht dran). Man kann maximal so viele Subdevices erzeugen, wie es ACEs gibt (man kann also keinen ACE aufteilen). Mit "GCN1.1"/C.I. wird diese Fähigkeit jetzt aufgebohrt. Ein zwischenzeitlich mal auf der AMD-Seite verfügbares Manual dazu sprach von 8 Queues pro ACE und bis zu 8 ACEs pro GPU (also dann 64 Compute-Queues). Dies ist genau das, was wir bei Kabini sehen, eben nur mit 4 ACEs (und damit bis zu 32 Queues, genau wie GK110). Die PS4 (ist ja auch eine etwas größere GPU mit 18 CUs statt Kabinis 2 CUs) hat dann den vollen Satz von 8 ACEs und 64 Queues, die man dann auch für die etwas größeren diskreten GPUs der nächsten Generation erwarten kann (die PS4 hat allerdings auch zwei Grafik-Command-Prozessoren: einen "normalen" mit Grafik+Compute-Queue wie man das kennt und dann noch einen "high priority/VSHELL" Command-Prozessor, der nur Grafik- aber keine Compute-Kommandos annehmen kann und offenbar für das Betriebssystem reserviert ist; die Abarbeitung der Kommandos dort hat Vorrang vor dem vom Spiel genutzen Command-Prozessor). "I foresee a universal information system (UIS), which will give everyone access at any given moment to the contents of any book that has ever been published or any magazine or any fact. The UIS will have individual miniature-computer terminals, central control points for the flood of information, and communication channels incorporating thousands of artificial communications from satellites, cables, and laser lines. Even the partial realization of the UIS will profoundly affect every person, his leisure activities, and his intellectual and artistic development. Unlike television...the UIS will give each person maximum freedom of choice and will require individual activity. But the true historic role of the UIS will be to break down the barriers to the exchange of information among countries and people." Andrej Dmitrijewitsch Sacharow ("Vater" der sowjetische H-Bombe, Friedensnobelpreisträger 1975), 24.August 1974 Zitat von Coda Sind Äpfel nicht i.d.R. Birnen? Zitat von Die Priorisierung bei endlichen Ressourcen erfolgt anhand des Erfolges. Wirtschaftlichkeitsprinzip. Deswegen sind die Ausführung von Gipsel und co. im Allgemeinen auch falsch, da sie nicht auf Basis von Rationalität erfolgt sind, sondern von Sondereinflüssen - z.B. Verträgen. Mir fehlen die Worte! Zitat von Erstaunlich war der Vorsprung mit dem rv770 gegenüber GT200b, erwartungsgemäß ist er es mit Cypress gegen GF100 bzw. Barts gegen GF104, peinlich ist es mit Cayman gegen GF110 und GF114 Zitat von Erstaunlich war der Vorsprung mit dem rv770 gegenüber GT200b, erwartungsgemäß ist er es mit Cypress gegen GF100 bzw. Barts gegen GF104. Zitat von Ailuros AMD's Schaetzungen [der Performance] fuer GF100 sind wohl um einiges zuverlaessiger als NVIDIA's. Geändert von Gipsel (2013-05-23 um 18:58:47 Uhr)

2013-05-23, 19:41:13	#625 (im Thread / einzeln)
Locuza Admiral Member Registriert: 2010-11-13 Beiträge: 2.879	Re: Kabini - 28nm Low-End-APU mit bis zu 4 Kernen - Bobcat_v2-/Jaguar-Kernen Und wie sieht das mit den 8 maximal aktiven Queues aus? Wenn es bei Kabini 4 ACEs gibt, dann kann ich z.B. von ACE 0 2 Queues verschicken. ACE 1 1 Queues ... ACE 2 3 Queues ... ACE 3 2 Queue ... oder z.B. auch ACE 0 8 Queues ACE 1 0 . . . ? Und jetzt zu einer weiteren Frage. Sind 4 ACEs mit 32 Queues nicht oversized für 2 CUs, 8 SIMDs und 128 ALUs?