R1000 Spekulationsthread

Also 35% mehr Performance im gleichen Node (falls es so sein soll) scheinen mir nicht recht wahrscheinlich bzw. eher zu viel. Auch wenn Nvidia zeigt, dass bei niedrigerem Takt, der näher am Effizienzsweetspot ist, und dafür mehr Shader, durchaus einiges an Potential vorhanden wäre...

Wenn, dann hätte Kepler und GCN(1.0) je einen eigenen "Effizienzsweetspot". Möchte man deiner Aussage unbedingt widersprechen, könnte man auch die gegenteilige Behauptung aufstellen, dass zahlreiche Kepler-Karten von Werk aus bereits ein höheres Stück über ihren Sweetspot hinaus takten.

GTX 680 OC vs. HD 7970 OC: Einstellungen für den Test
Die Tests finden nicht nur bei "Max OC" statt, wir haben uns auch angesehen, wie die Architekturen bei getrennter GPU- und RAM-Übertaktung skalieren. Die Maximalwerte wurden von uns anhand von Erfahrungswerten festgelegt: Die besten uns vorliegenden HD-7970-Grafikkarten stemmen 1.250/3.600 MHz, sofern man sie (laut)stark kühlt, die beiden GTX-680-Muster erreichen knapp 1.300/3.550 MHz. Dementsprechend duellieren sich die Kandidaten mit diesen Taktraten. Die Radeon HD 7970 startet dank ihres großen Potenzials folglich mit einem Vorteil, denn sie ist um +35 (GPU) respektive +31 Prozent (VRAM) übertaktet. Die Geforce GTX 680 legt (ausgehend vom Auto-Turbo) um lediglich um +16 (GPU) respektive +18 Prozent (VRAM) zu

aus http://www.pcgameshardware.de/Grafi...g-Test-Geforce-GTX-680-Radeon-HD-7970-875267/
Würden die im Raum stehenden Zahlen zutreffen, hätte
- Hainan mit den genannten 3,5 Mrd. Transistoren auf 270mm² im Vergleich zu Pitcarin immerhin 25% mehr Transistoren bei gut 27% mehr Fläche (könnte die µArch etwa leicht "aufgelockert" worden sein, um höhere Takte zu ermöglichen?), und
- Curacao mit 5,5 Mrd. Transistoren auf 420mm² hätte im Vergleich zu Tahiti (4,31Mrd, 365mm²) gut 27% mehr Transistoren auf 15% mehr Fläche (was erstmal als kleiner Widerspruch erscheinen mag, aber bei genauerem Hinsehen nur eine Angleichung der Transistordichte an den Wert von etwa 13 Mio / mm² bedeutet, ausgehend vom doch etwas "lockerer gestrickten" Tahiti mit 11,8 Mio / mm²).
Insofern scheinen mir die Performance-Hochrechnungen garnicht so verwegen. Mit rund 25% mehr (effektiven) Transistoren und 12% mehr Takt wären sogar +40% Grafik-Performance schon erreicht, gegeben die GPUs nuckeln nicht an irgendeinem Flaschenhals ;)
Einzig die dabei angegebene Leistungsaufnahme erscheint etwas schönfärberisch. Würde man hier ausgehend von Cape Verde die Performance-Indizes mit der Leistungsaufnahme in Relation setzen, könnte man Bonaire, stellvertretend für die übrigen Familienmitglieder von GCN(1.1?) in 28nm (optimiert), eine Steigerung der Performance/Watt um 22% zusprechen. Das reicht dann aber noch nicht an die Angegebenen Verbrauchszahlen.
 
Das sind Fakes, der Tahiti Nachfolger heiß Hawaii, nicht Curacao...

