Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
- Ersteller PCGH-Redaktion
- Erstellt am
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Nein. Um es einfach zu umschreiben, man muss nur den letzten Übertrag für die zweite Runde parat haben.
Es bläht die Interconnects etwas auf und bringt zusätzlichen Verwaltungsaufwand.
@Rest
Dont feed the Troll !
Nein. Um es einfach zu umschreiben, man muss nur den letzten Übertrag für die zweite Runde parat haben.
Es bläht die Interconnects etwas auf und bringt zusätzlichen Verwaltungsaufwand.
@Rest
Dont feed the Troll !
FrozenPie
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Hieße dass dadurch etwas Effizienz flöten gehen würde, was wahrscheinlich durch die neue Fertigung wieder mehr als ausgeglichen wird
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
"etwas" kann man denk ich so stehen lassen, da alles was man macht Einfluss auf die Verlustleistung hat. Ob man es am ende Merkt ist die andere Frage, messen kann man es sicherlich.
Interessant wird es zu sehen ob es vllt. andere Penalties gibt, etwa reduzierter Maximaltakt o.ä.
BTT
"etwas" kann man denk ich so stehen lassen, da alles was man macht Einfluss auf die Verlustleistung hat. Ob man es am ende Merkt ist die andere Frage, messen kann man es sicherlich.
Interessant wird es zu sehen ob es vllt. andere Penalties gibt, etwa reduzierter Maximaltakt o.ä.
BTT
FrozenPie
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Wird wirklich interessant ob Pascal immer noch so Taktfreudig wie Maxwell wird, aber das bezweifle ich mal sehr stark
"Etwas" ist vor allem darauf bezogen was gerade gemacht wird. Wenn nur Single-Percision oder gar Half-Percision (FP32 bzw FP16) verwendet wird, geht natürlich Effizienz flöten, aber wenn Double-Percision (FP64) verwendet wird, steigt die Effizienz sehr deutlich (Ich rede hier wirklich von Effizienz und nicht vom Verbrauch)
Wird wirklich interessant ob Pascal immer noch so Taktfreudig wie Maxwell wird, aber das bezweifle ich mal sehr stark
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Mir ist schleierhaft was du dann mit Effizienz meinst, wenn nicht Durchsatz pro Watt/X-Einheit.
Der Sinn ist doch, dass man keine dedizierten ALUs für bestimmte Genauigkeiten mehr braucht.
Der Durchsatz/Effizienz skaliert dann auch grob linear, ergo 2xF16 / 1xFP32 / 0.5xFP64 pro definierter Watt/Zeit Einheit.
Die Effizienz pro Bit bleibt also mehr oder weniger gleich.
@Topic
Tonga ist mir für die Daten nach wie vor zu groß, 700 Mio Transistoren mehr hat als Tahiti und dann nur DCC und besseres Frontend,etc.
Mir ist schleierhaft was du dann mit Effizienz meinst, wenn nicht Durchsatz pro Watt/X-Einheit.
Der Sinn ist doch, dass man keine dedizierten ALUs für bestimmte Genauigkeiten mehr braucht.
Der Durchsatz/Effizienz skaliert dann auch grob linear, ergo 2xF16 / 1xFP32 / 0.5xFP64 pro definierter Watt/Zeit Einheit.
Die Effizienz pro Bit bleibt also mehr oder weniger gleich.
@Topic
Tonga ist mir für die Daten nach wie vor zu groß, 700 Mio Transistoren mehr hat als Tahiti und dann nur DCC und besseres Frontend,etc.
FrozenPie
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Sorry falls es jetzt dadurch zu Missverständnissen kam
Gibt halt nur immer wieder solche die die Effizienz mit dem Verbrauch gleichsetzen und dem wollte ich entgegenwirken
Sorry falls es jetzt dadurch zu Missverständnissen kam
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Für die Genauigkeit braucht man mehr Verbindungen und muss mehr Datenpfade getrennt halten, ebenso das Register-Stack braucht Anpassungen bei den Verbindungen, je nach Implementierung.
AMD hat bei GCN 1-3 ALUs mit einer DP-Konfiguration von 1:16 - 1:2 vorliegen.
Bei GCN 3 unterstützt AMD auch nativ FP16, aber mit dem gleichen Durchsatz wie bei FP32, aber sie belegen dafür weniger Register, was der Performance dann doch hilft.
Nvidia hat bei Maxwell auch Mixed-Precision ALUs.
Bei Tegra X können jeweils 2x 16 FP Operationen durchgeführt werden, wenn jeweils die gleichen Operationen in einem Durchgang verwendet werden oder eben 1x 32 FP.
Bei Pascal muss Nvidia das Netz dann auf FP64 verbreitern.
Wenn die Serie schon fertig ist, was sie natürlich ist, dann hat die neuliche Entscheidung die interne Unternehmensstruktur wieder mehr zu spalten und zu fokussieren, natürlich keinen Einfluss darauf.
Was bei GCN Gen 4 wichtig sein wird, ist die Software und das ist eine Sache, die man immer negativ oder positiv beeinflussen kann.
Man könnte auch über einen doppelt so breiten L2-Cache spekulieren.
Kommt darauf an wie du eine Architektur definierst und wie umfassend du das siehst.
Für die Genauigkeit braucht man mehr Verbindungen und muss mehr Datenpfade getrennt halten, ebenso das Register-Stack braucht Anpassungen bei den Verbindungen, je nach Implementierung.
AMD hat bei GCN 1-3 ALUs mit einer DP-Konfiguration von 1:16 - 1:2 vorliegen.
Bei GCN 3 unterstützt AMD auch nativ FP16, aber mit dem gleichen Durchsatz wie bei FP32, aber sie belegen dafür weniger Register, was der Performance dann doch hilft.
Nvidia hat bei Maxwell auch Mixed-Precision ALUs.
Bei Tegra X können jeweils 2x 16 FP Operationen durchgeführt werden, wenn jeweils die gleichen Operationen in einem Durchgang verwendet werden oder eben 1x 32 FP.
Bei Pascal muss Nvidia das Netz dann auf FP64 verbreitern.
Es ging um Arctic Islands vs. Pascal.
Der letzte Punkt hebelt den ersten aus.
Wenn die Serie schon fertig ist, was sie natürlich ist, dann hat die neuliche Entscheidung die interne Unternehmensstruktur wieder mehr zu spalten und zu fokussieren, natürlich keinen Einfluss darauf.
Was bei GCN Gen 4 wichtig sein wird, ist die Software und das ist eine Sache, die man immer negativ oder positiv beeinflussen kann.
Ein doppelt so breites Front-End ist schon Schotter, ebenso kommen einige Transistoren vom 4K Encode/Decode dazu.Tonga ist mir für die Daten nach wie vor zu groß, 700 Mio Transistoren mehr hat als Tahiti und dann nur DCC und besseres Frontend,etc.
Man könnte auch über einen doppelt so breiten L2-Cache spekulieren.
Zuletzt bearbeitet:
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
UVD 5.0 schwer einzuschätzen, aber man wirft dafür ja UVD 3.0 raus.
DCC ist auch schwer einzuschätzen, deshalb lieber klotzen (100 Mio.)
DP1:3 fällt raus, dafür kommt GCN1.2
Front-End ist ne Menge, da gebe ich dir recht aber ob das wirklich an die 500 Mio. sind? Das wären grob 20 % des Transistor Budgets(ganzes Frontend).
Wenn man die Die-Shots von Tahiti und Tonga vergleicht und man davon ausgeht, dass beide echt sind, so fallen schon einige Ungereimtheiten auf.
Es kann natürlich sein, dass sich die alle in Luft auflösen, aber dann bleibt immer noch die Frage nach dem Sinn den Tonga eigentlich erfüllen soll. Dreistellige Millionenbeträge für einen Apple Design-Win?
Natürlich ist es nicht so simpel wie dargestellt, ich wollte allerdings keinen extra Fred deswegen aufmachen und du bei zweiter Überlegung anscheinend auch nicht“Das was du wieder gelöscht hast„
Rechnen wir es doch mal durch, 1MB L2 sind in etwa 50 Mio. Transistoren(6T-SRAM).
UVD 5.0 schwer einzuschätzen, aber man wirft dafür ja UVD 3.0 raus.
DCC ist auch schwer einzuschätzen, deshalb lieber klotzen (100 Mio.)
DP1:3 fällt raus, dafür kommt GCN1.2
Front-End ist ne Menge, da gebe ich dir recht aber ob das wirklich an die 500 Mio. sind? Das wären grob 20 % des Transistor Budgets(ganzes Frontend).
Wenn man die Die-Shots von Tahiti und Tonga vergleicht und man davon ausgeht, dass beide echt sind, so fallen schon einige Ungereimtheiten auf.
Es kann natürlich sein, dass sich die alle in Luft auflösen, aber dann bleibt immer noch die Frage nach dem Sinn den Tonga eigentlich erfüllen soll. Dreistellige Millionenbeträge für einen Apple Design-Win?
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
1,5 MB L2-Cache - 768KB = ~ 36 Millionen Transistoren zusätzlich.
Bei UVD/VCE ist es natürlich eine gute Frage, wie viel die überhaupt kosten.
Auf jeden Fall nehmen sie schon ordentlich Platz weg (Carrizo hat natürlich noch den h265 Codec implementiert):
http://cdn.wccftech.com/wp-content/uploads/2015/08/AMD-Carrizo-APU_Video-IP.jpg
DCC hat AMD bei Carrizo mit 0,2% Flächenkosten beziffert:
http://cdn.wccftech.com/wp-content/uploads/2015/08/AMD-Carrizo-APU_Graphic-Color-Compression.jpg
Das ganze irgendwie in Transistoren umzurechnen ist natürlich nicht machbar, aber 100 Millionen für DCC sind es definitiv nicht.
Von DP 1:4 auf 1:16 runter, keine Ahnung wie viele Transistoren das spart.
GCN Gen 3 hat auf jeden Fall Hardware Virtualisierung, Context Switching, dafür hat AMD irgendwelche Puffer für den Context Save sicher erweitert, aber auch eine gute Frage, was das ganze in Transistoren kostet.
Das Front-End hat auf jeden Fall sehr viele Transistoren.
Der Sinn von Tonga oder die ganze Produktstrategie erschließt sich mir auch nicht bzw. es ist ein Ergebnis trauriger Umstände.
Das Tonga existiert ist natürlich verständlich, wann und wie Tonga auf den Markt gebracht wurde, leider weniger.
1,5 MB L2-Cache - 768KB = ~ 36 Millionen Transistoren zusätzlich.
Bei UVD/VCE ist es natürlich eine gute Frage, wie viel die überhaupt kosten.
Auf jeden Fall nehmen sie schon ordentlich Platz weg (Carrizo hat natürlich noch den h265 Codec implementiert):
http://cdn.wccftech.com/wp-content/uploads/2015/08/AMD-Carrizo-APU_Video-IP.jpg
DCC hat AMD bei Carrizo mit 0,2% Flächenkosten beziffert:
http://cdn.wccftech.com/wp-content/uploads/2015/08/AMD-Carrizo-APU_Graphic-Color-Compression.jpg
Das ganze irgendwie in Transistoren umzurechnen ist natürlich nicht machbar, aber 100 Millionen für DCC sind es definitiv nicht.
Von DP 1:4 auf 1:16 runter, keine Ahnung wie viele Transistoren das spart.
GCN Gen 3 hat auf jeden Fall Hardware Virtualisierung, Context Switching, dafür hat AMD irgendwelche Puffer für den Context Save sicher erweitert, aber auch eine gute Frage, was das ganze in Transistoren kostet.
Das Front-End hat auf jeden Fall sehr viele Transistoren.
Der Sinn von Tonga oder die ganze Produktstrategie erschließt sich mir auch nicht bzw. es ist ein Ergebnis trauriger Umstände.
Das Tonga existiert ist natürlich verständlich, wann und wie Tonga auf den Markt gebracht wurde, leider weniger.
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
DP 1:4 stimmt
Der Große HW-Block links neben den ALUs stört mich einfach, den gibt es weder bei Tahiti noch bei Hawaii und auf dem einzigen Fiji Die-Shot ist auch nichts zu erkennen
Full Tonga@ 384bit mit 6GB medium Speed GDDR fänden alle vermutlich deutlich prickelnder.
Naja vmtl. will ich es einfach nur nicht wahrhaben, dass AMD mit Tonga einfach Design Fehler gemacht hat, sieht ihnen sonst gar nicht ähnlich.
Wobei ich nicht weiß, wie die Sache implementiert ist. Hat jeder Memory Controller seinen eigenen „Kompressor“? Wäre bei 384Bit natürlich doppelt bitter …
DP 1:4 stimmt
Der Große HW-Block links neben den ALUs stört mich einfach, den gibt es weder bei Tahiti noch bei Hawaii und auf dem einzigen Fiji Die-Shot ist auch nichts zu erkennen
So traurig können die Umstände doch gar nicht sein, dass man 384Bit Interfaces verbaut für den Fall, das DDC nicht Funktioniert. Tonga erscheint wie aus einer anderen Welt.
Full Tonga@ 384bit mit 6GB medium Speed GDDR fänden alle vermutlich deutlich prickelnder.
Naja vmtl. will ich es einfach nur nicht wahrhaben, dass AMD mit Tonga einfach Design Fehler gemacht hat, sieht ihnen sonst gar nicht ähnlich.
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Ausgehend vom Schaubild liegt ein Kompressor bei einem Render-Backend an.
Bei Carrizo sind es 2 (2x4 = 8 ROPs), wo die Daten dann komprimiert den Speichercontrollern übergeben werden.
Bei Tonga gibt es 32 ROPs, also 8 Render-Backs-Ends und damit vermutlich auch 8 Kompressoren.
Von Hawaii und Fiji haben wir leider keine Bilder.
Wenn ich das richtig sehe, sind bei Tonga die ROPs auf zwei Seiten verteilt (Links/Rechts) und nicht mehr wie bei Tahiti auf drei Seiten.
Weswegen eine Seite, eben die links, mehr Logik darstellt.
http://www.abload.de/img/nfqygvru4k.jpg
http://cdn.wccftech.com/wp-content/uploads/2015/06/AMD-Tonga-GPU-Die-Shot-635x462.jpg
Da kommt natürlich noch etwas mehr dazu, aber dort findet sich auch der UVD/VCE und vielleicht noch irgendetwas zerquetschtes.
Stattdessen gab es einen Tonga mit 256-Bit, 1792 ALUs, 2GB und erst jetzt nach einem Jahr kommt eine SKU mit 2048 ALUs.
Also traurig erscheinen die Umstände durchaus, wenn man das ganze so strecken muss und am Ende auf 384-Bit SKUs verzichtet.
Ein Design-Fehler findet sich nicht, außer man nimmt spekulativ an das die zwei Memory-Controller Rechts kaputt sind, aus welchen Gründen auch immer.
Da hast du bei deiner Überlegung Recht.
Ausgehend vom Schaubild liegt ein Kompressor bei einem Render-Backend an.
Bei Carrizo sind es 2 (2x4 = 8 ROPs), wo die Daten dann komprimiert den Speichercontrollern übergeben werden.
Bei Tonga gibt es 32 ROPs, also 8 Render-Backs-Ends und damit vermutlich auch 8 Kompressoren.
Wir haben aber nur einen Tahiti die-shot als Vergleich.Der Große HW-Block links neben den ALUs stört mich einfach, den gibt es weder bei Tahiti noch bei Hawaii und auf dem einzigen Fiji Die-Shot ist auch nichts zu erkennen
Von Hawaii und Fiji haben wir leider keine Bilder.
Wenn ich das richtig sehe, sind bei Tonga die ROPs auf zwei Seiten verteilt (Links/Rechts) und nicht mehr wie bei Tahiti auf drei Seiten.
Weswegen eine Seite, eben die links, mehr Logik darstellt.
http://www.abload.de/img/nfqygvru4k.jpg
http://cdn.wccftech.com/wp-content/uploads/2015/06/AMD-Tonga-GPU-Die-Shot-635x462.jpg
Da kommt natürlich noch etwas mehr dazu, aber dort findet sich auch der UVD/VCE und vielleicht noch irgendetwas zerquetschtes.
Prickelnd wäre es gewesen Tonga früher zu releasen und mit 3 und 6 GB Modellen Tahiti vollständig zu ersetzen.
Stattdessen gab es einen Tonga mit 256-Bit, 1792 ALUs, 2GB und erst jetzt nach einem Jahr kommt eine SKU mit 2048 ALUs.
Also traurig erscheinen die Umstände durchaus, wenn man das ganze so strecken muss und am Ende auf 384-Bit SKUs verzichtet.
Ein Design-Fehler findet sich nicht, außer man nimmt spekulativ an das die zwei Memory-Controller Rechts kaputt sind, aus welchen Gründen auch immer.
Zuletzt bearbeitet:
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Bei Hawaii hast du Recht, da gibt es nur Bull-Shots aber bei Fiji hat Chipworks einen veröffentlicht, leider nur Low Res.
https://www.chipworks.com/competiti...-reports/recent-reports/amd-fury-x-hynix-high
ROPs: Ist eine mögliche Erklärung, es sieht in der Tat etwas danach aus. Sicher ist natürlich was anderes, vor allem da die Blockgröße variiert.
Design Fehler im Sinne von Unnütz und daher natürlich ein Fehler, defekte IP-Blöcke wären Implementierungsfehler.
Das Launch Prozedere war aus wirtschaftlicher Sicht wohl Schadensbegrenzung, da man die Tahitis noch loswerden musste.
Bei Hawaii hast du Recht, da gibt es nur Bull-Shots aber bei Fiji hat Chipworks einen veröffentlicht, leider nur Low Res.
https://www.chipworks.com/competiti...-reports/recent-reports/amd-fury-x-hynix-high
ROPs: Ist eine mögliche Erklärung, es sieht in der Tat etwas danach aus. Sicher ist natürlich was anderes, vor allem da die Blockgröße variiert.
Design Fehler im Sinne von Unnütz und daher natürlich ein Fehler, defekte IP-Blöcke wären Implementierungsfehler.
Das Launch Prozedere war aus wirtschaftlicher Sicht wohl Schadensbegrenzung, da man die Tahitis noch loswerden musste.
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Das ist in der Welt des Internets, wo ich mich meistens aufhalte, gar nicht vorgekommen.
Sehr interessant das HBM-Interface zu sehen.
Holy Sh*t!
Das ist in der Welt des Internets, wo ich mich meistens aufhalte, gar nicht vorgekommen.
Sehr interessant das HBM-Interface zu sehen.
In dem Sinne ja, etwas haben, was man nicht verwendet und dann pro Chip mehr bezahlen, dass ist natürlich sub-optimal.Design Fehler im Sinne von Unnütz und daher natürlich ein Fehler, defekte IP-Blöcke wären Implementierungsfehler.
Was unter traurige Umstände fällt.
grabhopser
Freizeitschrauber(in)
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Jetzt bräuchte man nur noch das Kleingeld und man könnte den ganzen Bericht einsehen.
Auch traurig
Holy Sh*t!
Das ist in der Welt des Internets, wo ich mich meistens aufhalte, gar nicht vorgekommen.
Sehr interessant das HBM-Interface zu sehen.
Jetzt bräuchte man nur noch das Kleingeld und man könnte den ganzen Bericht einsehen.
Auch traurig
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Ist denn ein GPU auch in Rounds aufgeteilt wie eine CPU(Ringbus)
Im Prinzip würde ich das Konzept(GCN(1.0,1.1,1.2),Maxwell,Volta) als Architektur sehen nur ich würde es in Low und High-Level aufteilen und alles was im Lowlevel geändert wird hätte für mich einen tieferen eingriff in die Architektur und highlevel eingriffe wären nur abwandlungen eben für verschiedene Sparten-, Leistungsklassen, anderer Chip andere Leistung aber eben das gleiche Konzept
Ihr vergesst das Tonga/Antigua noch gegenüber GCN1.0-1 HSA implimentiert hat da kommt man schon so auf seine transistoren anzahl und ich denke nicht das das HSA interface besonders klein ausfällt
Zuletzt bearbeitet:
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
1. Rounds <---> Ringus???
2. Auf low-level-Sicht muss man natürlich tiefgreifend bei den ALUs etwas verändern.
3. Wir haben schon gesagt GCN Gen 3.
Tonga hat kein "HSA-Interface", dass haben im engeren Sinn nur die APUs, um das HSA-Buzzword mal abzulegen, geht es an der Stelle darum, wie man Daten-Kohärenz sicherstellt.
Dafür hat AMD spezifische Buse implementiert, bis hin zu zusätzlichen Adressbits und Cache-Tags für die Kohärenz.
Die dGPUs haben das nicht, brauchen sie auch nicht, "dank" PCIe.
1. Rounds <---> Ringus???
2. Auf low-level-Sicht muss man natürlich tiefgreifend bei den ALUs etwas verändern.
3. Wir haben schon gesagt GCN Gen 3.
Tonga hat kein "HSA-Interface", dass haben im engeren Sinn nur die APUs, um das HSA-Buzzword mal abzulegen, geht es an der Stelle darum, wie man Daten-Kohärenz sicherstellt.
Dafür hat AMD spezifische Buse implementiert, bis hin zu zusätzlichen Adressbits und Cache-Tags für die Kohärenz.
Die dGPUs haben das nicht, brauchen sie auch nicht, "dank" PCIe.
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
@Locuza
Ringbus Ringbus für Cores, Speicher, Grafik, PCI-Express - Core i7 Sandy Bridge im Test: Quad-Cores werden schneller und viel sparsamer - Golem.de
hups steht sogar drunter schon lange von Grafikkarten bekannt
Das mit HSA find ich grad auf die schnelle nich meine aber mal eine Folie drüber gesehen zu haben
@Locuza
Ringbus Ringbus für Cores, Speicher, Grafik, PCI-Express - Core i7 Sandy Bridge im Test: Quad-Cores werden schneller und viel sparsamer - Golem.de
hups steht sogar drunter schon lange von Grafikkarten bekannt
Das mit HSA find ich grad auf die schnelle nich meine aber mal eine Folie drüber gesehen zu haben
Locuza
Lötkolbengott/-göttin
AW: Radeon R9 380X: Powercolor bestätigt 4 GiByte an 256 Bit
Ich habe mich gewundert, wie du von der Genauigkeit der Berechnungen auf Ringbus gekommen bist.
ATI/AMD hatte den Ringbus nur beim R600, danach war es wieder eine klassische Crossbar.
/Edit: Oh, die 1xxx Serie hatte ihn auch schon davor.
Die Verwendung von einem Ringbus ist mir jetzt nicht oft ins Auge gefallen.
Intel beim LLC, Sony/IBM/Toshiba beim Cell, R600 beim Memory-Controller.
Ansonsten?
Bei HSA, jedenfalls was auch notwendig für die Spezifikation ist, hat GCN Gen 3 allgemein Compute Context Switching/Preemption realisiert.
Ich habe mich gewundert, wie du von der Genauigkeit der Berechnungen auf Ringbus gekommen bist.
ATI/AMD hatte den Ringbus nur beim R600, danach war es wieder eine klassische Crossbar.
/Edit: Oh, die 1xxx Serie hatte ihn auch schon davor.
Die Verwendung von einem Ringbus ist mir jetzt nicht oft ins Auge gefallen.
Intel beim LLC, Sony/IBM/Toshiba beim Cell, R600 beim Memory-Controller.
Ansonsten?
Bei HSA, jedenfalls was auch notwendig für die Spezifikation ist, hat GCN Gen 3 allgemein Compute Context Switching/Preemption realisiert.
Zuletzt bearbeitet:
Ähnliche Themen
