AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
- Ersteller PCGH-Redaktion
- Erstellt am
R
Rotkaeppchen
Guest
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
"Mit den Augen zwinker, lächeln, Dir ein Bier versprechend"
Lohnt es sich trotzdem, die Zeitung zu lesen? Nur weil Du Fiji nicht siehst, kann es doch da sein?
"Mit den Augen zwinker, lächeln, Dir ein Bier versprechend"
Atent123
Volt-Modder(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Momentan spricht man von einem Refresh nicht von einem Rebrand.
Momentan spricht man von einem Refresh nicht von einem Rebrand.
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
PCGH lesen lohnt sich immer!
https://www.google.de/maps/place/Fi...2!3m1!1s0x6e1990fd703cdc5d:0x9e9c319946ef5b93
P.S.: Weintrinker
PCGH lesen lohnt sich immer!
https://www.google.de/maps/place/Fi...2!3m1!1s0x6e1990fd703cdc5d:0x9e9c319946ef5b93
P.S.: Weintrinker
Lios Nudin
BIOS-Overclocker(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Egal ob Rebrand oder Refresh, großartige Leistungssprünge sollte man unterhalb von Fiji nicht erwarten:
Ich halte diese Entwicklung für eher wahrscheinlich.
Egal ob Rebrand oder Refresh, großartige Leistungssprünge sollte man unterhalb von Fiji nicht erwarten:
Ich halte diese Entwicklung für eher wahrscheinlich.
Locuza
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Du musst das Speicherinterface ändern, der Rest kann aber im Prinzip gleich bleiben.
Weil das später ein unabhängiger Abschnitt ist.
Du musst das Speicherinterface ändern, der Rest kann aber im Prinzip gleich bleiben.
Jever_Pilsener
BIOS-Overclocker(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Die Graka kommt dann sicher mit einer Kompakt-Wakü, bin kein Fan davon. Aber eine Graka mit standardmäßig verbautem vollwertigem Wasserkühler, den man in seinen Kühlkreislauf einbinden kann, wäre nice.
Die Graka kommt dann sicher mit einer Kompakt-Wakü, bin kein Fan davon. Aber eine Graka mit standardmäßig verbautem vollwertigem Wasserkühler, den man in seinen Kühlkreislauf einbinden kann, wäre nice.
wolflux
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Ich muss da Zweifel anmelden, dass man mit der Wakü darauf 100% in die Vollen gehen kann, auch für Enthusiasten. Ich tippe aus Erfahrung das es schon ordentliche OC - ERGEBNISSE geben wird jedoch, meine Bedenken sind die mitgekühlten Spannungswandler,, wie auch immer sie mitgekühlt werden". Dann auch nur mit 2 Lüftern und größerer Lautstärke.
Wir werden sehen ☺
MfG.
wolflux
Ich muss da Zweifel anmelden, dass man mit der Wakü darauf 100% in die Vollen gehen kann, auch für Enthusiasten. Ich tippe aus Erfahrung das es schon ordentliche OC - ERGEBNISSE geben wird jedoch, meine Bedenken sind die mitgekühlten Spannungswandler,, wie auch immer sie mitgekühlt werden". Dann auch nur mit 2 Lüftern und größerer Lautstärke.
Wir werden sehen ☺
MfG.
wolflux
Zuletzt bearbeitet:
RawMangoJuli
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Grafikkarten: AMDs Radeon 300 auf Gaming Show statt Computex - ComputerBase
AMD DAS NERVT!
Grafikkarten: AMDs Radeon 300 auf Gaming Show statt Computex - ComputerBase
AMD DAS NERVT!
Atent123
Volt-Modder(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Sind doch bisher alles nur Gerüchte.
Sind doch bisher alles nur Gerüchte.
Brehministrator
BIOS-Overclocker(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Davon würde man erstmal standardmäßig ausgehen, ja. Das kann aber einen ziemlichen Rattenschwanz hinter sich her ziehen, so dass man letztlich doch die halbe Architektur umstellen muss. So zum Beispiel die Art, wie der Speichercontroller mit den ganzen Shader-Clustern oder den Caches kommuniziert, also quasi der On-Chip-Bus. Der könnte schlichtweg für so eine hohe Bandbreite nicht geeignet sein. In GPUs ist da einiges schaltungstechnisch *wesentlich* komplizierter als bei CPUs. Heutzutage können ja die Shader unabhängig voneinander und "über kreuz" auf den VRAM zugreifen, was früher gar nicht ging. Das stellt enorme Anforderungen an die Anbindung des Speichercontrollers an alle Shader-Cluster, denn der Speichercontroller muss parallel dutzende völlig unabhängige Anfragen verarbeiten (oder eine sehr leistungsfähige Queue dafür bestitzen). Das kann man nicht einfach ohne Leistungsverluste auf ein wesentlich breiteres Speicher-Interface hochskalieren, wenn es ursprünglich dafür nicht vorgesehen war. Es ist nicht immer so einfach, wie es auf den ersten Blick scheint.
Was natürlich gleich bleiben kann, sind die ganzen kleinen Shader selbst. Die nehmen zwar (gemeinsam mit den Caches) einen Großteil der Die-Fläche ein, bedeuten aber längst nicht so viel Layout-Aufwand, weil die alle ein jeweils gleiches Layout auf dem Die besitzen. Wenn man also nur die Shader beibehält, und den Rest neu designt, hat man den "Großteil" der Arbeit und Optimierung verworfen. Und das rechtfertigt m.E. definitiv die Bezeichnung "neue Architektur"
Davon würde man erstmal standardmäßig ausgehen, ja. Das kann aber einen ziemlichen Rattenschwanz hinter sich her ziehen, so dass man letztlich doch die halbe Architektur umstellen muss. So zum Beispiel die Art, wie der Speichercontroller mit den ganzen Shader-Clustern oder den Caches kommuniziert, also quasi der On-Chip-Bus. Der könnte schlichtweg für so eine hohe Bandbreite nicht geeignet sein. In GPUs ist da einiges schaltungstechnisch *wesentlich* komplizierter als bei CPUs. Heutzutage können ja die Shader unabhängig voneinander und "über kreuz" auf den VRAM zugreifen, was früher gar nicht ging. Das stellt enorme Anforderungen an die Anbindung des Speichercontrollers an alle Shader-Cluster, denn der Speichercontroller muss parallel dutzende völlig unabhängige Anfragen verarbeiten (oder eine sehr leistungsfähige Queue dafür bestitzen). Das kann man nicht einfach ohne Leistungsverluste auf ein wesentlich breiteres Speicher-Interface hochskalieren, wenn es ursprünglich dafür nicht vorgesehen war. Es ist nicht immer so einfach, wie es auf den ersten Blick scheint.
Was natürlich gleich bleiben kann, sind die ganzen kleinen Shader selbst. Die nehmen zwar (gemeinsam mit den Caches) einen Großteil der Die-Fläche ein, bedeuten aber längst nicht so viel Layout-Aufwand, weil die alle ein jeweils gleiches Layout auf dem Die besitzen. Wenn man also nur die Shader beibehält, und den Rest neu designt, hat man den "Großteil" der Arbeit und Optimierung verworfen. Und das rechtfertigt m.E. definitiv die Bezeichnung "neue Architektur"
C
cesium137
Guest
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Denke schon......
Weiß einer was Raph so trinkt?
Denke schon......
Locuza
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
GS-4106 The AMD GCN Architecture - A Crash Course, by Layla Mah
5,5 TB an Bandbreite kannst du theoretisch durch den LDS bekommen, 2,8 TB beim L1 Cache und 1 TB beim L2-Cache.
Da wäre der HBM-Speicher weiterhin die langsamste Stufe, selbst mit 512 oder 640 GB/s.
Bei Hawaii müsste man in der Hinsicht nichts ändern.
Davor befindet sich sowieso noch die fette Crossbar.
Die "einzige" konkrete Anpassung die man benötigt, ist wahrscheinlich die Verdrahtung zwischen Speicher-Controllern, L2-Cache und daneben und dazwischen vielleicht den ROPs.
Was aber glaube ich dem gleichem Prinzip wie GDDR5 folgen kann und wird.
Alles andere kann man vermutlich sitzen und stehen lassen wie es ist.
Nur das einzig Wahre :
Mal eine kleine Auflistung was Hawaii intern so durchpumpen kann (Seite 47):
GS-4106 The AMD GCN Architecture - A Crash Course, by Layla Mah
5,5 TB an Bandbreite kannst du theoretisch durch den LDS bekommen, 2,8 TB beim L1 Cache und 1 TB beim L2-Cache.
Da wäre der HBM-Speicher weiterhin die langsamste Stufe, selbst mit 512 oder 640 GB/s.
Bei Hawaii müsste man in der Hinsicht nichts ändern.
Davor befindet sich sowieso noch die fette Crossbar.
Die "einzige" konkrete Anpassung die man benötigt, ist wahrscheinlich die Verdrahtung zwischen Speicher-Controllern, L2-Cache und daneben und dazwischen vielleicht den ROPs.
Was aber glaube ich dem gleichem Prinzip wie GDDR5 folgen kann und wird.
Alles andere kann man vermutlich sitzen und stehen lassen wie es ist.
Als ob er so einen Mist trinkt.
Nur das einzig Wahre
:
Zuletzt bearbeitet:
Brehministrator
BIOS-Overclocker(in)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Sehr schönes Dokument, kannte ich noch nicht
Vielleicht geht es ja doch. Ich glaube trotzdem nicht daran, dass wir in den nächsten Monaten Hawaii mit HBM sehen werden, auch wenn es möglich sein könnte
Sehr schönes Dokument, kannte ich noch nicht
Vielleicht geht es ja doch. Ich glaube trotzdem nicht daran, dass wir in den nächsten Monaten Hawaii mit HBM sehen werden, auch wenn es möglich sein könnte 
Rolk
Kokü-Junkie (m/w)
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Gut zu wissen.
Das letztere, ersteres wusste ich schon.
PCGH lesen lohnt sich immer!
https://www.google.de/maps/place/Fi...2!3m1!1s0x6e1990fd703cdc5d:0x9e9c319946ef5b93
P.S.: Weintrinker
Gut zu wissen.
Das letztere, ersteres wusste ich schon.
Locuza
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Man braucht schließlich eine neue Maske/Chip dafür.
Meine Aussage war lediglich, dass nur wegen HBM keine neue Architektur oder Änderungen garantiert sind.
Natürlich hat am Ende AMD Fiji mit HBM konzipiert.
Entsprechende Berechnungen und Simulationen vollzogen, wie viele ALUs, ROPs, L2-Cache..., Sinn machen und was man letztendlich auch reinpacken kann.
Wenn Fiji ein echtes Monster darstellen möchte, dann wäre es ein 8-Fach Front-End und 128-ROPs mit 4096 ALUs.
AMD könnte aber Front/Back-End weiterhin relativ schlank halten und einfach versuchen durch interne Verbesserungen am Front-End und durch bessere Versorgung des Back-Ends durchzukommen.
Die Neugierde ist schon schrecklich, wenn es gar keine Informationen diesbezüglich gibt, nicht einmal unseriöse Gerüchte.
Passieren wird das sicher nicht. (Hawaii mit HBM)Vielleicht geht es ja doch. Ich glaube trotzdem nicht daran, dass wir in den nächsten Monaten Hawaii mit HBM sehen werden, auch wenn es möglich sein könnte
Man braucht schließlich eine neue Maske/Chip dafür.
Meine Aussage war lediglich, dass nur wegen HBM keine neue Architektur oder Änderungen garantiert sind.
Natürlich hat am Ende AMD Fiji mit HBM konzipiert.
Entsprechende Berechnungen und Simulationen vollzogen, wie viele ALUs, ROPs, L2-Cache..., Sinn machen und was man letztendlich auch reinpacken kann.
Wenn Fiji ein echtes Monster darstellen möchte, dann wäre es ein 8-Fach Front-End und 128-ROPs mit 4096 ALUs.
AMD könnte aber Front/Back-End weiterhin relativ schlank halten und einfach versuchen durch interne Verbesserungen am Front-End und durch bessere Versorgung des Back-Ends durchzukommen.
Die Neugierde ist schon schrecklich, wenn es gar keine Informationen diesbezüglich gibt, nicht einmal unseriöse Gerüchte.
Locuza
Lötkolbengott/-göttin
AW: AMD Fiji: Offizieller Teaser, Unterstützung in GPU-Z
Das ist leider etwas schwer zu bewerten.
Man kann es aber grob überblicken.
Hier ist ein die-shot von Tahiti, welcher entsprechend eingefärbt wurde:
http://www.abload.de/img/nfqygvru4k.jpg
Grob gesagt besteht das Front-End aus dem Command-Processor und den Rasterizer/Geometry-Engines. (Rot + weiße Markierung.).
ROPs sind im Grunde das Back-End. (Gelb, wobei sie da auch paar andere Dinge mit markiert haben. )
Gipsel hat sich mal die Mühe gemacht, die Flächen auszurechnen:
3DCenter Forum - AMD/ATI - Die-Shots von Cape Verde, Pitcairn und Tahiti - Seite 2
Wenn Gipsel beim Raster/Front-End alles mitgezählt hat, sind das 18mm².
Hawaii hat doppelt soviele Raster/Geometry-Engines, sagen wir mal dennoch grob das doppelte, 36mm² und wenn Fiji abermals verdoppelt, eben 72mm².
Grob überschlagen wäre das schon viel Holz.
Aber das sollte man nicht als "guten" Maßstab nehmen.
Man kann das Layout optimieren, die Dichte erhöhen, sonstige Optimierungen machen damit das Front-End besser wird, ohne komplex mehrere Bestandteile davon skalieren zu müssen.
Von Hawaii gibt es leider keinen die-shot, man hat also keinen Zwischenschritt, um das ausgehend davon bewerten zu können.
Fiji spart sich das fette GDDR5-Interface, HBM sollte trotzt viel mehr Leitungen weniger Platz verbrauchen, auf der anderen Seite darf Fiji aber nicht zu groß werden.
AMD hat ein die-Limit wegen dem Interposer und HBM.
Theoretisch könnte man einen Fiji bis zu 600mm² vollpacken oder 570mm² oder irgendetwas sehr großes halt, aber dann gibt es nicht ausreichend Platz daneben für die HBM-Steine auf dem Interposer.
Entsprechend muss AMD vielleicht zwanghaft Kompromisse eingehen, was sie einbauen.
Das ist leider etwas schwer zu bewerten.
Man kann es aber grob überblicken.
Hier ist ein die-shot von Tahiti, welcher entsprechend eingefärbt wurde:
http://www.abload.de/img/nfqygvru4k.jpg
Grob gesagt besteht das Front-End aus dem Command-Processor und den Rasterizer/Geometry-Engines. (Rot + weiße Markierung.).
ROPs sind im Grunde das Back-End. (Gelb, wobei sie da auch paar andere Dinge mit markiert haben. )
Gipsel hat sich mal die Mühe gemacht, die Flächen auszurechnen:
3DCenter Forum - AMD/ATI - Die-Shots von Cape Verde, Pitcairn und Tahiti - Seite 2
Wenn Gipsel beim Raster/Front-End alles mitgezählt hat, sind das 18mm².
Hawaii hat doppelt soviele Raster/Geometry-Engines, sagen wir mal dennoch grob das doppelte, 36mm² und wenn Fiji abermals verdoppelt, eben 72mm².
Grob überschlagen wäre das schon viel Holz.
Aber das sollte man nicht als "guten" Maßstab nehmen.
Man kann das Layout optimieren, die Dichte erhöhen, sonstige Optimierungen machen damit das Front-End besser wird, ohne komplex mehrere Bestandteile davon skalieren zu müssen.
Von Hawaii gibt es leider keinen die-shot, man hat also keinen Zwischenschritt, um das ausgehend davon bewerten zu können.
Fiji spart sich das fette GDDR5-Interface, HBM sollte trotzt viel mehr Leitungen weniger Platz verbrauchen, auf der anderen Seite darf Fiji aber nicht zu groß werden.
AMD hat ein die-Limit wegen dem Interposer und HBM.
Theoretisch könnte man einen Fiji bis zu 600mm² vollpacken oder 570mm² oder irgendetwas sehr großes halt, aber dann gibt es nicht ausreichend Platz daneben für die HBM-Steine auf dem Interposer.
Entsprechend muss AMD vielleicht zwanghaft Kompromisse eingehen, was sie einbauen.
Zuletzt bearbeitet:
Ähnliche Themen