An sich klingen die Infos für mich nicht zwangsläufig unglaubwürdig, nur weil womöglich die Chip-Namen nicht stimmen. Interessant finde ich an den Gerüchten, dass vor allem der neue, relativ kleine 270mm²-Chip in verschiedenen Versionen weitgehend den Performance-Bereich abdecken soll. Der 420mm²-Highend-Chip steht nach der Message gar nicht so gut da und würde demnach nur in kleinen Mengen gebraucht und entsprechend teuer (wie eben auch Nvidias Titan) vermarktet. Ob ein Faker auf so eine Kombination gekommen wäre? Die abgeleiteten Performance-Erwartungen wären ja auch nicht unbedingt unglaubwürdig.
 
Kannst du das mal erklären?
4 CUs bilden bei GCN eine Einheit.
Instruction cache und scalar data cache werden von 4 CUs geteilt.
Man kann auch nur 3 CUs anbinden, so wie bei Pitcairn oder Cape Verde, dass führt dann zu einer etwas anderen Balance.
Aber was soll dann bei 36 CUs geschehen? Sollen dann 2 CUs pro Seite angeschlossen werden, an 16KB/32KB I$/K$? Das wäre von der Arbeitsverteilung einfach Müll.
Die "saubere" Alternative wäre auf jeder Seite 12 CUs im Dreierverbund zu verbauen, damit man eine gerade Balance hat, aber AMD hat sich ja schon etwas beim Viererverbund dabei gedacht, gibt es immerhin gerade Teiler.
So ein Verhältnis wäre aus meinen Augen unwahrscheinlich, vor allem nur ein High-End-Chip. Curacao PRO würde da definitiv fehlen.
Dazu noch falsche Codenamen, wieso sollte ich das ganze dann als wahrscheinlich ansehen?

Ob ein Faker auf so eine Kombination gekommen wäre? Die abgeleiteten Performance-Erwartungen wären ja auch nicht unbedingt unglaubwürdig.
Du kannst doch alles mögliche auf ein Blatt Papier schreiben und versuchen die TF und Bandbreiten in ein "passendes" Verhältnis zueinander zu setzen und dazu noch eine TPD schreiben.
Die News-Seiten würden dir wohl jede Kombination durchgehen lassen, die halbwegs im Rahmen wäre.
 
Zuletzt bearbeitet:
4 CUs bilden bei GCN eine Einheit.
Instruction cache und scalar data cache werden von 4 CUs geteilt...
Pitcairn und Tahiti haben 2 "Raster Engines" (der Block, der auf den netten Bildchen etwa ACE, GE, Rasterizer und die Verbindung zu den Einheiten darstellen dürfte), aufgeteilt bei Pitcairn in 4 + 3 + 3 GCNs, das ganze mal 2, Tahiti hat ein runderes Verhältnis von (4 * 4) * 2.
Bei 3 "Raster Engines" spricht dann auch nicht viel gegen (4 * 3) * 3. Die Rechnung (4 * 4 + 2) * 2 ignoriert schlicht die Aufteilung in 3 Raster Engines.

Du kannst doch alles mögliche auf ein Blatt Papier schreiben und versuchen die TF und Bandbreiten in ein "passendes" Verhältnis zueinander zu setzen und dazu noch eine TPD schreiben.
Die News-Seiten würden dir wohl jeder Kombination durchgehen lassen, die halbwegs im Rahmen wäre.
Zugegeben, selbst für chinesische Fantasiezahlen aus dem linken Nasenflügel erscheinen die Specs relativ weltnah: mehr dürfte Design und Wirtschaftlichkeit nicht zulassen, mit weniger ist kein Blumentopf zu gewinnen. Die Angaben zu Stromverbrauch, aber auch die 15% Mehrperformance der HD8850 im Vergleich zu Pitcairn XT mit gleichen Specs sind dagegen mit einer gehörigen Prise Salz zu genießen.
 
4 CUs bilden bei GCN eine Einheit.
Instruction cache und scalar data cache werden von 4 CUs geteilt.
Man kann auch nur 3 CUs anbinden, so wie bei Pitcairn oder Cape Verde, dass führt dann zu einer etwas anderen Balance.
Oder auch 2 CUs wie bei Kabini.
Aber was soll dann bei 36 CUs geschehen? Sollen dann 2 CUs pro Seite angeschlossen werden, an 16KB/32KB I$/K$? Das wäre von der Arbeitsverteilung einfach Müll.
Die "saubere" Alternative wäre auf jeder Seite 12 CUs im Dreierverbund zu verbauen, damit man eine gerade Balance hat, aber AMD hat sich ja schon etwas beim Viererverbund dabei gedacht, gibt es immerhin gerade Teiler.
So ein Verhältnis wäre aus meinen Augen unwahrscheinlich,
Wieso, Du beschreibst doch gerade, wie die Lösung mit 36 CUs perfekt paßt?!? 3 Raster-Einheiten (je 16 Pixel pro Takt, also in der Summe 48 ), 3 Shaderarrays zu je 12 CUs bestehend aus 3 Gruppen zu je 4 CUs. Ergibt 36 CUs mit Vierergruppen aus CUs. Die Zahl der Rastereinheiten paßt auch zu den 48ROPs (ist aber keine Bedingung). Wo wäre das Problem?
40CUs mit 3 Rastereinheiten ist eventuell problematisch (weil nicht durch 3 teilbar, 4 Rastereinheiten gehen dann wieder sicher), allerdings ist nicht ganz klar, ob AMD die Shader in genau so viele Subarrays aufteilen muß, wie es Rastereinheiten gibt (bisher machen sie es so), oder ob das entkoppelt ist. Oder wie das Loadbalancing mit ungleich großen Subarrays funktioniert. Das Letzteres ganz gut funktionieren kann, zeigt ja nVidia.
vor allem nur ein High-End-Chip. Curacao PRO würde da definitiv fehlen.
Dazu noch falsche Codenamen, wieso sollte ich das ganze dann als wahrscheinlich ansehen?

Du kannst doch alles mögliche auf ein Blatt Papier schreiben und versuchen die TF und Bandbreiten in ein "passendes" Verhältnis zueinander zu setzen und dazu noch eine TPD schreiben.
Die News-Seiten würden dir wohl jeder Kombination durchgehen lassen, die halbwegs im Rahmen wäre.
Das ist das Hauptargument. Realistisch betrachtet sind das schlicht Spekulationen aus einem Forum ohne wirklichen Einblick in die tatsächlichen Gegebenheiten, die jetzt ständig recycled wird.
 
1.Ist bei Kabini der I$/K$ Cache genau so groß oder wurde er halbiert?
2. Einfach wegen der Schönheit, wegen dem ungeraden Teiler bei den Caches, die Rasterizer habe ich aber nicht bedacht.
Aber du hast Recht, dass sind absolut vernachlässigbare Sachen, alles andere würde auch schön zusammenpassen.
 
GCN ist im neuen MacPro drin, wie es aussieht:
http://www.computerbase.de/news/2013-06/apple-mac-pro-mit-ivy-bridge-e-und-amd-grafik/

Zur Seite stellt man dem System maximal zwei FirePro-GPUs aus dem Hause AMD mit insgesamt 4.096 Shadern, was auf zwei parallel arbeitende Workstation-Modelle des Typs W9000 schließen lässt.

Offizielle Seite:
http://www.apple.com/mac-pro/
Dort wird unter Graphics geschrieben:
Traditionally, pro computers have relied primarily on the CPU for their computing power. But as GPU performance has dramatically increased, software developers have begun to leverage that power in their apps. With the new Mac Pro, we looked ahead and engineered an even more powerful GPU architecture. Not only does it feature a state-of-the-art AMD FirePro workstation-class GPU with up to 6GB of dedicated VRAM — it features two of them. With all that power, you’ll be able to do things like seamlessly edit full-resolution 4K video while simultaneously rendering effects in the background — and still have enough power to connect up to three high-resolution 4K displays.

Zur Seite steht Ivy-E.
 
Laut digitimes fängt Apple bei TSMC im Juli mit 20nm Risc Produktion an und Anfang 2014 soll die Produktion dann voll laufen.
http://www.digitimes.com/news/a20130624PD207.html
Mal gespannt, wann der erste Chip von AMD in 20nm kommt. Vor allem, ob es eine GPU oder eine ARM APU sein wird.
 
Hätte[/strike] habe [strike]fast mir schon gedacht, dass es ein Apfel wird, der hier für 20nm eine Lanze bricht.
.
EDIT :
.

Ich bleibe auch bei meiner Spekulation, dass es noch mindestens 1 Jahr dauern wird, bis wir 20nm AMD Produkte sehen werden. Ich tippe dabei auf eine GPU (Topmodell der Reihe, das dann auch für den professionellen Bereich vermarktet wird).
 
Zuletzt bearbeitet:
Ich tippe dabei auf eine GPU (Topmodell der Reihe, das dann auch für den professionellen Bereich vermarktet wird).

Denke ich auch aber nicht erst in einem Jahr, sondern die MacPro FirePro GPUs Ende Jahr.
 
Sollte sich der 28nm Refresh (für Herbst des Jahres?) bewahrheiten, würde dann gleich ein 20nm Modell folgen? Vor allem: wenn Apple gerade in die Risiko-Produktion mit kleinen Chips geht, und es durch die zusätzlichen Prozessschritte von 20nm gut 100 Tage dauert, bis allein die Wafer das Werk durchlaufen haben, müsste die Produktion für besagte 20nm GPUs (all die übrigen Schritte einbezogen) bereits ab etwa August anlaufen, damit Ende diesen Jahres FirePro's unter dem Weihnachtsbaum liegen. Ich sage mal: das ist nicht drin (lasse mich aber gerne eines besseren überzeugen).
 
Unter Dirk Meyer hätte ich ja auch gedacht, dass AMD auch bei der Risc Production einsteigt um möglichst früh erste 20nm Designs produzieren zu können.
Bei Rory denke ich eher, AMD wartet etwas bis der Prozeß ausgereifter ist und spart sich ein oder zwei Redesigns und somit Maskensätze.
Denke ja, dass TSMC die Erfahrungen der Risc Production in den 20nm Bibliotheken und Designrichtlinien für die anderen Kunden einarbeitet.
Von daher würde ich im Frühjahr noch nicht großartig mit 20nm bei AMD rechnen, höchstens in Produkten mit hoher Gewinnmarge.
 
Bei Rory denke ich eher

Der macht zu 1/3 das was der Gut zahlende Kunde will, wenn der die Anpassung zahlt, wird es gemacht wenn nicht wartet man darauf das andere die Fertigungsentwicklung zahlen.

wenn da Apple kommt und sagt wir wollen den Shrink, dann macht AMD das, sofern es technisch möglich ist.
 
Damit die Geschichte logisch auf geht bräuchte AMD eine eigene Fertigung und ein paar Jahre zeiut, die die Entwicklung neuer Fertigungsprozesse nunmal dauert.
 
Ich bezweifle sehr, dass 20nm-GPUs vor H2/14 kommen, wenn überhaupt. AMD muss Cash sparen und daher Risiken minimieren. Mit dem Design der GPUs auf 28nm kennt man sich bei AMD inzwischen aus und die 28nm-Wafer sollten langsam günstiger werden. Andererseits sollen die Vorteile von 20nm nicht sehr groß sein, sodass diese von den Mehrkosten der 20nm-Wafer womöglich erst mal mehr als aufgefressen werden. Unter solchen Rahmenbedingungen das Risiko einzugehen, einen neuen Prozess zu wagen, macht für mich einfach keinen Sinn.

Apple fängt dagegen mit einem Design bei TSMC neu an; dass man dann nicht mehr auf einen "alten" Prozess setzt, ist unter dieser Ausgangssituation verständlich.
 
Der 28nm Refresh war ursprünglich für ende 2012 oder Anfang 2013 geplant, warum sollte man einfach so den Refresh um 1 Jahr verschieben, bestimmt nicht weil man zuviele 28nm Chips auf Lager hat, wenn der 20nm Prozess bei TSMC läuft, dann besser direkt ein neuen Chip in 20nm entwickeln, 28nm ist nur Geldverschwendung, was soll der Chip bringen, +15% auf die Ghz Editon ist zuwenig, Tahiti XT ist auch ineffizient im vergleich zu den neuen Geforce 7xx, es gab auch Spekulationen das AMD den 28nm Refresh komplett gestrichen hat. In 20nm kann man 3072 Shader erwarten, das sind nur 50% mehr Einheiten, aber durch ein besseres Frontend skalieren die Recheneinheiten dann besser & effizienter als der Vorgänger, mit so einem Chip wird dann Geforce Titan keine Chance gegen AMD haben.

RV770 (55nm) = 956 Millionen Transistoren
RV870 (40nm) = 2,15 Milliarden Transistoren
Tahiti XT (28nm) = 4,31 Milliarden Transistoren
 
Zuletzt bearbeitet:

Also ich find's lustig :) Ist hald (und zwar offensichtlichI) auf Trash-Stile aufgezogen... Und in dieses Video fließen vll. ein paar 1000 Dollar, nicht 10.000e oder noch mehr, also die Sache ist frisst jetzt keine Budgets auf etc..

LG
 
Ich bezweifle sehr, dass 20nm-GPUs vor H2/14 kommen, wenn überhaupt

und gibts heute 9 monate später was neues von der R300 serie ?

die jetzigen chips sind bis auf tahithi ja technisch von ende 2011.

es ist einfach noch nie so lange still gewesen. ich glaube ich habe seit 14 jahren computer hobby zum ersten mal einen pc 3 jahre ohne austausch von hardware genutzt :D
 
Seit Rory ist es ziemlich still bei AMD geworden. Etwas schade, hat man doch kaum Material für Spekulationen.
Ich erwarte jedoch mit 20nm Ende dieses Jahres keine großen Fortschritte. Die Architektur (GCN) scheint soweit bewährt als da noch große Änderungen kommen. Neue Features (Audio DSP, HSA) brauchen erst Software bevor sie Nutzen bringen.

Einen größeren Performanceschub erwarte ich erst mit FinFet (2015/16).
 
Na ja - wenn man Nvidias Maxwell (Einführung des GM107 auf der Geforce 750) als Vergleich heranzieht - dann gibt es durchaus naheliegende Verbesserungen, die auch bei AMD sofort was bringen könnten.

Zum einen deutlich mehr interner Cache im Grafikchip, zum anderen verbesserte Strombedarfseigenschaften - insbesondere bei Blu-ray und Konsorten.

MFG Bobo(2014)
 
Die Architektur mag sich bewährt haben, aber es gibt immer Raum für Optimierungen. Die große Herausforderung der 20nm Generation ist sowieso die Speicherbandbreite. Nvidia versucht dies anscheinend durch große Chaches zu kompensieren, aber was wird AMD machen? Amd war schon immer aggressiver bei der Einführung neuer Speichertechnologien, also unter Umständen schon Gddr6 oder HMC oder sowas?
 
Instruction Scheduling

Um auch den einzelnen Shader effektiver zu machen, hat NVIDIA einige Veränderungen beim "Workload Balancing", der "Clock-Gating Granularity", dem "Instruction Scheduling" und den "Instructions Issued per Clock Cycle" vorgenommen. Letztgenannter Punkt ist zwar im Vergleich zu "Fermi" und "Kepler" identisch geblieben, allerdings hat NVIDIA die Latenzen reduziert um die Effektivität zu steigern. Das bessere "Workload Balancing" gelingt unter anderem durch eine andere Aufteilung durch die "Warp Scheduler". Zwar sind auch weiterhin vier "Warp Scheduler" pro SMM vorhanden (wie auch bei den SMX-Clustern in der "Kepler"-Architektur), allerdings teilen sich die vier "Warp Scheduler" nicht mehr auf alle Shadereinheiten auf, sondern sind fest bestimmten Shadern zugeordnet (angepasst an die jeweilige Weite des "Warp Scheduler"). Weiterhin sind die "Warp Scheduler" in der Lage, sowohl mathematische Operationen an die Shader weiterzuleiten als auch Speicher-Operationen an die "Load/Store-Units" zu liefern. Allerdings ist es dem "Warp Scheduler" nur möglich, bei einer Art Operation alle Shadereinheiten auszulasten.

Bessere Auslastung bei bestehendem Code

Oben genannte Anpassungen sind ausschließlich auf eine bessere Anpassung der Hardware zurückzuführen. Schlechter Code kann aber weiterhin dazu führen, dass die Architektur ihre Vorteile nicht ausspielen kann. Geht man allerdings davon aus, dass sich bestehender Code nicht ändert, hat NVIDIA dennoch weitere Verbesserungen an den Registern vorgenommen. Keinerlei Unterschiede gibt es bei "Maxwell" und "Kepler" in den 64k 32-Bit Registern, den 64 Warps sowie den maximalen Registern pro Thread von 255. Verdoppelt hat sich die Anzahl der aktiven Thread-Blöcke pro Streaming Multiprozessor auf insgesamt 32. Dies dürfte sich vor allem dann positiv auswirken, wenn ein kleiner Thread 64 oder weniger Blöcke belegt.

Dedicated Shared Memory

Sowohl "Maxwell" als auch "Kepler" verfügen über 64 kB Shared Memory. Allerdings teilt sich dieser bei "Kepler" zu 48/16 kB zwischen dem L1-Cache und einem Cluster-weiten Shared Memory auf. Bei "Maxwell" sind L1-Cache und Texture-Cache in einer Einheit vereint, wobei das Limit pro Thread-Block in der Belegung weiterhin bei 48 kB liegt.

Um diesen Shared Memory weiterhin effizient nutzen zu können verfügt "Maxwell" über einige sogenannte "Atomic Operationen" für 32-Bit-Integer-Operationen und "Native Shared Memory 32 Bit and 64 Bit compare-and-swap (CAS)"-Operationen. Diese mussten bei "Kepler" und "Fermi" noch über ein kompliziertes "Lock/Update/Unlock"-Prinzip abgearbeitet werden und belegten daher deutlich mehr Platz im Speicher.

Dynamic Parallelism

Befehle und Daten, die an die GPU geliefert werden, können verschachtelt aufgebaut sein (beispielsweise wenn Berechnungen von den Ergebnissen anderer Berechnungen abhängig sind) und somit die verschiedenen Threads der GPU über eine bestimmte Laufzeit blockieren. NVIDIA versuchte dem über Optimierungen in der CUDA-Schnittstelle entgegen zu wirken.

Mit dem "Dynamic Parallelism" kann die GPU selbst diese Verschachtelungen auflösen. Dies sorgt allerdings auch für etwas mehr Programmieraufwand, denn der Programmierer muss nun beachten, dass die GPU sich nicht selbst den Speicher volllaufen lässt. Sollte es dazu kommen, dass die selbst angelegten Threads den freien Speicher der GPU überschreiten, werden die Daten über die PCI-Express-Schnittstelle ausgelagert, was den gesamten Prozess wiederum verlangsamt. Die GPU bestimmt dabei selbst, in wie weit sie die Verschachtelung zulässt. NVIDIA will und kann keine Raster vorgeben, da man damit auch die Leistung in ungünstigen Szenarien einschränkt.

 
Zurück
Oben Unten