Maxwell - GM1xx (H1/2014) / GM2xx (H2/2014)

[HPVD]

Details Nvidia Maxwell

Viel gibt es noch nicht an Infos und Spekulationen, aber wir können ja schon mal anfangen zu sammeln:

Erscheinungsjahr: H1 2014
(Stand Dez 2012)

DP Leistung pro Watt: > 14 GFLOPS/Watt
vergl. Kepler ca. 5GFLOPS/Watt

Compute Capability: 5.0 ?
vgl: Kepler GK110/K20: CC 3.5
http://www.geeks3d.com/20121112/nvidia-r310-54-beta-graphics-drivers-for-windows/#comment-26221

Fertigungstechnologie: 20 nm
http://www.computerbase.de/news/2012-08/kommt-nvidias-gk110-fuer-desktop-pcs-nicht-vor-maerz-2013/

Interface: wahrscheinlich PCIe 3.0,
da 4.0 Geräte es für 2015 erwartet werden
http://www.zdnet.de/41558407/pci-express-4-0-liefert-doppelte-bandbreite-von-pcie-3-0/

Speicher: wahrscheinlich GDDR5,
da GDDR6 erst 2014 startet
http://vr-zone.com/articles/gddr6-memory-coming-in-2014/16359.html


wer weiß mehr?

Bekannte Maxwell GPUs:

GM107 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9968616#post9968616)
GM108 (576SPs 384SPs bzw. 3 Cluster SMM, 64-Bit) (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9968893#post9968893)
GM200
GM204
GM206 (http://www.geeks3d.com/20140208/gpu-caps-viewer-1-20-0-test-version-new-online-gpu-database-with-opengl-and-opencl-info/#comment-37277)


Details GM204:

256-Bit
laut Leak über 400mm² Die-Size (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10267161#post10267161)


Interessante Details aus der CUDA.dll:
It’s now clearly exposed in NVCUDA.DLL v334.67

push offset D__cuda_arch_8 ; “-D__CUDA_ARCH__=500″
push offset Maxwell ; “Maxwell”
push offset Compute_50 ; “compute_50″

The lab rats at NVIDIA are already playing with a bunch of Maxwells
GM206 GM204 GM200 GM108 GM107

Also CC 3.2 has been removed, instead CC 3.7 appears. I guess that’s the CC of “Aries” or “Mary-Kate” and “Ashley”.
http://www.geeks3d.com/20140208/gpu-caps-viewer-1-20-0-test-version-new-online-gpu-database-with-opengl-and-opencl-info/#comment-37277

[Ailuros]

Ich befuerchte dass der Thread anhand fehlender Einzelheiten sich schwer weiterbewegen wird fuer die naechsten 8-12 Monate.

[Duplex]

Ich hoffe Maxwell wird ein 30SMX Chip, also GK110 x 2, in 20nm könnte der Chip mit besseren Frontend noch effizienter als GF100 oder GK110 sein.
Bei GF110 hat Nvidia die Shader auch über Faktor2 gegenüber Gt200 steigern können, warum sollte das jetzt bei Kepler> Maxwell anders sein?

[Ailuros]

Ich hoffe Maxwell wird ein 30SMX Chip, also GK110 x 2, in 20nm könnte der Chip mit besseren Frontend noch effizienter als GF100 oder GK110 sein.
Bei GF110 hat Nvidia die Shader auch über Faktor2 gegenüber Gt200 steigern können, warum sollte das jetzt bei Kepler> Maxwell anders sein?

Dilemma: was ist Dir lieber eine sehr grosse Anzahl an clusters (wobei der Abstand von cluster0 zu clusterN uebermaessig gross ist) oder einfach weniger und fettere clusters?

[HPVD]

Ich befuerchte dass der Thread anhand fehlender Einzelheiten sich schwer weiterbewegen wird fuer die naechsten 8-12 Monate.
ja das mag sein.
Trotzdem wir man sicherlich noch ein paar Info Stückchen zusammen tragen können die dann mit neuen "Info-Tröpfelchen" Stück für Stück ein genauers Bild ergeben werden... halt wie immer Spekulationen :biggrin:

[HPVD]

nicht taufrisch aber bestimmt noch aktuell:

"Der von Nvidia für das Jahr 2013(=>2014) angekündigte Grafikchip "Maxwell" wird zusätzlich zum GPU-Design auch integrierte ARM-Rechenkerne mitbringen. Dies bestätigte Nvidia-Mitarbeiter Michael Rayfield, seines Zeichens General Manager für den Mobile-Geschäftssektor, gegenüber der Webseite Hexus.net .

Laut Rayfield ist Maxwell die erste Implementation des vor kurzem auf der CES (Las Vegas) von Nvidia-Chef Jen-Hsun Huang angekündigten "Project Denver": Nvidia will für Desktop- und Supercomputer geeignete Kombi-Prozessoren mit ARM-CPU- und Nvidia-GPU-Kernen erschaffen."

http://www.heise.de/newsticker/meldung/Nvidia-bestaetigt-Auf-Maxwell-GPUs-sitzen-auch-ARM-Prozessorkerne-1172923.html

[AnarchX]

In der Spekulation sollten auch nicht die integrierten ARM-Cores fehlen: http://www.xbitlabs.com/news/cpu/display/20110119204601_Nvidia_Maxwell_Graphics_Processors_to_Have_Integrated_ARM_General _Purpose_Cores.html
edit: schon bemerkt... ;)

[HPVD]

welche Aufgaben könnten denn diese Arm-Kerne übernehmen?

[AnarchX]

Im Endeffekt könnten sie eine Host-CPU ersetzen. Und zudem könnte man vielleicht auch das Sheduling etwas flexibilisieren, ähnlich wie Xeon Phi.

[boxleitnerb]

Und das bringt im Grafikbereich auch was? Potenzial sollte genug da sein, denn mit doppelt soviel Rechenleistung erreicht man jetzt selbst in neuen Spielen, die nicht so krass an der Bandbreite hängen, maximal 50% mehr Leistung (GTX580 vs GTX680).

[HPVD]

aus den 14-16 GFLOPS/Watt folgt eine DP Leistung bei typischen 225W
von 14GFLOPS/Watt*225Watt = 3,15 TFLOPS DP
das wäre ca. Faktor 3 von Kepler GK110

[HPVD]

mögliche Details zu den ARM Kernen:

""Maxwell" wird dann 2014 ein komplett neues Design sein. Erwartet wird hier auch die Verwendung des "Project Denver". Viel ist dazu noch nicht bekannt. Offenbar verwendet NVIDIA aber ARM-Kerne auf Basis der 64-Bit-Architektur ARMv8-A, die unter den Codenamen "Atlas" und "Apollo" geführt werden. "Atlas" und "Apollo" könnten als Duo eingesetzt werden, während sich erstgenannter um die rechenintensiven Aufgaben kümmert, sorgt zweitgenannter mit besonderen Stromspartechniken für einen besonders geringen Verbrauch."

http://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/24541-roadmap-vergleich-nvidia-verschiebt-maxwell.html

[Ailuros]

Und das bringt im Grafikbereich auch was? Potenzial sollte genug da sein, denn mit doppelt soviel Rechenleistung erreicht man jetzt selbst in neuen Spielen, die nicht so krass an der Bandbreite hängen, maximal 50% mehr Leistung (GTX580 vs GTX680).

Ich wuerde eher fragen ob das Resultat bzw. die ARM cores wirklich gegen Intel's zukuenftige high end CPUs fuer general processing ueberhaupt konkurrieren kann.

Sonst hinkt der obrige Vergleich IMO; klar kommt nicht mehr als maximal 50% mehr Leistung raus wenn man bei gleicher Bandbreite eine vorige high end SKU mit einer zeitigen performance SKU vergleicht.

Bandbreite macht mir persoenlich bei Maxwell keine besondere Sorge; wenn das ganze Paket als SoC ankommt koennte ich an so manchen anderen Kopfschmerz denken. ARM custom cores koennen zwar theoretisch klein sein, aber bei N Anzahl der cores ist die Summe auch nicht mehr gering und beisst eben von der die area fuer die eigentliche GPU schon ein gewisses Prozentual ab. Noch dazu kommt wohl dass 20HP in einem ziemlich miserablen Zustand ist nach dem ueblichen Hintergrund-gefluester.

[HPVD]

weiter mögliche Details zu den Arm Kernen wenn sie aus dem Projekt Denver kommen:

Project Denver is an ARM architecture CPU being designed by Nvidia, targeted at personal computers, servers, and supercomputers. The CPU package will include an Nvidia GPU on-chip.[1]

The existence of Project Denver was revealed at the 2011 Consumer Electronics Show[2]. In a March 4th 2011 Q&A article CEO Jen-Hsun Huang revealed that Project Denver is a five year 64-bit ARM architecture CPU development on which hundreds of engineers had already worked for three and half years and which also has 32-bit ARM architecture backwards compatibility.[3]

The Project Denver CPU internally translates the ARM instructions to an internal instruction set, using firmware in the CPU.[4]

According to Charlie Demerjian, Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARM-64 instruction set because Nvidia could not obtain a license to Intel's patents.[4]

http://en.wikipedia.org/wiki/Project_Denver

[Leonidas]

Die eigentliche Frage zu Maxwell ist doch: Geht NV wieder die Kepler-Strategie? Weil es macht ja durchaus Sinn, in einer neuen Fertigung nicht zuerst einen 550mm²-Chip rauszubringen, sondern diesen erst später aufzulegen, wenn die Fertigung halbwegs solide ist.

Gut möglich, daß wir Sommer 2014 wieder nur einen GM104 sehen, der nur 2/3 dessen offenbart, was Maxwell insgesamt leisten könnte.

[Ailuros]

Die eigentliche Frage zu Maxwell ist doch: Geht NV wieder die Kepler-Strategie? Weil es macht ja durchaus Sinn, in einer neuen Fertigung nicht zuerst einen 550mm²-Chip rauszubringen, sondern diesen erst später aufzulegen, wenn die Fertigung halbwegs solide ist.

Na hoffentlich wird sich NV in dem Fall erstmal in der 550mm2 Grenze unter 20nm halten koennen. Unter 50mm2 kann ich mir schwer vorstellen dass 8 higher end + 8 lower end ARM custom cores unter 20nm einnehmen. IMHO ist die Antwort zur Frage (ueberhaupt anhand der 20nm Problematik) ja, obwohl sich diesmal NV vielleicht nicht ausschliesslich auf TSMC verlassen koennte, was aber auch ziemlich viel mehr kostet einen chip fuer N verschiedene libraries auszulegen.

Gut möglich, daß wir Sommer 2014 wieder nur einen GM104 sehen, der nur 2/3 dessen offenbart, was Maxwell insgesamt leisten könnte.

Tja mit oder ohne CPUs? :freak: Im ersten Fall will ich persoenlich nichts davon wissen.

[boxleitnerb]

Ich wuerde eher fragen ob das Resultat bzw. die ARM cores wirklich gegen Intel's zukuenftige high end CPUs fuer general processing ueberhaupt konkurrieren kann.

Sonst hinkt der obrige Vergleich IMO; klar kommt nicht mehr als maximal 50% mehr Leistung raus wenn man bei gleicher Bandbreite eine vorige high end SKU mit einer zeitigen performance SKU vergleicht.

Bandbreite macht mir persoenlich bei Maxwell keine besondere Sorge; wenn das ganze Paket als SoC ankommt koennte ich an so manchen anderen Kopfschmerz denken. ARM custom cores koennen zwar theoretisch klein sein, aber bei N Anzahl der cores ist die Summe auch nicht mehr gering und beisst eben von der die area fuer die eigentliche GPU schon ein gewisses Prozentual ab. Noch dazu kommt wohl dass 20HP in einem ziemlich miserablen Zustand ist nach dem ueblichen Hintergrund-gefluester.

Meinst du, wenn man GK104 genausoviel Bandbreite/Flop geben würde wie GF110, dass GK104 dann entsprechend skalieren würde, also doppelt so schnell wäre? Kann mir das nicht so recht vorstellen.

[HPVD]

Die eigentliche Frage zu Maxwell ist doch: Geht NV wieder die Kepler-Strategie? Weil es macht ja durchaus Sinn, in einer neuen Fertigung nicht zuerst einen 550mm²-Chip rauszubringen, sondern diesen erst später aufzulegen, wenn die Fertigung halbwegs solide ist.

Gut möglich, daß wir Sommer 2014 wieder nur einen GM104 sehen, der nur 2/3 dessen offenbart, was Maxwell insgesamt leisten könnte.

jo ... oder: schaffen sie es durch die Verschiebung auf 2014 mehrere Varianten gleichzeitig zu bringen?

=> wann ist denn mit der Fertigung von größeren 20nm Strukturen generell zu rechnen?

[Ailuros]

Meinst du, wenn man GK104 genausoviel Bandbreite/Flop geben würde wie GF110, dass GK104 dann entsprechend skalieren würde, also doppelt so schnell wäre? Kann mir das nicht so recht vorstellen.

Du meinst wohl GK110 (denn GF110 hat schon so viel Bandbreite wie GK104); die Antwort ist immer noch nein. Aber damit es vielleicht fuer Dein Beispiel hilft, wenn es zu "bis zu" Leistung kommt ist GK110 eben nicht "nur" 2x Mal schneller als GF110 und das eben bei 50% mehr vorgesehener Bandbreite bei GK110.

[boxleitnerb]

Ne, ich schrieb "Bandbreite/Flop", also ein hypothetischer mit 380-400 GB/s Bandbreite ausgestatteter, aber ansonsten unveränderter GK104, der dann doppelt so schnell wäre die ein GF110 (Fermi) - 3 TFLOP vs 1.5 TFLOP

Meine Frage ist im Grunde die:
GK104 bringt seine Rechenleistung nicht im selben Maß auf die Straße in 3D wie GF110. Liegt das ausschließlich an der Bandbreite oder geht Potenzial noch woanders verloren, eben im Scheduling z.B.?

[Ailuros]

Ne, ich schrieb "Bandbreite/Flop", also ein hypothetischer GK104 mit 400GB/s Bandbreite.

Meine Frage ist im Grunde die:
GK104 bringt seine Rechenleistung nicht im selben Maß auf die Straße in 3D wie GF110. Liegt das ausschließlich an der Bandbreite oder geht Leistung noch woanders verloren?

Nein es liegt IMHO nicht nur an der Bandbreite sondern an mehreren Faktoren. GF114 hat 1.2 TFLOPs gegen 1.5 beim GF110 und der erste kann auch nicht die Differenz von durchschnittlich >40% zum zweiten ueberbruecken, selbst wenn Du einem GF114 192GB Bandbreite schenken wuerdest.

Du packst das Ganze einfach am falschen Bein: GK104 ist mit seinen 8 SMXs mehr oder weniger ein aufgepumpter 8 SM GF114.

[boxleitnerb]

It’s hardly news, but Nvidia will keep its business at TSMC in the post 28nm-world.

In an interview with Korean daily Hankook Ilbo, Nvidia exec Phil Eisler said the company has approved TSMC’s 20nm capacity. Eisler noted that Nvidia evaluated all other foundry options and came to the conclusion that TSMC is still the best choice.

Interestingly, Samsung is said to be in the running for Nvidia’s 20nm contracts as well. Although Samsung generates a lot of buzz with its Exynos SoCs and Apple’s A-series chips, it share in the foundry market is very low. Furthermore, it has been rumoured for months that Apple could move its business to TSMC.

More here.


http://www.fudzilla.com/home/item/29715-nvidia-on-board-for-tsmc%E2%80%99s-20nm-process

[HPVD]

http://www.fudzilla.com/home/item/29715-nvidia-on-board-for-tsmc%E2%80%99s-20nm-process

damit wissen wir nach wessen Fertigungszeitplan für 20nm wir schauen müssen.

Aktuell dazu:
"Rumor: TSMC to build quad-core 20nm chips for Apple by late 2013:
Apple began verifying TSMC's 20nm process in August this year (2012) and may begin risk production in November with the process," the report said. "Volume production is expected to start in the fourth quarter of 2013..."
http://appleinsider.com/articles/12/10/12/rumor-tsmc-to-build-quad-core-20nm-chips-for-apple-by-late-2013

=> damit sollte H1 2014 ein Maxwell in 20nm doch auch fertigungstechnisch möglich sein...

[Ailuros]

damit wissen wir nach wessen Fertigungszeitplan für 20nm wir schauen müssen.

Aktuell dazu:
"Rumor: TSMC to build quad-core 20nm chips for Apple by late 2013:
Apple began verifying TSMC's 20nm process in August this year (2012) and may begin risk production in November with the process," the report said. "Volume production is expected to start in the fourth quarter of 2013..."
http://appleinsider.com/articles/12/10/12/rumor-tsmc-to-build-quad-core-20nm-chips-for-apple-by-late-2013

=> damit sollte H1 2014 ein Maxwell in 20nm doch auch fertigungstechnisch möglich sein...

Theoretisch ja, aber auch nur wenn TSMC es rechtzeitig schafft 20HP anstaendiger auf die Beine zu stellen. Bis jetzt gibt es kein einziges Hintergrund-gefluester dass NICHT bestaetigt dass 20HP in einem schlechteren Zustand ist als 28HP im vergleichbaren Zeitraum.

Wenn der Prozess jetzt noch problematischer sein sollte (ist auch keine besondere Ueberraschung denn Prozesse sind per se problematischer je kleiner sie werden) und TSMC erhoeht nochmal die Kosten fuer die tools werden sich IHVs wohl eher ihre Zeit damit nehmen denn keiner kann sich ueberteuerte chips so leicht leisten. So wie es momentan aussieht sollte man froh sein wenn performance bis low end 20nm chips in H1 2014 erscheinen. Von hochkomplizierten high end chips wuerde ich sicherheitshalber schon jetzt nicht vor H2 2014 rechnen und dann wieder fraglich ob ueberhaupt schon fuer desktop.

[Ronny145]

Wenn man die üblichen Verschiebungen mit einkalkuliert, würde ich auch eher 2H 2014 als realistisch sehen, vorher nicht. Aber vielleicht überrascht uns TSMC diesmal, wer weiß. Darauf wetten würde ich nicht nach dem schleppenden 28nm Start.

[boxleitnerb]

Erste Maxwell Chips noch in 28nm?

The more interesting news is that the initial Maxwell parts will be made on TSMC’s 28nm process, not 20nm as is widely rumored.
http://semiaccurate.com/2012/12/06/nvidias-maxwell-process-choice/

So könnte man früh launchen, und der 28nm Prozess mit dieser Reife könnte nicht so fürchterlich weit vom 20nm Prozess entfernt sein, was Kosten und Perf/W angeht, vor allem wenn 20nm so mies ist, wie es hier rumort wird.
Nachteil: Legt man dieselben Chips nochmal für 20nm auf, wirds natürlich teuer. Vielleicht eine Art Tick-Tock Strategie?

Edit:
AMD muss Charlie die Kohle gestrichen haben, wenn er jetzt Geld für die Artikel verlangt :D

[Ailuros]

Erste Maxwell Chips noch in 28nm?


http://semiaccurate.com/2012/12/06/nvidias-maxwell-process-choice/

So könnte man früh launchen, und der 28nm Prozess mit dieser Reife könnte nicht so fürchterlich weit vom 20nm Prozess entfernt sein, was Kosten und Perf/W angeht, vor allem wenn 20nm so mies ist, wie es hier rumort wird.
Nachteil: Legt man dieselben Chips nochmal für 20nm auf, wirds natürlich teuer. Vielleicht eine Art Tick-Tock Strategie?

Ein interessanter Ausweg fuer zeitliche Maxwell performance SKUs Vorstellung ist es allemal. Ein direkter shrink danach ist alles andere als ein besonders grosses Problem.

Edit:
AMD muss Charlie die Kohle gestrichen haben, wenn er jetzt Geld für die Artikel verlangt :D

Werbung bringt nicht mehr genug um die Seite aufrecht zu erhalten und sie hatten nach Ihnen nur die Wahl fuer subscriptions oder dicht zu machen. Was jetzt im Rest des Artikels steht keine Ahnung.

[V2.0]

"Where GK114 ended up" - Hallo Charlie wo kann ich den Test eines GK114 lesen?

[Ailuros]

"Where GK114 ended up" - Hallo Charlie wo kann ich den Test eines GK114 lesen?

Er hatte einen Artikel ueber den angeblichen "GK114" geschrieben kurz nachdem er nur die ~15% Leistungssteigerung von Sea Islands meldete. Es ist wahr dass beide IHVs eine hoehe Leistungssteigerung im Visier hatten, aber es durch die Begrenzungen des Prozesses nicht moeglich waren.

Sonst theoretisch koennten sie schon 80% mehr perf/W mit Maxwell/Performance@28HP erreichen; nur hab ich den Verdacht dass der die einfach zu gross wird und es zu stark den Stromverbrauch beinflussen wird. Bei schaetzungsweise 400-450mm2 kann man wohl nicht mehr so leicht auf einen hypothetischen 2*6pin board form factor hoffen.

[boxleitnerb]

Wie soll das gehen, nochmal 80% mehr Effizienz im gleichen Prozess? Vor allem ggü. was, dem eh schon breiten GK110 oder dem recht hochgetakteten GK104? Der Tausch Perf/W <-> Perf/mm2 klappt nur bis zu einem gewissen Grad.

[Knuddelbearli]

breiter niedrig getaktet ist imemr energie effizeinter ^^

eine gpu mit 2x gk104 hardware und 25% weniger takt wäre vermutlich auch ~80% effizienter

[boxleitnerb]

Ja aber NOCH breiter wie GK110? GK110 wird von der Effizienz recht nah an GK104 liegen schätze ich, die kann man also als eine Einheit sehen, was Perf/W angeht. Und von da aus gesehen, kann ich mir keine weiteren massiven Steigerungen vorstellen.

[schreiber]

Ailuros spricht wohl von 20nm und nicht von 28nm...

[Ronny145]

Edit:
AMD muss Charlie die Kohle gestrichen haben, wenn er jetzt Geld für die Artikel verlangt :D


Hoffentlich fällt der Clown damit auf die Fresse.

[Ailuros]

Wie soll das gehen, nochmal 80% mehr Effizienz im gleichen Prozess? Vor allem ggü. was, dem eh schon breiten GK110 oder dem recht hochgetakteten GK104? Der Tausch Perf/W <-> Perf/mm2 klappt nur bis zu einem gewissen Grad.

Nochmal mein letzter Paragraph in meinem Beitrag vor diesem:

Sonst theoretisch koennten sie schon 80% mehr perf/W mit Maxwell/Performance@28HP erreichen; nur hab ich den Verdacht dass der die einfach zu gross wird und es zu stark den Stromverbrauch beinflussen wird. Bei schaetzungsweise 400-450mm2 kann man wohl nicht mehr so leicht auf einen hypothetischen 2*6pin board form factor hoffen.

Ich sagte lediglich dass es theoretisch moeglich ist wenn der chip auch analog gross sein wird; nicht dass es auch wirklich Sinn machen wird ueberhaupt im Vergleich zum GK110. Wie oben im fettgedruckten IMHO ab 400mm2 und aufwaerts braucht man dann 6pin+8pin und der TDP wird sich wohl nicht mehr unter 250W befinden.

Womoeglich breitere Architektur und marketingtechnisch mit GFLOPs/W haut das in so einem verdrehten Sinn schon hin.

Ja aber NOCH breiter wie GK110? GK110 wird von der Effizienz recht nah an GK104 liegen schätze ich, die kann man also als eine Einheit sehen, was Perf/W angeht. Und von da aus gesehen, kann ich mir keine weiteren massiven Steigerungen vorstellen.

Wieviel TFLOPs sind fuer den top dog Maxwell vorgesehen?

Ailuros spricht wohl von 20nm und nicht von 28nm...

Nein ich meinte schon 28Hxx.

[boxleitnerb]

Ich meinte es relativ. Du hast gesagt Perf/W, nicht absolute Performance. Darauf bin ich eingegangen :)

[Ailuros]

Ich meinte es relativ. Du hast gesagt Perf/W, nicht absolute Performance. Darauf bin ich eingegangen :)

NV bzw. Charlie meinten aber im gegebenen Fall GFLOPs/W. Mit dem gleichen Mist hat NV auch bei Kepler vor seiner Erscheinung geworben egal ob es eigentlich nur fuer Tesla/GK110 und hauptsaechlich fuer FP64 zutrifft.

[boxleitnerb]

GFLOPs/W ist doch Perf/W. Oder reden wir aneinander vorbei?
Auf welchen Chip hast du dich denn bezogen mit denen 80% mehr Effizienz?

[Coda]

GFLOPs/W und Performance/W ist nicht das selbe.

[Ailuros]

GFLOPs/W ist doch Perf/W. Oder reden wir aneinander vorbei?

Am Ende meinen wir das gleiche in der Debatte hier, aber in Echtzeit entspricht GFLOP/W nur unter Bedingungen zu perf/W. Im Fall von HPC und DP schon; in 3D eben nicht. NVIDIA meint mit Maxwell stets den top dog, wobei Charlie wohl nicht verstanden hat dass wenn sie tatsaechlich bei Maxwell mit 28nm anfangen dieses wohl nicht fuer den top dog sein kann.

Auf welchen Chip hast du dich denn bezogen mit denen 80% mehr Effizienz?

Maxwell performance oder mit dem heutigen Code-Gewarkel "GM104". Nochmal moeglich schon, aber IMHO eine Schnappsidee da sich ein sehr grosser 28nm performance Maxwell die wohl schwer im Bereich TDP in 3D von einem GK110 unterscheiden wird. Wenn ihnen Stromverbrauch diesmal relativ egal ist geht ein Maxwell performance chip unter 28HP schon; wenn jetzt AMD eine aehnliche Masche eingeht kein Problem. Im Gegenfall koennte es verdammt schwer aussehen mit allem Maxwell/28nm irgendwelche sehenswerte OEM/notebook deals zu gewinnen.

[Nightspider]

Falls 20nm noch später kommt und noch teurer wird am Anfang lohnt es sich vllt doch noch Maxwell als 600-650mm2 Schlachtschiff in den ergiebigen Server Markt zu bringen.

[AnarchX]

Wie könnten eigentlich die Cluster bei Maxwell aussehen?

Mit den 16 TMUs liegt man ja immernoch unter dem ALU:TEX-Verhältnis von AMD, also wohl eher keine Änderung.

Die PolyMorph-Engines sind ein sehr gelungener Ansatz, den man wohl beibehalten wird.

Bei den ALUs gibt es wohl den größten Spielraum. Wenn man bei NVs Roadmap den 20nm Prozess mit einem Faktor 2 herausrechnet, bleiben da 40% mehr Leistung pro Watt.
Im Endeffekt wäre es vielleicht keine schlechte Idee, ähnlich wie AMD die Granularität von 32 auf 64 zu erhöhen und gleichzeitig wieder das superskalare Sheduling von GF104+ über Board zu werfen.
Damit könnte man die ALUs auf 4 Stück pro SMX reduzieren, aber gleichzeitig die Peakleistung um 33% erhöhen.

[HOT]

Vielleicht bringt man die kleineren Modelle (G<irgendwas>104, 106 usw) noch in 28nm und das Schlachtschiff dann erstmals in 20nm. Das ist ja eh ein verändertes Design zu den Gamerdingern.

[Ailuros]

Falls 20nm noch später kommt und noch teurer wird am Anfang lohnt es sich vllt doch noch Maxwell als 600-650mm2 Schlachtschiff in den ergiebigen Server Markt zu bringen.

Ueber den Rand von den bisherigen ~600mm2 fuer bisherige TSMC Prozesse wuerde ich persoenlich nicht reichen, nichtmal sogar auf runde 600mm2.

Wenn NV alternativ zu 28nm greift dann nur anfangs IMHO und nur fuer alles =/< performance chips. Selbst bei 60nm/GT200/575mm2 war es schon ein ziemlich grosses Problem fuer sie, deshalb entschieden sie sich auch ab GF100 auf dem neuesten Prozess zu entwickeln. Als sie GT200 zur Massenproduktion schickten war 60nm ziemlich gut ausgereift und trotz allem kostete sie jeglicher die ueber $120 in der Herstellung mit nur ~52% durchschnittlichen wafer yields. Kein Wunder dass sie das Zeug so schnell wie moeglich auf 55nm schrumpften.

[Skysnake]

Falls 20nm noch später kommt und noch teurer wird am Anfang lohnt es sich vllt doch noch Maxwell als 600-650mm2 Schlachtschiff in den ergiebigen Server Markt zu bringen.
Und wer soll das Produzieren? Der Weihnachtsmann? :freak:

Alles >=600mm² ist völlig utopisch. Meines Wissens nach packen die Tools nicht mal so große DIEs. Mal ganz abgesehen von den Yields.

[AnarchX]

Wird wohl Zeit, dass die Interposer kommen:
90 bis 65nm kann man sicherlich mit einer >1000mm² Maske belichten und dort bringt man dann vier ~250mm² 20nm Dies auf, die auf Grund ihrer Größe eine vernünftige Yield-Charakteristik aufweisen.

[Skysnake]

nein kann man nicht, weils so große Masken nicht gibt....

[AnarchX]

Canon hat doch schon für einen Kamera-Sensor einen ganzen 300mm Wafer genutzt, insofern hat man da wohl schon Spielräume, wenn wohl auch nicht mit den Anlagen, die für normale ASICs genutzt wurden.
Wobei so ein Si-Interposer Wafer wohl momentan noch $10k Euro kosten soll: http://www.monolithic3d.com/2/post/2011/12/is-the-buzz-around-xilinxs-25d-fpga-justified.html

Auf wohl vorhandene 25x25mm Interposer, könnte man immerhin zwei ~210mm² Die setzen.

[Nightspider]

nein kann man nicht, weils so große Masken nicht gibt....

Und größere wird es auch nie geben weil sowas wie Fortschritt ja nicht existiert... :rolleyes:

Dramatische Situationen verlangen dramatische Mittel.

Die DIE-Größen sind die letzten 10 Jahre immens gestiegen und 550mm² wird nicht die Grenze bleiben.

Erst recht wenn man bei ~5-10nm am Ende angelangt ist wird man versuchen für den High-HighEnd / Server-Bereich noch leistungsfähigere Chips zu produzieren.

Und wenn der neue Fertigungsprozess nochmals deutlich teurer wird als der alte, könnte es für Nvidia rentabel sein im alten, günstigen, Fertiegungsprozess einen geringfügig größere Chip zu produzieren.
Und das wären gerade mal 10-20% mehr Fläche was im Umkehrschluss gerade mal 5-9% größere Achsenlängen bedeutet.

Spätestens wenn 2015 die 450mm Wafer in Masse vom Band laufen, wird man die Masken anpassen müssen.

Und wenn man an die Grenze bei 5-10nm kommt muss TSMC auch versuchen auf anderen Wegen mehr Geld einzunehmen. Das kann man indem man bei bisher gut funktionierenden Prozessen eben größere Wafer verwendet, größere Chips produziert, die man für mehr Gewinn verkaufen kann, und somit wenigstens einen geringen Fortschritt beibehält. Auch wenn die Entwicklung in dieser Richtung nur minimale Sprünge erlaubt.

Und in vielen Chip-Bereichen wird man eben die Fläche vergrößern müssen, wenn die Bauteildichte nicht mehr steigt.

Just my 2 Cents.

[Skysnake]

Da wird man eher Interposer verwenden, denn damit kannst du deine scheis teuren Tools weiter verwenden und musst dich auch nicht mit immer beschisseneren Yields rumärgern.

Die GESAMTE! Tool-Chain müsste ja komplett neu designed werden. Da tut man sich schon mit den 450mm Wafern MEHR als schwer, und da soll man mal kurz Riesen-DIEs bauen?

Und dass dann nur für ein paar Prozent mehr DIE-Größe... Interposer bieten da wenigstens eine vernünftige Steigerung.

[Nightspider]

Riesen DICE produziert man jetzt schon. Und wenn 550mm² bei dir nicht riesig sind, sind es 600 auch nicht. ;)

Wenn du per Interposer GPUs stapeln willst, frage ich mich wie du die Abwärme abführen willst ohne Wasserkühlung.

[AnarchX]

Riesen DICE produziert man jetzt schon. Und wenn 550mm² bei dir nicht riesig sind, sind es 600 auch nicht. ;)
Im Endeffekt sind wohl Ausflüge jenseits der 575mm² nur möglich, wenn TSMC entsprechend seine Fertigungsanlagen umbaut. Was eher langfristigen Charakter hat.
Aber da muss man auch wieder mehr Redundanz in die Chips verbauen, nicht dass ein Punktdefekt in einem kritischen Bereich so ein Silizium-Monster unbrauchbar macht.


Wenn du per Interposer GPUs stapeln willst, frage ich mich wie du die Abwärme abführen willst ohne Wasserkühlung.
Stapeln von GPU/CPU-Dies ist erst die nächste Stufe, davor stehen die Si-Interposer auf denen erst mal nur die Dies nebeneinander angeordnet werden. Wegen der Silizium-Basis sind da Interfaces mit hohen Bandbreiten und kleinen Anschlussflächen möglich. Das dürfte gegenüber PCIe schon mal ein deutlicher Sprung sein.

[Ailuros]

Riesen DICE produziert man jetzt schon. Und wenn 550mm² bei dir nicht riesig sind, sind es 600 auch nicht. ;)

Wenn du per Interposer GPUs stapeln willst, frage ich mich wie du die Abwärme abführen willst ohne Wasserkühlung.

Tut man, nur mit ca. 1 Jahr Verspaetung damit es rentabel herzustellen ist.

Bei Maxwell und 20HP kommen zwei Faktoren die Du uebersiehst noch dazu:

1. 20HP ist in einem schlechteren Zustand als es 28HP je wahr. Keine Ahnung ob und fuer welche Maxwell Varianten NV an 28nm denkt, aber aus der Luft gegriffen hat es Charlie sicher nicht. Schon allein die Tatsache dass NV (wohl teilweise) fuer 20nm Alternativen fuer einige Familien-Mitglieder von Maxwell denkt, ist schon eine Indizie dass es tatsaechlich nicht gut aussieht.

2. Bei Maxwell top dog soll noch eine gesunde Anzahl von ARM custom CPU cores dazukommen, wobei ich momentan 8 grosse und 8 kleinere CPU cores schaetzen sollte. Umsonst sind die Dinger auf jeden Fall nicht und wenn man diesmal fuer den top dog rechnet muss man wohl die die area fuer die CPU cores auch noch mitberechnen, plus womoeglich irgendwelche surrounding logic um das Ganze auf einem die unterzubringen.

Intel's Xeon Phi Co_Prozessor ist momentan die einzige Loesung fuer HPC die 600mm2 unter Intel's 22nm einnimmt; bei Vollausbau mit 300W TDP, wobei K20X mit 235W TDP um die 22% mehr GFLOPs DP erreicht. Moeglich ist vieles aber NV wird wohl nicht so daemlich sein und der Konkurrenz ihren GFLOPs/W Vorteil so leicht verschenken.

[Nightspider]

Bei Maxwell und 20HP kommen zwei Faktoren die Du uebersiehst noch dazu:

1. 20HP ist in einem schlechteren Zustand als es 28HP je wahr.

Das übersehe ich nicht. Davon habe ich ja eben gesprochen. Genau deswegen könnte es sich ja etwas mehr lohnen in 28nm einen noch größeren Chip zu bauen. Mit diesem hätte man ja dann die Zeit besser überbrücken können, bis man ~>500mm² Chips in 20nm produzieren kann. (Ich dachte 600-650mm² wären technisch jetzt möglich und nur wegen den Kosten noch nicht umgesetzt)

[Ailuros]

Das übersehe ich nicht. Davon habe ich ja eben gesprochen. Genau deswegen könnte es sich ja etwas mehr lohnen in 28nm einen noch größeren Chip zu bauen. Mit diesem hätte man ja dann die Zeit besser überbrücken können, bis man ~>500mm² Chips in 20nm produzieren kann. (Ich dachte 600-650mm² wären technisch jetzt möglich und nur wegen den Kosten noch nicht umgesetzt)

Es gibt keinen besonderen Grund dass diesmal NV nicht wieder den performance Maxwell chip dem top dog vorzieht, eher das grobe Gegenteil. In dem Fall und um keine besonders grosse Luecke zwischen Kepler und Maxwell zu lassen (bis Maxwell top dog endlich fuer desktop rentabel herstellbar ist unter 20nm) schaetze ich dass sie vielleicht kleineres Zeug als den top dog anfangs unter 28nm herstellen und erst dann damit auf 20nm springen wenn der Prozess halbwegs stabil auf seinen Beinen steht.

Seh es Dir anders an:

GF110 / 3.0b transistors / 530mm2@40nm
GK110 / 7.1b transistors / 550mm2@28nm

Fuer Maxwell top dog fuell mir spekulativ die Mitte aus und rechne den CPU Quark noch mit und dann koennen wir sehen wie man eine Elephanten in einen Haushalts-Kuehlschrank genau quetschen kann.

Die obrigen interposer Thesen von anderen oben sind zwar schoen und gut, aber ich waere mir persoenlich nicht so sicher dass NV irgendwelche Experimente eingehen wuerde mit einem so hochkompliziertem chip auf einem so wackeligen Prozess ohne dass sie frueher damit irgendwie bei bescheideneren chips herumgefunkelt haben. Wenn natuerlich irgend ein kleinerer Maxwell chip in der Zwischenzeit damit antanzen wuerde, dann aendert sich natuerlich so manches.

[AnarchX]

Separately, NVidia will describe a 20 Gbit/s serial die-to-die link made in 28-nm CMOS. It runs on a 0.9 V supply and has power efficiency of 0.54pJ/b. The interconnect might be part of Nvidia’s Project Denver, a still secretive family of processors merging ARM and graphics cores for everything from notebooks to supercomputers.
http://cdn.eetimes.com/electronics-news/4401645/Samsung-big-little--no-Haswell--Project-Denver-at-ISSCC?pageNumber=0

[Ailuros]

http://cdn.eetimes.com/electronics-news/4401645/Samsung-big-little--no-Haswell--Project-Denver-at-ISSCC?pageNumber=0

Die Einzelheiten darueber sind so wenig und wage dass die Godson Details in dem Artikel schon interessanter sind :D

[Skysnake]

Riesen DICE produziert man jetzt schon. Und wenn 550mm² bei dir nicht riesig sind, sind es 600 auch nicht. ;)

Wenn du per Interposer GPUs stapeln willst, frage ich mich wie du die Abwärme abführen willst ohne Wasserkühlung.
Das eine ist mit einem recht lange gereiften Prozess überhaupt möglich, das andere scheiter sehr sehr sehr sicher schon allein an den Tools....

Da liegen eben Welten dazwischen.

Zudem, wie gesagt, warum sich in derartige Grenzbereiche bewegen, wenn man es auch gleich richtig krachen lassen kann und Chips mit >>500mm² produzieren könnte. Also z.B. 1000mm² auf 4 Chips verteilt. Die Yields der einzelnen Chips sind gut, bleibt nur das Problem des Aufbringens auf den Interposer und eben die Zusatzkosten. Das ist aber noch immer um welten billiger als neue Tools und son Monsterchip von >600mm². Und naja, eben nochmal ne ganze Ecke größer.

Interposer lohnt sich halt erst, wenn man das so nicht mehr bewerkstelligt bekommt. Wenn man es einsetzt kann man aber halt direkt in die Vollen gehen.

Tut man, nur mit ca. 1 Jahr Verspaetung damit es rentabel herzustellen ist.

Bei Maxwell und 20HP kommen zwei Faktoren die Du uebersiehst noch dazu:

1. 20HP ist in einem schlechteren Zustand als es 28HP je wahr. Keine Ahnung ob und fuer welche Maxwell Varianten NV an 28nm denkt, aber aus der Luft gegriffen hat es Charlie sicher nicht. Schon allein die Tatsache dass NV (wohl teilweise) fuer 20nm Alternativen fuer einige Familien-Mitglieder von Maxwell denkt, ist schon eine Indizie dass es tatsaechlich nicht gut aussieht.

2. Bei Maxwell top dog soll noch eine gesunde Anzahl von ARM custom CPU cores dazukommen, wobei ich momentan 8 grosse und 8 kleinere CPU cores schaetzen sollte. Umsonst sind die Dinger auf jeden Fall nicht und wenn man diesmal fuer den top dog rechnet muss man wohl die die area fuer die CPU cores auch noch mitberechnen, plus womoeglich irgendwelche surrounding logic um das Ganze auf einem die unterzubringen.

Die Cores sind sicher in den SMX angeordnet. Wenn das ein synthetisches Design ist, kannste die auch gut mit rein packen, und "Lücken" ausfüllen.

Intel's Xeon Phi Co_Prozessor ist momentan die einzige Loesung fuer HPC die 600mm2 unter Intel's 22nm einnimmt; bei Vollausbau mit 300W TDP, wobei K20X mit 235W TDP um die 22% mehr GFLOPs DP erreicht. Moeglich ist vieles aber NV wird wohl nicht so daemlich sein und der Konkurrenz ihren GFLOPs/W Vorteil so leicht verschenken.
Naja, das muss sich erst noch zeigen. Aktuell steht auf der Green500 ein XeonPhi System GANZ oben. Von XeonPhi gibts ja verdammt viel unterschiedliches Zeug. Angefangen bei unterschiedlichen Bestückungen pro Node, dann noch komplett unterschiedliche KArten usw usw.

Man darf da halt nicht den Fehler machen, und die Flops von XeonPhi und GPUs direkt miteinander vergleichen. XeonPhi ist tendenziell halt unempfindlicher gegenüber Branches usw.

Das übersehe ich nicht. Davon habe ich ja eben gesprochen. Genau deswegen könnte es sich ja etwas mehr lohnen in 28nm einen noch größeren Chip zu bauen. Mit diesem hätte man ja dann die Zeit besser überbrücken können, bis man ~>500mm² Chips in 20nm produzieren kann. (Ich dachte 600-650mm² wären technisch jetzt möglich und nur wegen den Kosten noch nicht umgesetzt)
Die Tools sind meines Wissens nach auf maximal 550 bis 600mm² ausgelegt. Im Zuge von GF100 hies es mal, nVidia wäre da über die Grenze von TSMC leicht drüber raus, bzw haar scharf dran vorbei. Ne einzelner Maske/Chip bekommste mit den Tools, die überall rum stehen halt einfach nicht größer.

Ich glaube allerdings auch sehr stark, das wir noch eine dritte Generation von 28nm GPUs sehen werden.

Es gibt keinen besonderen Grund dass diesmal NV nicht wieder den performance Maxwell chip dem top dog vorzieht, eher das grobe Gegenteil. In dem Fall und um keine besonders grosse Luecke zwischen Kepler und Maxwell zu lassen (bis Maxwell top dog endlich fuer desktop rentabel herstellbar ist unter 20nm) schaetze ich dass sie vielleicht kleineres Zeug als den top dog anfangs unter 28nm herstellen und erst dann damit auf 20nm springen wenn der Prozess halbwegs stabil auf seinen Beinen steht.

Seh es Dir anders an:

GF110 / 3.0b transistors / 530mm2@40nm
GK110 / 7.1b transistors / 550mm2@28nm

Fuer Maxwell top dog fuell mir spekulativ die Mitte aus und rechne den CPU Quark noch mit und dann koennen wir sehen wie man eine Elephanten in einen Haushalts-Kuehlschrank genau quetschen kann.

Die obrigen interposer Thesen von anderen oben sind zwar schoen und gut, aber ich waere mir persoenlich nicht so sicher dass NV irgendwelche Experimente eingehen wuerde mit einem so hochkompliziertem chip auf einem so wackeligen Prozess ohne dass sie frueher damit irgendwie bei bescheideneren chips herumgefunkelt haben. Wenn natuerlich irgend ein kleinerer Maxwell chip in der Zwischenzeit damit antanzen wuerde, dann aendert sich natuerlich so manches.
Ich geh auch nicht davon aus, dass der TopDog sonderlich zeitnah erscheint.

Bzgl dem Interposer darfst du mich aber nicht falsch verstehen,
Ich sage NICHT: nVidia wird Maxwell mit Interposer bringen, sondern:
STATT nem >>600mm² Chip zu bringen, würde man Interposer verwenden. ;)

[Ailuros]

Die Cores sind sicher in den SMX angeordnet. Wenn das ein synthetisches Design ist, kannste die auch gut mit rein packen, und "Lücken" ausfüllen.

Bei Maxwell sollte es leichter sein die ALUs nochmals brutal in die Breite zu treiben selbst im Vergleich zu Kepler.

Naja, das muss sich erst noch zeigen. Aktuell steht auf der Green500 ein XeonPhi System GANZ oben. Von XeonPhi gibts ja verdammt viel unterschiedliches Zeug. Angefangen bei unterschiedlichen Bestückungen pro Node, dann noch komplett unterschiedliche KArten usw usw.

Man darf da halt nicht den Fehler machen, und die Flops von XeonPhi und GPUs direkt miteinander vergleichen. XeonPhi ist tendenziell halt unempfindlicher gegenüber Branches usw.

Schoen. Nimm einen Kepler und entferne alles was theoretisch ueberflussig ist um es auf Phi HPC Faehigkeiten zu begrenzen und benutze einen noch kleineren Prozess wie 28HP und wir werden wohl sehen wie dagegen dann ein Phi genau aussieht.

So wie es ist sind es bei Phi maximal 1073 GFLOPs DP auf Papier mit einem TDP von 300W und das eben weil der die genau am Rand des Herstellung-prozesses hergestellt wurde ergo 600mm2 und mit Verlaub sind mir jeglicher Seite Vor-und Nachteil im gegebenen Fall wurscht. Architektur-bedingte Vorteile haben erstmal gar NICHTS mit Herstellungs-bedingten Einzelheiten zu tun. Tut mir leid aber ich sehe auch bei Phi nicht den angeblichen Prozess-Vorteil von Intel.

Die Tools sind meines Wissens nach auf maximal 550 bis 600mm² ausgelegt. Im Zuge von GF100 hies es mal, nVidia wäre da über die Grenze von TSMC leicht drüber raus, bzw haar scharf dran vorbei. Ne einzelner Maske/Chip bekommste mit den Tools, die überall rum stehen halt einfach nicht größer.

Nein das vorgeschlagene Maximum von TSMC ist bei 600mm2 afaik.

[Skysnake]

Bei Maxwell sollte es leichter sein die ALUs nochmals brutal in die Breite zu treiben selbst im Vergleich zu Kepler.

Und was hat das eine mit dem anderen zu tun :confused:


Schoen. Nimm einen Kepler und entferne alles was theoretisch ueberflussig ist um es auf Phi HPC Faehigkeiten zu begrenzen und benutze einen noch kleineren Prozess wie 28HP und wir werden wohl sehen wie dagegen dann ein Phi genau aussieht.

So wie es ist sind es bei Phi maximal 1073 GFLOPs DP auf Papier mit einem TDP von 300W und das eben weil der die genau am Rand des Herstellung-prozesses hergestellt wurde ergo 600mm2 und mit Verlaub sind mir jeglicher Seite Vor-und Nachteil im gegebenen Fall wurscht. Architektur-bedingte Vorteile haben erstmal gar NICHTS mit Herstellungs-bedingten Einzelheiten zu tun. Tut mir leid aber ich sehe auch bei Phi nicht den angeblichen Prozess-Vorteil von Intel.

Naja, Maxwell/Projekt Denver wird nicht all zu XeonPhi unähnlich werden in einigen Bereichen oder sogar gesamt, nur halt kein x86.

Die Sache ist halt, man kann schon schlecht einschätzen, wie gut die Architektur nun wirklich ist. Man hat halt den Fertigungsvorteil, aber anscheinend auch Fertigungsprobleme(chen).

XeonPhi kann hat dafür aber auch Vorteile, die viel Energie sparen können. AMD und nVidia können das auch implementieren, fragt sich dann nur, wieviel Mehrverbrauch dadurch entsteht.

XeonPhi und GPUs haben meiner Meinung nach zwar eine große Schnittmenge, aber eben auch gewisse Bereiche, wo Sie klar besser sind als der Konkurrent. Das Problem was ich halt für nVidia sehe ist, das die Verbreitung von GPUs eh nicht sooooooo gewaltig war. Zwar nicht unerheblich, aber auch nicht signifikant. Von dieser Marktlücke knapst sich jetzt halt Intel einen Teil ab, und der könnte, einfach durch mehr Flexibilität, einfachere Portierung von Programmen usw. wohl am Ende sogar größer ausfallen.

Gerade die Sache mit der Software sollte man WIRKLICH! nicht unterschätzen. Ich glaub das kann man aber erst so richtig zu schätzen wissen/beurteilen, wenn man mal für GPUs und mal für XeonPhi programmiert hat. Da liegen schon welten dazwischen. nVidia hat mit CUDA zwar teils auch recht einfach programmierbarkeit, aber da ist man hal wieder propritär...

Da seh ich eher HSA von AMD als Chance, ähnlich einfach zu werden, und vor allem eben einen offenen Standard zu haben, wo ich mich nicht auf Gedeih und Verderben an einen Hersteller ketten muss...




Nein das vorgeschlagene Maximum von TSMC ist bei 600mm2 afaik.
Wat nein :ugly: 550-600 ist ne Spanne, und da liegen 600 GENAU drin :freak:

Aber gut, das es doch genau die 600mm² sind. War mir da nicht mehr ganz sicher.

[Ailuros]

Naja, Maxwell/Projekt Denver wird nicht all zu XeonPhi unähnlich werden in einigen Bereichen oder sogar gesamt, nur halt kein x86.

Die Sache ist halt, man kann schon schlecht einschätzen, wie gut die Architektur nun wirklich ist. Man hat halt den Fertigungsvorteil, aber anscheinend auch Fertigungsprobleme(chen).

Welchen Fertigunsvorteil genau? 22nm < 28nm und ich bin sogar so frech und behaupte dass Intel's 32nm mit TSMC's 28nm vergleichbarer ist. Ergo wieviel wuerde vom heutigen Phi unter 32nm theoretisch uebrig bleiben wieder bei 300W TDP oder andersrum wie viel MEHR GFLOPs wuerde man theoretisch gewinnen bei gleichen 235W TDP wenn man einen GK110 unter Intel's 22nm herstellen wuerde?

XeonPhi kann hat dafür aber auch Vorteile, die viel Energie sparen können. AMD und nVidia können das auch implementieren, fragt sich dann nur, wieviel Mehrverbrauch dadurch entsteht.

Das hat wieder nichts mit dem Prozess zu tun.

XeonPhi und GPUs haben meiner Meinung nach zwar eine große Schnittmenge, aber eben auch gewisse Bereiche, wo Sie klar besser sind als der Konkurrent. Das Problem was ich halt für nVidia sehe ist, das die Verbreitung von GPUs eh nicht sooooooo gewaltig war. Zwar nicht unerheblich, aber auch nicht signifikant. Von dieser Marktlücke knapst sich jetzt halt Intel einen Teil ab, und der könnte, einfach durch mehr Flexibilität, einfachere Portierung von Programmen usw. wohl am Ende sogar größer ausfallen.

Siehe oben und nein Intel hat die HPC auch nicht alle aufgekehrt.

[Skysnake]

Ailuros, die Konzepte kann man nicht direkt vergleichen, daher wird es wohl auch für beide am Markt seinen Bereich geben.

Über XeonPhi ohne Fertigungsvorsprung müssen wir glaube ich nicht reden :ugly: Da würde Intel gnadenlos unter gehen. Die Frage ist halt, was kann Intel da noch drehen, bis sie keine weiteren Shrinks mehr fahren können, und die Konkurrenz aufschliest. Ich trau mir da aber wirklich keine Voraussage zu, wie sich das weiterentwickeln wird, und ich häng mich normal gern zum Fenster raus mit irgendwelchen Prognosen :ugly:

[Ailuros]

Der springende Punkt waere wenn man hypothetisch GK110 unter Intel's 22nm herstellen wuerde das Resultat irgendwo zwischen GK104 und GK110@28nm die area, Leistung um einiges ueber einer K20X liegen wuerde (denk Frequenz) und ein TDP der womoeglich sich im GK104 Bereich bewegen wuerde.

Schwamm drueber wir sollten uns lieber ueber reale hw konzentrieren und nicht hypothetischen Krampf.

[boxleitnerb]

Do you envision a Steam Box connecting to other screens outside the living room?

The Steam Box will also be a server. Any PC can serve multiple monitors, so over time, the next-generation (post-Kepler) you can have one GPU that’s serving up eight simultaeneous game calls. So you could have one PC and eight televisions and eight controllers and everybody getting great performance out of it. We’re used to having one monitor, or two monitors — now we’re saying let's expand that a little bit.

http://www.theverge.com/2013/1/8/3852144/gabe-newell-interview-steam-box-future-of-gaming

Mit Maxwell könnte es im Zusammenspiel GRID dann die Virtualisierung für daheim geben. Ein Monster-PC im Keller, der die Tablets, Handhelds, TVs und Monitore im Haus für die ganze Familie bedient. Kein Kabelsalat, keine Redundanz durch 5 Gaming-PCs. Wenn jemand zu Besuch kommt, könnte das auch mit seinem Smartphone/Tablet funktionieren.

[Skysnake]

Und wer will so was?

Und vor allem, warum sollte das die Industrie wollen? Gerade die Publisher werden alles dran setzen das zu verhindern. Das ist ja fast das Gleiche wie Raubmordkopieren und Gebrauchspieleräuber...

[boxleitnerb]

Sag mal, liest man von dir auch mal was anderes als Anti-NV?

Was haben die Publisher und die Industrie mit NV zu tun? Es ist ja auch nicht ausgeschlossen, dass man für jede Virtualisierung dann extra zahlen muss. Ich finde so ein Konzept super. Man will sein Spiel im Garten weiterspielen oder mit einem Freund zusammenspielen, der seinen PC nicht mitschleppen will? Es gibt viele spannende Anwendungsmöglichkeiten. Aber die siehst du irgendwie gar nicht, da kommt nur Contra...

[Skysnake]

Klar seh ich die, ich fände sowas durchaus auch toll, wobei ich persönlich schon den klassische3n PC bevorzuge, aber jedem das seine.

Die Sache ist nur, die Industrie muss da auch mitspielen, und so lange die Publisher eben was ganz anderes wollen, werden die nVidia da nicht mal den kleinen Finger reichen...

Die wollen nämlich auch nur ihr Geld machen, und bei so was haben Sie dann Angst, dass die Leute eben nicht für jede Version bezahlen usw usw. Also was machst du dann als Firma.

1. Etwas was manche Leute cool finden, die ganze Contentindustrie dich aber lynchen will
2. Etwas was die Leute so lala finden, dir aber die Contentindustrie die Tür einrennt

Wenn streamen, dann doch bitte von Hardware der Publisher aus. Damit haben Sie dann nämlich die volle Kontrolle, und nichts anderes wollen Sie, und Sie werden es auch bekommen. Egal ob nVidia, AMD oder sonst wer das macht. Sie werden es über kurz oder lang bekommen. Der Einzige, der das verhindern kann ist der Kunde. Da der Kunde aber im Schnitt so dumm wien Stück Brot ist, und süchtig wie drecksau, wird das nicht passieren. Hat man schon mit Steam und Origin gesehen...

Aber eventuell hab ich die letzten 10 Jahre in der Spieleindustrie auch nur geträumt...

Ach und btw. wo ist das bitte "Anti-NV" wenn ich sag, dass das mit dem "Monster-PC im Keller" Schwachsinn ist, und das Zeug eben beim Publisher steht....

Grid ist genau das, was sich die Publisher wünschen, und gerade in China kann ich mir SEHR gut vorstellen, dass das durchschlagen wird. Aber nicht hierzulande.

[Konami]

Da steht nirgends was von Lizenzen, die geteilt werden. Nur Rechenleistung. Bei Steam eingeloggt sein wird man wohl weiterhin übers Endgerät.

[boxleitnerb]

@Ailuros:

Wo siehst du denn (deutliches) Verbesserungspotential bei Maxwell? Unter der Annahme, dass man den Chip nicht größer oder stromhungriger macht.

[Ailuros]

@Ailuros:

Wo siehst du denn (deutliches) Verbesserungspotential bei Maxwell? Unter der Annahme, dass man den Chip nicht größer oder stromhungriger macht.

Es gibt zwei ziemlich interessante Patente von NV die relativ frueh irgendwo nach dem fermi launch auftauchten. Das eine spricht von einer multi-level cache und das andere hatte etwas mit register files zu tun aber mein Gedaechtnis ist ziemlich truebe was das zweite betrifft.

Man kann an der Verwaltung der threads, der Bandbreite und weiss der Geier noch was schrauben. Ueberhaupt mit den ingegrierten custom CPU cores koennte sich so manches aendern, wobei natuerlich die Frage offen bleibt ob Denver in allen Maxwell GPUs integriert sein wird oder am Anfang lediglich fuer high end.

[Skysnake]

Caches, Caches und nochmal Caches.

Ach und natürlich dynamische Threaderzeugung/-steuerung durch kleine "CPU"-Cores. Da lässt sich viel raus holen.

So ne Skalareinheit wie in GCN ist auch ziemlich cool.

[Timbaloo]

wobei natuerlich die Frage offen bleibt ob Denver in allen Maxwell GPUs integriert sein wird oder am Anfang lediglich fuer high end.
Da bin ich sehr gespannt. Was ist die "special sauce" :biggrin:

[mboeller]

So ne Skalareinheit wie in GCN ist auch ziemlich cool.

Selbst Angestellte von Nvidia scheinen GCN ja sehr cool zu finden:

http://timothylottes.blogspot.com/2013/01/orbis-and-durango.html

[Nakai]

Caches, Caches und nochmal Caches.

Ach und natürlich dynamische Threaderzeugung/-steuerung durch kleine "CPU"-Cores. Da lässt sich viel raus holen.

So ne Skalareinheit wie in GCN ist auch ziemlich cool.

Naja GCN hat ziemlich viel Caches. 64KB pro Vec16-SIMD, 64KB Shared und noch Caches für Textureinheiten und der Skalaren Einheit.

Wieviel hat den die Kepler Architektur bzw. GK110 im Vergleich? Ein Link würde reichen.;)

mfg

[Ailuros]

Naja GCN hat ziemlich viel Caches. 64KB pro Vec16-SIMD, 64KB Shared und noch Caches für Textureinheiten und der Skalaren Einheit.

Wieviel hat den die Kepler Architektur bzw. GK110 im Vergleich? Ein Link würde reichen.;)

mfg

http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

[Nakai]

Mhh, da unterscheiden sich GCN und Kepler vom Cache-System schon gravierend.

Kepler hat im Vergleich zu GCN deutlich weniger Cache im Bezug auf die FLOPs.
Oder sehe ich das falsch?

[Ailuros]

Mhh, da unterscheiden sich GCN und Kepler vom Cache-System schon gravierend.

Kepler hat im Vergleich zu GCN deutlich weniger Cache im Bezug auf die FLOPs.
Oder sehe ich das falsch?

Sicher. Ich hoffe dass caches auf Maxwell nicht nur grosszuegiger sondern auch flexibler werden als bis zu Kepler.

[Skysnake]

Und genau damit steigert man eben die Performance in kritischen Situationen, wo man etwas irregulärere Zugriffmuster hat.

Sprich, gerade da wo Slowdowns auftreten, die nicht durch einen reichen Mangel an Rechenleistung oder ein Limit bei den FFUs verursacht wird, sollten größere Caches etwas bringen.

[Nakai]

Sicher. Ich hoffe dass caches auf Maxwell nicht nur grosszuegiger sondern auch flexibler werden als bis zu Kepler.

Ich bin da immer noch ein Laie. NV hat pro SMX 192 SP SPs und 64 DP SPs.
Beide sollte natürlich parallel laufen dürfen. Dazu kommen 32 SFUs und 32 LSUs.

GK110:
Pro SMX:
192SPs
64DPs
32SFUs
32LSUs
65536*32bit Register(256KB insgesamt! Was hat GCN? Bzw. wie löst es GCN)
64KB Cache(konfigurierbar als L1 und Shared)
48KB Read Only

1536KB L2 Cache Global


GCN:
Pro CU:
64SPs
DP durch loopen der SPs
SFs durch loopen der SPs
16 LSUs
64KB Shared Cache
Pro SIMD 64KB -> 256KB
64KB L1Cache(liegt eher zwischen CUs und L2Cache)

768KB L2 Cache Global

GCN ist wirklich ein Cache-Monster. Globaler Cache ist dennoch nur halb so groß, wie beim GK110. Ich sehe, reinher von meinem derzeitigen Standpunkt und Wissen, GCN >> GK110 reinher von der architekturellen Seite. Da muss NV einen ziemlich fetten Sprung machen um AMD aus architektureller Sicht zu schlagen. Da kann man sicher wirklich schon auf Maxwell freuen.

Achja, wenn es was auszusetzen gibt, immer her damit. Ich will ja was dazulernen.;)

[Ailuros]

Mir ist lieber wenn Gipsel oder jemand anders der sich um zich Male besser mit der Materie auskennt, solche Fragen beantwortet.

Wofuer ich aber ernsthafte Zweifel habe ist dass GK110 wirklich dedizierte DP Einheiten hat die ueber nichts anderes als nur FP64 faehig sind. Mit meinem Halbwissen koennte ich mir lediglich vorstellen dass es sich um irgendwelche relativ kleine Einheiten handelt die helfen durch loops die 3:1 SP/DP Relation zu erreichen. Kann natuerlich totaler Bloedsinn sein, aber vielleicht eine Art scheduling Logik um in Grenzen DP mit einem Schuss SP parallel bearbeiten zu koennen?

[Nakai]

Wofuer ich aber ernsthafte Zweifel habe ist dass GK110 wirklich dedizierte DP Einheiten hat die ueber nichts anderes als nur FP64 faehig sind. Mit meinem Halbwissen koennte ich mir lediglich vorstellen dass es sich um irgendwelche relativ kleine Einheiten handelt die helfen durch loops die 3:1 SP/DP Relation zu erreichen. Kann natuerlich totaler Bloedsinn sein, aber vielleicht eine Art scheduling Logik um in Grenzen DP mit einem Schuss SP parallel bearbeiten zu koennen?

Laut einem Interview über GK104, sind anscheinend tatsächlich DP-SPs verbaut. Ich kann mal versuchen die Quelle zu finden. Jedenfalls hat das ein Nvidia-Mitarbeiter erwähnt. Ob der wirklich mit allen Informationen ausgestattet war, kann ich nicht sagen.

[Ailuros]

Laut einem Interview über GK104, sind anscheinend tatsächlich DP-SPs verbaut. Ich kann mal versuchen die Quelle zu finden. Jedenfalls hat das ein Nvidia-Mitarbeiter erwähnt. Ob der wirklich mit allen Informationen ausgestattet war, kann ich nicht sagen.

Mir ist schon bewusst was sie behauptet haben, aber es heisst auch nicht dass ich es sofort glaube. DP stream processors sind ziemlich teur in hw und das was ich hier glauben soll ist dass jeder GK110 SMX ueber 2*SIMD32 verfuegt der ueber nichts anderes faehig ist als nur DP. Wieso soll so eine Einheit wenn sie schon ueber FP64 faehig ist nicht ueber FP32 faehig sein? Noch besser wir reden hier ueber 960 zusaetzliche DP SPs auf dem gesamten chip ergo hat GK110 nicht wirklich "nur" 2880 SPs sondern insgesamt 3840.

[Locuza]

Wurde das wirklich so gesagt, dass die DP-Einheiten kein SP können?
Wäre es nicht vielleicht eher so, dass es ein Drittel-Einheiten gibt, die NUR DP berechnen können, aber für SP ebenso herangezogen werden können?
Bisher hat man doch immer mehrere ALUs für einen DP-Wert verwendet oder täusche ich mich da komplett?

[Ailuros]

Wurde das wirklich so gesagt, dass die DP-Einheiten kein SP können?

Ja; noch schlimmer Block-Diagramme zeigen dedizierte DP Einheiten an.

Wäre es nicht vielleicht eher so, dass es ein Drittel-Einheiten gibt, die NUR DP berechnen können, aber für SP ebenso herangezogen werden können?
Bisher hat man doch immer mehrere ALUs für einen DP-Wert verwendet oder täusche ich mich da komplett?

Genau das meine ich auf die eine oder andere Art; technisch moeglich ist es zwar schon aber fuer die heutigen Verhaeltnisse und fuer einen chip der sowohl im desktop als auch fuer HPC dienen soll klingt es mir nach idiotischem engineering solch einen Ueberfluss zu entwickeln. Das dumme ist eben dass NV nirgends definiert was sie genau mit DP Einheit meinen.

[=Floi=]

es wird schlicht energieeffizienter sein.
zitat:
SMX: 192 single‐precision CUDA cores, 64 double‐precision units, 32 special function units (SFU), and 32 load/store units
(LD/ST).

[Ailuros]

es wird schlicht energieeffizienter sein.
zitat:
SMX: 192 single‐precision CUDA cores, 64 double‐precision units, 32 special function units (SFU), and 32 load/store units
(LD/ST).

Erklaer mir mal inwiefern energie-effizienter, denn ich verpasse hier offensichtlich wesentliches.

[Hugo78]

Wenn NV tatsächlich einen Weg gefunden hat DP Einheiten zubauen die kaum größer als SP Einheiten sind,
dann ist es sicherlich effizienter, als zwei oder drei SP Einheiten für einen DP FLOP rechnen zulassen.

http://www.legitreviews.com/images/reviews/news/2_GK110_SMX_Unit.jpg

[Gipsel]

Ich bin da immer noch ein Laie. NV hat pro SMX 192 SP SPs und 64 DP SPs.
Beide sollte natürlich parallel laufen dürfen. Dazu kommen 32 SFUs und 32 LSUs.Wie schon von Anderen bemerkt, ist es höchst zweifelhaft, daß es separate DP-Einheiten gibt. Das macht einfach keinen Sinn. Was nV dazu sagt, ist beinahe unerheblich, da die nicht gerade für die Exaktheit ihrer Auskünfte in solchen Detailfragen bekannt sind (ein Beispiel sind z.B. einige in Photoshop erstellten "Dieshots", die kaum bis gar keine Ähnlichkeit mit der Realität aufweisen).
GK110:
Pro SMX:
192SPs [vermutlich 4 Blöcke mit 3 x vec16]
64DPs [vermutlich nicht existent, sondern durch "Kopplung" oder Looping der FP32vec16 ALUs erreicht]
32SFUs [4 x 8]
32LSUs [4 x 8 / 2 x 16?]
65536*32bit Register (256KB insgesamt!) [vermutlich 4 x 16384 Register = 4 x 64kB]
64KB Cache (konfigurierbar als L1 und Shared) [16kB Cache + 48kB shared memory oder 32/32 oder 48/16kB]
48KB Read Only [das ist der Textur-L1]

1536KB L2 Cache Global [256 kB pro 64Bit Speichercontroller]
Die Vierergruppierung kommt dadurch zustande, daß Threads, die von einem der 4 Scheduler gehandhabt werden, diesen nicht wechseln können. Logisch besitzt jeder SMx also 4 Registerblöcke zu je 64kB. Physisch implementiert ist das sogar noch feinkörniger. Teilt man die ALUs, an die die Scheduler jeweils die Instruktionen absetzen können ebenfalls in 4 Blöcke auf, kann man die Distanzen zwischen Registerfiles und ALUs drastisch verringern (senkt den Stromverbrauch dramatisch). Im Prinzip gibt es dann 64 kleine Registerfiles zu je 4 kB, die jeweils 3 SPs (einzelne Slots der vec16-ALUs) und eine SFU (die allerdings eine Anbindung an jeweils 2 Registerfiles haben müßte) versorgen. Alternativ besteht der Grundbaustein aus 8kB Registern, 6 SPs (2 benachbarte Slots der Vec-ALUs) und einer SFU. Die LSUs weden von einem breiten Datenbus von den RegFiles versorgt, erfordern mehr Scheduleraufwand und können anders aufgeteilt sein (also es muß nicht die vier Blöcke geben, der Vergleich zu GCN wäre hier interessant ;))

GCN:
Pro CU:
64SPs [4 x vec16 ALUs]
DP durch loopen der SPs
SFs durch loopen der SPs
16 LSUs [die existieren so bezeichnet nicht, man könnte auch argumentieren, daß es nach nV-Lesart 32 sind]
64KB Shared Cache [shared memory ist kein Cache!]
Pro SIMD 64KB -> 256KB [pro SIMD/vec16-ALU gibt es 64kB Vektor-Register, 256kB insgesamt]
64KB L1Cache(liegt eher zwischen CUs und L2Cache)
[read-write-L1 ist lediglich 16kB pro CU, diese 16kB dienen geichzeitig auch als Textur-L1 (weswegen GCN im Prinzip sehr flexibel bei Texturen ist, alle Compute-Features/atomics/whatever gehen auch direkt mit Texturen); es gibt noch 32kB L1-I, der zwischen jeweils (bis zu) 4 CUs geteilt wird und 16kB Skalar-L1, ebenfalls von 4 CUs geteilt]

768KB L2 Cache Global [wenn Du von GCN redest, dann sind es 64 oder 128kB pro 32Bit Speicherkanal, CapeVerde nutzt 128kB, Pitcairn und Tahiti nur 64kB, weswegen CV und Pitcairn beide insgesamt 512kB haben und Tahiti 768kB, GCN an sich würde auch 1536kB L2 mit einem 384Bit-Speicherinterface unterstützen]

GCN ist wirklich ein Cache-Monster. Globaler Cache ist dennoch nur halb so groß, wie beim GK110.
Ähnlich Keplers SMx ist auch eine GCN-CU intern in 4 ALU-Blöcke mit eigenem Scheduler unterteilt (auch hier können Threads den Scheduler nicht wechseln). Hier stehen ebenfalls pro Block 64kB Register (zur Unterscheidung zu den bei GCN auftreteneden Registern für die Skalar-ALU Vektor-Register/vRegs genannt). Die Organisation ist allerdings einfacher. Jeder Registerblock von 64kB versorgt genau eine vec16-ALU (aufgeteilt in 4kB-Blöcke für jeden SP [Slot der Vec-ALU]). Die 4 kB müssen also nicht für 3 SPs reichen, sondern nur für einen einzigen. GCN (die VLIW-Architekturen sogar tendentiell noch mehr) ist also kein Cache-Monster sondern eher ein Register-Monster. Die 2048 SPs eines Tahiti können auf insgesamt 8MB Register zugreifen. Den 1536 SPs eines GK104 stehen 2MB zur Verfügung, GK110 im Vollausbau bietet 3,75MB fü 2880 SPs.
Ein weiterer Vorteil von GCN gegenüber Kepler ist das local oder shared Memory (ist wie gesagt kein Cache). Bei Kepler gibt es insgesamt 64kB pro SMx, wobei aber maximal 48kB in dieser Funktion verfügbar sind (weil das benutzte Speicherarray statisch zwischen Cache und local memory aufgeteilt wird). Viele Threads (die nötig sind, um die großen SMx mit 192 SPs auszulasten) streiten sich also um maximal 48kB local memory. Bei GCN kommen auf nur 64 SPs in einer CU (die also weniger Threads für die Auslastung benötigt) volle 64 kB local memory. Wann immer also recht viel local memory benötigt wird (mal so als Anhaltspunkt: DX CS5 erlauben 32kB pro Workgroup), bekommt GCN deutlich später Platzprobleme, kann also mehr Threads parallel laufen lassen (was die Auslastung verbessert und für das Latency hiding der GPUs essentiell ist). Bei Tahiti kommen insgesamt 2 MB shared/local memory auf 2048 SPs, GK104 muß mit maximal nuzbaren 0,375 MB (384 kB) auskommen und selbst GK110 bringt es nur auf 0,7 MB (720 kB).

Oder einfach mal so als Beispiel:
Irgendein Problem soll mit workgroups der Größe von 64 workitems ("Threads" im nV-Sprech) gelöst werden, wobei jede dieser Gruppen auf 8 kB local/shared memory zugreifen kann. Bei GCN passen also 8 Gruppen (512 workitems) gleichzeitig auf eine CU, bei Kepler maximal 6 (384 work items) auf einen SMx. Dabei stehen aber dem SMx erheblich größere ALU-Resourcen (und auch externe Bandbreite) zur Verfügung. 384 work items sind gerade mal 12 Warps (Hardware-Threads). Jeden Takt werden in einem SMx Instruktionen von 4 Warps issued (wobei dual issue schon nur bei Vorhandensein von IPC funktioniert, maximal 2 Instruktionen pro Warp => 8 Instruktionen pro Takt). So oder so, nach 3 Takten, gehen den Schedulern die Warps aus, wenn nicht viel IPC im Code existiert (zum Vergleich, die ALU-Latenz bei Kepler beträgt 10 Takte). Im Zweifelsfall bekommen die ALUs also 3 Takte lang Arbeit und warten dann erstmal die nächsten 7 Takte, bis es weitergeht.

Bei GCN im Vergleich laufen 8 Gruppen, was hier auch genau 8 Wavefronts (AMDs-Bezeichnung für die Hardware-Threads) sind, pro Scheduler also genau zwei. Das Scheduling bei GCN läuft deutlich anders als bei Kepler, aber allgemein kann GCN pro Takt genau 1 ALU-Instruktion absetzen (die vier Scheduler wechseln sich mit dem issue ab). Die Scheduler haben also nach 8 Takten die erste Instruktion für alle Wavefronts auf der CU abgesetzt. Die Latenz beträgt üblicherweise aber nur 4 Takte (gibt ein paar Ausnahmen bei bestimmten Instruktionen oder dem Wechsel zwischen Skalar- und Vektor-Instruktionen). D.h. das mit normalen ALU-Instruktionen die ALUs nie arbeitslos werden können.

Summa Summarum könnten auf Tahiti 256 solcher work groups (16384 work items / "threads") gestartet werden, auf GK104 nur 48 (3072 work items) und selbst bei GK110 nur 90 (5760). Da ergibt es sich von selbst, daß dann das ganze Latency-Hiding der GPUs besser funktioniert und die Auslastung auf GCN höher ist. Zugunsten von Kepler kann man die Situation verschieben, wenn viel IPC vorhanden ist oder keine ALU- bzw. Latenz-Limitierung vorliegt (weil z.B. die externe Bandbreite gesättigt wird). Aber ansonsten ist in solchen Situationen GCN klar überlegen.

==================

Um nochmal auf die Frage der LSUs bei GCN zurückzukommen, die gibt es wie gesagt so nicht. Die Adressierung von (globalem) Speicher oder Texturen erfolgt durch 16 "AGUs" in der Cache-Control des Vektor-L1 (der normale Schreib-Lese-L1, der auch Textur-L1 ist) unter Verwendung von Werten aus den Vektor-Registern als auch den Skalar-Registern (was unter anderem PRTs bzw. bindless textures ermöglicht). Read-Only-Werte können auch von der Skalar-ALU über den Skalar-L1 (der auch am L2-hängt) in die Skalar-Register gelesen und dann per Broadcast an die Vektor-ALUs verteilt werden (Vektor-Instruktionen können ein Skalar-Register direkt als Operand benutzen). Die Adressierung des local/shared memory (AMD nennt es LDS) ist davon getrennt. Hier können bis zu 32 4Byte-Werte pro Takt geliefert werden (über 2 getrennte Datenbusse zu je 512 bit, jeder versorgt 2 SIMDs). Weiterhin besteht auch hier die Möglichkeit, daß Vektor-Instruktionen einen Operanden direkt aus dem LDS per Broadcast benutzen können.
GDS (Global Data Share, gibt es bei nV nicht) und ROPs hängen dagegen am Export-Bus und werden ebenfalls anders adressiert.

Vor einem guten Jahr habe ich mal diese etwas vereinfachte Übersicht einer CU gebastelt. Ein paar Pfeile fehlen der Übersichtlichkeit zuliebe (oder auch die beiden Datenbusse vom LDS zu SIMD0/1 bzw. SIMD2/3; der LDS sitzt also praktisch zwischen den SIMDs, 16x32=512 bit gehen an die beiden linken SIMDs, das Gleiche nochmal an die beiden rechten). Verschiedenfarbige Pfeile kennzeichnen unterschiedliche Instruktionstypen bzw. Datenquellen.
http://www.abload.de/img/gcn_cu2rcve.png

Ich sehe, reinher von meinem derzeitigen Standpunkt und Wissen, GCN >> GK110 reinher von der architekturellen Seite. Da muss NV einen ziemlich fetten Sprung machen um AMD aus architektureller Sicht zu schlagen.Das ist schwer zu sagen.
AMD und nV haben etwas andere Schwerpunkte bei der Entwicklung gesetzt. AMD hat praktisch mit einem weißen Blatt Papier für GCN angefangen und heraus kam eine ziemlich klar durchdachte und "schön" strukturierte Vektor-Architektur für die CUs. Dies ist ein für mich überzeugend aussehendes Design, was eine gute Grundlage für zukünftige Entwicklungen darstellen sollte (VLIW hat ja auch ein paar Jahre durchgehalten, GCN-Derivate werden wir vielleicht sogar noch länger sehen). In ein paar Teilaspekten und beim Drumherum kann dagegen nVidia durchaus Vorteile für sich verbuchen.

[Skysnake]

Laut einem Interview über GK104, sind anscheinend tatsächlich DP-SPs verbaut. Ich kann mal versuchen die Quelle zu finden. Jedenfalls hat das ein Nvidia-Mitarbeiter erwähnt. Ob der wirklich mit allen Informationen ausgestattet war, kann ich nicht sagen.
nVidia erzählt viel scheis, wenn der Tag lang ist...
Allein wenn man sich mal anschaut, was man für ne 32Bit und ne 64Bit ALU braucht, um die arithmetischen Operationen auszuführen auf Integerbasis, da ist es am einfachsten, merkt man SEHR schnell, das man nur sehr wenig zu mehreren SP ALUs dazu packen muss, um Sie fit zu machen für DP.

Gipsel hats ja auch schonmal angesprochen, nVidia nimmt sehr hochtrabende Worte, sagt aber nirgends, was SIE denn unter DP-Units verstehen :rolleyes: Kann also durchaus sein, dass Sie nur die paar Shuffels, loops und Multiplizierer/Addierer-Erweiterungen als "DP-Units" definieren :ufail:

Hört sich halt fürs Marketing so besser an...

Wenn NV tatsächlich einen Weg gefunden hat DP Einheiten zubauen die kaum größer als SP Einheiten sind,
dann ist es sicherlich effizienter, als zwei oder drei SP Einheiten für einen DP FLOP rechnen zulassen.

http://www.legitreviews.com/images/reviews/news/2_GK110_SMX_Unit.jpg
Schau dir an, was man braucht für SP und DP, und du wirst sehen, dass das nicht möglich ist... Das ist ja ganz "einfache" Mathematik, die dir beschreibt, wie du eine Addition/Multiplikation und Division durchführen kannst/musst. Daran kannst du nichts rütteln


Das ist schwer zu sagen.
AMD und nV haben etwas andere Schwerpunkte bei der Entwicklung gesetzt. AMD hat praktisch mit einem weißen Blatt Papier für GCN angefangen und heraus kam eine ziemlich klar durchdachte und "schön" strukturierte Vektor-Architektur für die CUs. Dies ist ein für mich überzeugend aussehendes Design, was eine gute Grundlage für zukünftige Entwicklungen darstellen sollte (VLIW hat ja auch ein paar Jahre durchgehalten, GCN-Derivate werden wir vielleicht sogar noch länger sehen). In ein paar Teilaspekten und beim Drumherum kann dagegen nVidia durchaus Vorteile für sich verbuchen.

Jup, und die Architektur sieht schon ziemlich gut aus, und hat vor allem Potenzial!

Allein die Sache mit dem GDS, welcher Kommunikation über Workgroups hinweg erlaubt ist der HAMMER! Das wünschen sich ja viele Programmierer von GPUs, wenn Sie damit anfangen, und müssen daran erstmal schlucken, dass das normal nicht geht.

Genau so die Sache mit dem schlafen legen von Threads. So kann man praktisch polling vernünftig auf GPUs implementieren, ohne sich in Deadlogs zu begewen.

Das Problem dabei ist nur, das AMD eben so eine Software-Schnittstelle (also API) wie CUDA fehlt, wo Sie halt einfach die neuen Funktionen ansprechbar machen. Sie nutzen halt OpenCL, was hier wirklich eine Bremse ist... Dennoch ist OpenCL positiv, da eben Code portierbar bleibt.

AMD müsste hier halt nur etwas stärker auf Extensions setzen! Ich hoffe wirklich, das AMD hier bald nachlegt. In der nächsten OpenCL Version soll ja durchaus einiges cooles kommen für AMD, wie ich gehört habe.

Potenzial ist wie gesagt in der Architektur mehr als genug vorhanden. Da muss man sich selbst hinter GK110 nicht verstecken.

[Nightspider]

Rein aus den Fakten kann man doch auch nicht ablesen, wie effizient und damit stark eine Architektur wird oder?

Für die Preise würde es mich natürlich auch freuen wenn CGN stark wird.

[Skysnake]

Jaein.

Man kann sehen, wie "gut" sich gewisse Probleme umschiffen lassen, bzw. wie wahrscheinlich es ist, das man sich ständig die Nase an der nächsten Wand platt rennt, und da sieht GCN eben recht angenehm für den Programmierer aus. Die Cachegrößen usw. passen alle ziemlich natürlich zusammen, also nichts, wo man wild anfangen muss zu rechnen, und sich eben ständig nen Kopf machen muss, oder krumme Zahlen bei raus kommen, mit denen man nichts anfangen kann.

Ob man am Ende dann wirklich die Performance erzielt, die man sicher erhofft ist eben wieder was ganz anderes. Der Teufel steckt hier immer im Detail....

Was positiv an GCN zu bewerten ist, ist halt, das viele der Features, die in GK110 so angepriesen werden, eben auch mit GCN relativ "einfach" zu realiseren wären. Hier kommt aber wieder das "nein" aus "Jaein" dazu. Im Moment fehlt es einfach an der Möglichkeit, diese Funktionalität dem Programmierer einfach zugänglich zu machen. Auf ISA-Ebene will man nicht wirklich anfangen zu programmieren, wenns nicht sein muss... Das verhindert einfach eine breite Nutzung der Hardwarefunktionen.

Die Jungs von Ati/AMD wissen halt echt, wie man gute Hardware baut, auf der Zielgerade verkacken Sies bisher aber immer ein bischen mit der API, und auch dem Marketing bzgl den Funktionen....

[PCGH_Carsten]

Wie schon von Anderen bemerkt, ist es höchst zweifelhaft, daß es separate DP-Einheiten gibt. Das macht einfach keinen Sinn.
Naja, nach der Verwirrung um GK104 wurde diesesmal schon etwas genauer nachgefragt - mehrfach, von mehrern Kollegen und nicht nur das Marketing sondern teils auch die Architecture Leads selbst.

Und es gibt mMn sehr wohl einen ziemlich triftigen Grund, warum man dedizierte DP-Einheiten verwendet - gerade nach dem, was man mit Fermi „durchgemacht“ hat: Energie > Fläche.

P.S.: Ansonsten ein tolles Posting von dir!

[Ailuros]

Naja, nach der Verwirrung um GK104 wurde diesesmal schon etwas genauer nachgefragt - mehrfach, von mehrern Kollegen und nicht nur das Marketing sondern teils auch die Architecture Leads selbst.

Und es gibt mMn sehr wohl einen ziemlich triftigen Grund, warum man dedizierte DP-Einheiten verwendet - gerade nach dem, was man mit Fermi „durchgemacht“ hat: Energie > Fläche.

P.S.: Ansonsten ein tolles Posting von dir!

Das dumme ist halt dass es nicht in meinen Laien-Schaedel passen will, dass man dadurch einen jeglichen "Energie"-Vorteil erringen kann.

Nach diesem hat GK110 3840SPs verteilt ueber 15 cluster, ergo 256SPs/SMX. Wo es jetzt bei mir hapert ist das Verstaendnis dass im Gegenfall ein hypothetischer Fall von 256 FP32 SPs (8*SIMD32) mit einem 4:1 SP<->DP ratio mehr verbrauchen wuerde als 192 FP32 + 64 FP64.

Dazu muss es nichtmal solch ein Vergleichsfall sein; es haetten auch nur ingesamt 192 SPs sein koennen wobei einfach nur 128SPs durch loops ueber DP faehig sind.

Wenn ich mich irre hat GT200 30 SPs DP bzw. 3 DP SPs/SM oder hab ich das falsch in Erinnerung? NV engineering hatte damals behauptet dass jegliche DP Einheit ~1.4mm2@40G einnimmt und sie haben wohl mit Absicht damals nicht auf 65 bzw. 55nm zitiert. Nichtdestominder ist fuer 30SPs eine theoretiche Summe von 14mm2@40G nicht sehr viel selbst wenn man es auf 65nm hochrechnet, aber bei den ehlendigen 77GFLOPs DP die man aus diesen bekommt muss ich mir schon Gedanken machen. Nun gut bei GT200 war wohl DP hoechstwahrscheinlich ein quasi "Nachgedanke" irgendwo in der Mitte der Entwicklung aber bei Kepler sind es bombastische 960SPs.

Sicher reden wir hier ueber 28nm und moeglicherweise vielleicht sogar einfachere DP Einheiten als bei GT200, aber dass die 960SPs auf GK110 weniger als 100mm2 betragen kann ich verdammt schwer schlucken. Gibt es power gating fuer die DP ALUs? Moeglich ist es schon nur ist die Logik dafuer auch nicht umsonst. Unter normalen Umstaenden sind also 256SPs/SMX auf GK110 aktiv unter 3D wobei man eigentlich nur die 192 davon benutzen kann fuer 3D (denn wenn die DP SPs selbst ueber 32bit integer faehig waeren haetten sie es schon irgendwo erwaehnt). Ich hab ehrlich gesagt nie einen NV engineer darueber nachgefragt, aber wenn er mir sagen wuerde dass es energie-effizienter so ist dann wuerde ich solch einen trockenen Satz ohne jegliche weitere Erlaeuterung einfach nicht glauben. Und dann kommt man eben in Bereiche wo kein IHV weitere details so frueh darueber frei geben wuerde.

Daemlicherweise erzaehlt zwar Charlie viel Duennschiss wenn der Tag lang ist aber ich kann mich gut daran erinnern dass er einige Zeit vor dem Kepler launch ein 1:1 SP/DP ratio behauptete. Kann durchaus sein dass der richtige hint bei ihm ankam und er es lediglich damals falsch interpretiert hatte. Da aber 1:1 total absurd klang fragte ich damals einige erfahrene engineers bei mehreren anderen IHVs nach ob dedizierte DP Einheiten eine gute Idee waeren. Alle Antworten waren negativ und eine von diesen ging ein klein bisschen mehr in Einzelheiten wobei es hiess dass bei relativ geringer Anzahl es unter Bedingungen kein Problem sein sollte; bei hoher Anzahl jedoch definitiv hw Verschwendung.

960SPs sind fast zwei Mal so viel wie auf einem GF110 um Himmel's Willen.

[PCGH_Carsten]

Das dumme ist halt dass es nicht in meinen Laien-Schaedel passen will, dass man dadurch einen jeglichen "Energie"-Vorteil erringen kann.

Powergating - erwähnst du ja später selbst. Ansonsten müssten die fetten Adder und Multiplier für jede SP-Operation mitlaufen und Bits maskiert werden. Die Scheduler, Dispatcher Datenleitungen und Register, die ja auch einen wesentlichen Teil der Chipfläche für DP ausmachen werden ja doppelt genutzt, 1xDPFP oder 2xSPFP.

[Ailuros]

Powergating - erwähnst du ja später selbst.

Braucht aber auch zusaetzliche Logik, zugegeben wohl geringe aber trotzdem...

Ansonsten müssten die fetten Adder und Multiplier für jede SP-Operation mitlaufen und Bits maskiert werden. Die Scheduler, Dispatcher Datenleitungen und Register, die ja auch einen wesentlichen Teil der Chipfläche für DP ausmachen werden ja doppelt genutzt, 1xDPFP oder 2xSPFP.

Ich frag mal weiter; mal sehen was dabei rauskommt.

[Skysnake]

Daemlicherweise erzaehlt zwar Charlie viel Duennschiss wenn der Tag lang ist aber ich kann mich gut daran erinnern dass er einige Zeit vor dem Kepler launch ein 1:1 SP/DP ratio behauptete. Kann durchaus sein dass der richtige hint bei ihm ankam und er es lediglich damals falsch interpretiert hatte. Da aber 1:1 total absurd klang fragte ich damals einige erfahrene engineers bei mehreren anderen IHVs nach ob dedizierte DP Einheiten eine gute Idee waeren. Alle Antworten waren negativ und eine von diesen ging ein klein bisschen mehr in Einzelheiten wobei es hiess dass bei relativ geringer Anzahl es unter Bedingungen kein Problem sein sollte; bei hoher Anzahl jedoch definitiv hw Verschwendung.

960SPs sind fast zwei Mal so viel wie auf einem GF110 um Himmel's Willen.
Es ist auch schwachsinn, bei so was dedizierte DP-Units zu verbauen. Das macht man wirklich nur, wenn man ganz ganz wenig DP Leistung braucht. Und selbst da ist es dann fraglich, ob man das wirklich machen will...

Das lernt man einfach schon in der Uni, in Chipdesign/ASIC-Entwurf, wie "einfach" es ist aus SP-Einheiten DP-Einheiten zu bauen. Das sind halt echt basics, und ich hab noch NIE jemanden gehört, der sich auch nur minimal in der Materie auskennt, der das auch nur im entferntesten realistisch hält.

Powergating - erwähnst du ja später selbst. Ansonsten müssten die fetten Adder und Multiplier für jede SP-Operation mitlaufen und Bits maskiert werden. Die Scheduler, Dispatcher Datenleitungen und Register, die ja auch einen wesentlichen Teil der Chipfläche für DP ausmachen werden ja doppelt genutzt, 1xDPFP oder 2xSPFP.
Und genau deswegen macht man auch keinen solchen Blödsinn wie mit den dedizierten DP-Units... Man kann einfach unglaublich viel wiederverwenden...

Dedizierte DP-Einheiten würden den Chip einfach extrem! aufblähen und eben GENAU das verhindern, was man sich dadurch erhofft, nämlich Energieeinsparung, da man nochmals Datenpfade legen muss, nochmals extra ALUs verbauen usw usw... Das bläht alles den Chip auf, und genau DAS will man nicht, weil damit die Datenpfade länger werden, und damit auch der Energieaufwand die Daten hin und her zu schupsen...

[PCGH_Carsten]

Ail, check mal PM. :)

[Gipsel]

Powergating - erwähnst du ja später selbst. Ansonsten müssten die fetten Adder und Multiplier für jede SP-Operation mitlaufen und Bits maskiert werden.Clock gating okay. Aber Powergating so feinkörnig klingt recht unrealistisch. Das würde nur gehen, wenn das nicht von Hardware sondern rein softwaregesteuert funktioniert und der Treiber vorab feststellen kann, daß keine DP-Instruktionen vorliegen. Dies allerdings kollidiert irgendwie mit der folgenden Annahme:
Die Scheduler, Dispatcher Datenleitungen und Register, die ja auch einen wesentlichen Teil der Chipfläche für DP ausmachen werden ja doppelt genutzt, 1xDPFP oder 2xSPFP.
Wenn das auch für SP genutzt werden soll, kann man es ja wohl nicht Powergaten, richtig?
Außerdem funktioniert die Doppelnutzung nur, wenn die DP-Einheiten auch 2x SP können, also anders formuliert, DP über die "Zusammenlegung" zweier SP-ALUs funktioniert. Bei komplett getrennten Einheiten muß es ja wohl getrennte Anbindungen an Scheduler und zu den Registern geben. Mir ist jetzt spontan kein Prozessordesign präsent, was diese recht aufwendigen und teuren Dinge mal so einfach dupliziert. Üblicherweise berechnen die exakt selben Einheiten DP und SP.

Ich habe das irgendwann schon mal ausgeführt, wo der Sweetspot bei der Wahl zwischen 1:2 bzw. 1:4 DP:SP in Abhängigkeit von verschiedenen Randbedingungen liegt. Wenn die Schedulerlogik/Registerports bzw. ganz allgemein die Anbindung limitiert, ist 1:2 sinnvoll, weil hier der Aufwand genau gleich groß ausfällt bzw. konstant bleibt. Bei SP bleibt im Prinzip ein Teil der Logik ungenutzt und es sind nur sehr moderate Zusätze erforderlich, um für eine hypothetische reine DP-Einheit 2xSP zu ermöglichen.

1:4 ist dann sinnvoll, wenn wirklich die eigentliche Logik für die Ausführung der Operationen limitiert, also die Dispatch-Logik und Registerzugriff mit verhältnismäßig wenig (Transistor- und Flächen-)Aufwand möglich sind (z.B. bei einem in-order-Design mit geringem Takt). Hier wird nämlich die Hälfte der Registerbandbreite bei DP "verschwendet". Dafür hält sich der Mehraufwand in den Einheiten selber aber sehr in Grenzen. Oder ausgehend von einer DP-Einheit (was mehr oder weniger die umgekehrte Richtung der GPU-Entwicklung ist), benötigt ein 1:4-Design die doppelte Registerbandbreite für SP und in etwa den doppelten Mehraufwand (nicht den doppelten Aufwand) eines 1:2-Design im Vergleich zu einem reinen DP-Einheit für Multiplikationen. Für Additionen muß man die Adder-Kapazitäten allerdings knapp verdoppeln. Letzteres ist der Grund, warum z.B. Bobcat und Jaguar Additionen mit 1:2 machen, Multiplikationen allerdings mit 1:4. ;)
Einleuchtender ist allerdings der Weg von SP-Einheiten (weil dies der primäre Einsatzfall bei GPUs ist). Hat man SP-ALUs, benötigt man nur recht geringe Erweiterungen an den ALUs, um Additionen mit 1:2 Rate und Multiplikationen mit 1:4 Rate auszuführen (1:16 geht ohne merkliche Erweiterungen). Dies ist die billigste Möglichkeit, ansprechend hohe DP-Leistung zu erreichen. Alles was bei einem reinen SP-Einsatz brach liegt, sind 3 Bits (von 27) der (Integer)-Multiplier und Adder und noch etwas in der Logik zur Behandlung der Rundung und Normierung. Für 1:2 benötigt es in den Addern kaum Zusatzaufwand, die Multiplierresourcen muß man allerdings verdoppeln. Aber das schlägt ziemlich sicher immer noch 3 SP-Einheiten mit 1 reinen DP-Einheit (die in etwa so groß sein sollte wie zwei reine SP-Einheiten) zu kombinieren.

Aber grau ist alle Theorie. Man kann es im Prinzip testen. Wenn nV's Darstellung stimmen sollte, müßte es möglich sein, 192 SP-Flops + 64 DP-Flops pro Takt auf einem SMx simultan zu erreichen. Selbst wenn man mit Registerport-Beschränkungen ankommt, müßten noch mindestens 128SP + 64DP-Operationen drin sein. Gibt es keine extra-Einheiten, dürfte das Maximum vermutlich bei 64 SP + 64 DP pro Takt liegen (wenn 1:2 ALUs mit SP-only ALUs kombiniert sind).

[PCGH_Carsten]

Das lernt man einfach schon in der Uni, in Chipdesign/ASIC-Entwurf, wie "einfach" es ist aus SP-Einheiten DP-Einheiten zu bauen. Das sind halt echt basics, und ich hab noch NIE jemanden gehört, der sich auch nur minimal in der Materie auskennt, der das auch nur im entferntesten realistisch hält.


Und genau deswegen macht man auch keinen solchen Blödsinn wie mit den dedizierten DP-Units... Man kann einfach unglaublich viel wiederverwenden...

Dedizierte DP-Einheiten würden den Chip einfach extrem! aufblähen und eben GENAU das verhindern, was man sich dadurch erhofft, nämlich Energieeinsparung, da man nochmals Datenpfade legen muss, nochmals extra ALUs verbauen usw usw... Das bläht alles den Chip auf, und genau DAS will man nicht, weil damit die Datenpfade länger werden, und damit auch der Energieaufwand die Daten hin und her zu schupsen...

Seit ungefähr drei Jahren höre ich „Leute die sich mit der Materie auskennen“ nur noch von Power reden, nicht mehr von Die-Space. Die-Space ist für Aktionäre interessant, Power für Forscher. ;-)

Wieviele "Bits" und damit nötige Datenpfade laufen denn bei 2.880 ALUs dauernd leer, wenn die anstelle von rein SP auch 1/2 DP-fähig sind? Und wie sähe die Rechnung bei 1/3-DP-Ratio aus? ;)

[PCGH_Carsten]

Clock gating okay. Aber Powergating so feinkörnig klingt recht unrealistisch. Das würde nur gehen, wenn das nicht von Hardware sondern rein softwaregesteuert funktioniert und der Treiber vorab feststellen kann, daß keine DP-Instruktionen vorliegen.

Gerade das kann (bzw. muss) die Kepler-Generation ja, da das Scheduling für Instruktionen mit fester Latenz teils in den Compiler verlagert wurde.

[Skysnake]

Seit ungefähr drei Jahren höre ich „Leute die sich mit der Materie auskennen“ nur noch von Power reden, nicht mehr von Die-Space. Die-Space ist für Aktionäre interessant, Power für Forscher. ;-)

Genau das verhinderst du ja mit dedizierten DP-Units. Du blähst den Chip auf, und machst damit die Wege länger. Also zumindest, wenn du die DP-Units in die SP-Units integrierst. Wenn, dann bitte wirklich physisch dedizierte Einheiten. Das hat auf die Pfadlänge bei den SP Einheiten keine Auswirkung, und die Performanceeinbußen bei der geringen Leistung kann man eh vernachlässigen. Auch die Probleme beim Wechsel zwischen SP<->DP sind bei GPUs eigentlich vernachlässigbar.


Wieviele "Bits" und damit nötige Datenpfade laufen denn bei 2.880 ALUs dauernd leer, wenn die anstelle von rein SP auch 1/2 DP-fähig sind? Und wie sähe die Rechnung bei 1/3-DP-Ratio aus? ;)
Wenn du die "dedizierten" DP-Units in die SMX mit den SP-Units integrierst, dann laufen immer gleich viele Datenpfade. Je nachdem sogar mehr mit den dedizierten, wenn du nicht clock/power gaten kannst, was so feingranular kaum vorstellbar ist.

Was du meinst ist, das man wie oben gesagt wirklich einen physisch dedizierten DP-Block/SMX hat, was nVidia ja aber verneint.

[PCGH_Carsten]

Was du meinst ist, das man wie oben gesagt wirklich einen physisch dedizierten DP-Block/SMX hat, was nVidia ja aber verneint.
Tun sie doch gar nicht, darum geht es hier.

[Skysnake]

Ja, und deswegen zieht ja auch dein Argument nicht, weil sich daran nichts ändert, man die Sache eher sogar noch schlimmer macht, weil man eben in der Form, wie nVidia es verkündet, keinen Vorteil daraus durch Power/clockgating ziehen kann, weil das viel zu feingranular wäre, als das man das praktikabel umsetzen könnte.

Hab ich mich so schlecht ausgedrückt?

[PCGH_Carsten]

Offenbar reden wir aneinander vorbei.

Nvidia verneint nicht, dass sie physikalisch dedizierte DP-Blöcke drin haben.

MMn sind es 4 16er-Blöcke, die die Warp-Scheduler komplett okkupieren, sodass man wohl nicht 64 DP plus irgendwas schedulen kann. Möglich müssten aber bsw. 48 DP und 2x 32 SP o.ä. sein.

[Skysnake]

jetzt physikalisch und physisch durcheinander bringen ;)

physisch = ortsbezogen
physikalisch = real/in Hardware

Ich bezog mich darauf, dass die Integration von DP-Einheiten, die dediziert, also nicht über die SP-Einheiten gelöst sind, und in den SMX integriert sind, es absolut keinen Vorteil gibt, wie du ihn propagierst.

Erst wenn ALLE DP-Einheiten in einem auf dem Chip separierten Block zusammengefasst werden, kann es zu den von dir genannten Vorteil kommen. Vorher scheitert das einfach am Overhead, die dafür nötigen Features zu integrieren.

Genau das verneint nVidia ja aber wie schon gesagt. Sie sagen eben nicht, das es irgendwo auf dem Chip nochmal einen DP-Block gibt, sondern stecken das alles mit den SP-Units zusammen in die SMX, und genau da haste dann eben keinen Vorteil, weil du die Power/Clock-Gatings nicht so implementieren kannst.

Da würdest du den Chip einfach nur aufblähen

[PCGH_Carsten]

Ok, dann weißt du jetzt zumindest, wovon ich spreche bzw. ich nach deiner Definition von physisch/physikalisch, wovon du sprichst.

Und offenbar sind wir einfach verschiedener Ansicht. Ich propagiere btw. nichts, sondern versuche eine Logik hinter beiden Verfahren zu erkennen und diese gegeneinander abzuwägen.

[Gipsel]

Offenbar reden wir aneinander vorbei.

Nvidia verneint nicht, dass sie physikalisch dedizierte DP-Blöcke drin haben.

MMn sind es 4 16er-Blöcke, die die Warp-Scheduler komplett okkupieren, sodass man wohl nicht 64 DP plus irgendwas schedulen kann. Möglich müssten aber bsw. 48 DP und 2x 32 SP o.ä. sein.
nV sagt, daß dual-issue auch mit DP geht, es belegt also nur einen der beiden issue Ports der Scheduler. Damit muß mehr als das gehen, wie ich schon schrieb. Wenn GK110 nicht mindestens 128 SP Instruktionen + 64DP Instruktionen gleichzeitig pro Takt und SMx schafft, gibt es keine dedizierten DP-Einheiten.

Wenn es dedizierte Einheiten wären, die sich aber nur betreiben lassen, wenn die normalen SP-Einheiten komplett ruhen (warum sollte das der Fall sein?), welche Vorteile hat man dann gegenüber multiple precision Einheiten, die entweder SP oder DP rechnen können? Außer natürlich, daß multiple precision Einheiten in der Summe deutlich kleiner wären und die Anbindung an den Scheduler und die Datenpfade zu den Regfiles nicht doppelt verbaut werden müssen. :rolleyes:
Das bißchen Mehr an Energieeffizienz, welches SP-only oder DP-only Einheiten gegenüber multiple precision Einheiten bieten könnten, wird durch den zusätzlichen Overhead dreimal wieder zunichte gemacht.

[PCGH_Carsten]

nV sagt, daß dual-issue auch mit DP geht, es belegt also nur einen der beiden issue Ports der Scheduler.

Wo sagen sie das?
edit: Ah, das Blockieren des zweiten Schedulers (nicht Issue Ports) bezog sich explizit auf Fermi, da war das ja sowieso noch anders).

[Gipsel]

Wo sagen sie das?
Kepler Whitepaper, Abschnitt "Quad Warp Scheduler":
Quad Warp Scheduler

The SMX schedules threads in groups of 32 parallel threads called warps. Each SMX features four warp schedulers and eight instruction dispatch units, allowing four warps to be issued and executed concurrently. Kepler’s quad warp scheduler selects four warps, and two independent instructions per warp can be dispatched each cycle. Unlike Fermi, which did not permit double precision instructions to be paired with other instructions, Kepler GK110 allows double precision instructions to be paired with other instructions.

[Skysnake]

Und genau das spricht eben dafür, das man, eben an eine DP:SP 1:2 Einheit mit 128 ALUs eben noch mal nen 64er Block drangepappt hat, der nur SP kann. So kann man das mit dem Sheduler, Registerzugriffen usw usw. recht optimal lösen und eben auch gleichzeitig DP und SP Instruktionen mischen.

So würde ich das zumindest konzeptionell anpacken.

[PCGH_Carsten]

Kepler Whitepaper, Abschnitt "Quad Warp Scheduler":

In der Version, die ich hier habe steht allerdings:
„… with certain other instructions that have no register file reads, including load/store, texture and some integer instructions…“

Vermutlich hatte ich das oben noch im Hinterkopf. :)

Und genau das spricht eben dafür, das man, eben an eine DP:SP 1:2 Einheit mit 128 ALUs eben noch mal nen 64er Block drangepappt hat, der nur SP kann. So kann man das mit dem Sheduler, Registerzugriffen usw usw. recht optimal lösen und eben auch gleichzeitig DP und SP Instruktionen mischen.

So würde ich das zumindest konzeptionell anpacken.

So hatte ich das ja ursprünglich auch mal gedacht, aber bei diversen Nachfragen u.a. auf der GTC blieb Nvidia ziemlich fest bei der Behauptung, es wären dedizierte Einheiten (um mal das "phys./phys." loszuwerden.

[Gipsel]

In der Version, die ich hier habe steht allerdings:
„… with certain other instructions that have no register file reads, including load/store, texture and some integer instructions…“Das war wohl die alte Version, in der neuen steht das, was ich zitiert habe.
Die ersten Dinge zu GK110 waren noch fehlerbehaftet (auch die Durchsatzangaben im Programming Manual). Denn eines steht fest, auch load/store, Textur- oder Integerinstruktionen führen üblicherweise register file reads aus. ;)

Aber selbst wenn es kein Pairing bei DP-Instruktionen gibt, muß ein Kepler-SMx immer noch simultan 128SP + 64 DP-Instruktionen pro Takt schaffen. Das ist die gleiche Größe, die ich oben für den Fall von Registerport-Beschränkungen aufgeführt habe.

[PCGH_Carsten]

Dann schaun wir einfach mal... muss nur noch ein GK110 hier aufschlagen. :)

[Coda]

Genau das verneint nVidia ja aber wie schon gesagt. Sie sagen eben nicht, das es irgendwo auf dem Chip nochmal einen DP-Block gibt, sondern stecken das alles mit den SP-Units zusammen in die SMX, und genau da haste dann eben keinen Vorteil, weil du die Power/Clock-Gatings nicht so implementieren kannst.
WTF? AMD schält bei Bobcat/Jaguar sogar pro Instruction die oberen 32 bit des Integer-Datapath ab.

Power Gating ist was anderes, aber die Clock kannst du natürlich beliebig an und ausschalten.

[Skysnake]

CPU!=GPU

Wobei mir das innerhalb der Pipeline neu ist bei CPUs.

CPUs sind da aber eh allgemein deutlich feingranularer als GPUs.

Wir können uns aber gern auf das clock-gating einigen, auch wenn ich es bei GPUs nicht für wahrscheinlich halte. Ist das ganze Design doch auf Durchsatz optimiert, was zur Folge hat, das man allgemein eher ganze Blöcke abschaltet, und nicht nur teilbereiche.

[Ailuros]

Man lernt wohl jeden Tag dazu und ja es ist schoen in solchen Faellen eben nicht recht zu haben. Ich hab ein bisschen herumgefragt bei hocherfahrenen engineers ausserhalb NV und ja getrennte Einheiten wenn es zum Stromverbrauch kommt sind die bessere Idee.

Ich gehe jetzt nicht in Einzelheiten aber mir wurde u.a. gesagt dass eine FP64 Einheit <0.05mm2@40nm.

[Skysnake]

Wären bei GK104 also 4,8mm². Tut also nicht wirklich weh. Bei GK110 wären es aber 48mm². Das ist jetzt nicht nichts. Selbst bei nem >500mm² Chip.

Viel interessanter ist dabei aber vor allem, ob die 0,05mm² nur die ALUs an sich sind, oder inkl. der kompletten Ansteuerlogik. Ich gehe schwer davon aus, das es nur die ALUs an und für sich sind.

[Ailuros]

Wären bei GK104 also 4,8mm². Tut also nicht wirklich weh. Bei GK110 wären es aber 48mm². Das ist jetzt nicht nichts. Selbst bei nem >500mm² Chip.

Erstens ist es angeblich unter <0.05 und zweitens unter 40nm. Alle Kepler chips werden bisher unter 28HP hergestellt.

Viel interessanter ist dabei aber vor allem, ob die 0,05mm² nur die ALUs an sich sind, oder inkl. der kompletten Ansteuerlogik. Ich gehe schwer davon aus, das es nur die ALUs an und für sich sind.

Wenn es nur schaetzungsweise 24-26mm2@28nm fuer GK110 sind wird wohl die surrounding logic auf keinen Fall mehr sein :P

***edit: wurde mir heute bevor ich herumgefragt habe geschickt: http://www.nvidia.com/content/GTC/documents/SC09_Dally.pdf

Dally behauptet fuer eine 64bit FPU bei 1.5GHz 0.1mm2. Bei seinem hypothetischem CMOS canvas von 20*20mm2 passen tatsaechlich 4000 solche FPUs theoretisch rein. Schon das klang mir "too good to be true" ergo hab ich schnell herumgefragt. Vorsicht: hotclock ie 1.5GHz sind nicht umsonst wenn es zu die area kommt, und nein er meint auch nicht 40nm obwohl es Fermi Referenzen in der Praesentation gibt.

[Skysnake]

Sorry, die 40nm sind mir grad irgendwie durch :-_-:

Bzgl Ansteuerungslogik ist das halt so ne Sache. Ich würde es nicht als klar darstellen, dass die Ansteuerungslogik also inkl Wires weniger ausmacht, als die ALUs an und für sich. Ist halt alles SEHR Implementierungsabhängig.

Ich frag mich dennoch, wie man durch die dedizierten Einheiten die Nachteile durch verlängerte Wege ausgleichen will. Wenn man SP/DP Units verwendet ist der Unterschied ja marginal, aber bei dedizierten?

Ich kanns noch immer nicht so wirklich glauben. Naja, wir werden ja sehen, wies weiter geht in den nächsten Generationen. Wenn andere auch auf den Trichter kommen, dann muss wohl wirklich was dran sein, wenns bei Kepler aber bleibt, dann bleibt auch der Zweifel bestehen.

[Ailuros]

Sorry, die 40nm sind mir grad irgendwie durch :-_-:

Keine Sorge; bei mir sind brainfarts in der Zwischenzeit schon Kunst :P

Bzgl Ansteuerungslogik ist das halt so ne Sache. Ich würde es nicht als klar darstellen, dass die Ansteuerungslogik also inkl Wires weniger ausmacht, als die ALUs an und für sich. Ist halt alles SEHR Implementierungsabhängig.

Ich frag mich dennoch, wie man durch die dedizierten Einheiten die Nachteile durch verlängerte Wege ausgleichen will. Wenn man SP/DP Units verwendet ist der Unterschied ja marginal, aber bei dedizierten?

Kurz und vereinfacht: von der die area Perspektive gewinnt natuerlich die Loesung von Einheiten die ueber FP32 und FP64 faehig sind. Aber von der Stromverbrauchs-Perskeptive wird es schnell zu einem anderen Kapitel wenn low und high precision Operationen (auf den gleichen Einheiten) um einiges mehr Strom verbraten durch das ganze muxing und routing das man dafuer braucht.

Ich kanns noch immer nicht so wirklich glauben. Naja, wir werden ja sehen, wies weiter geht in den nächsten Generationen. Wenn andere auch auf den Trichter kommen, dann muss wohl wirklich was dran sein, wenns bei Kepler aber bleibt, dann bleibt auch der Zweifel bestehen.

Och NV ist traditionell nie besonders sparsam mit die area gewesen auf ihren high end chips. Ich wollte und konnte es selber nicht glauben, aber dafuer hab ich auch viel zu wenig Ahnung von der Materie.

[Skysnake]

Ja, scheint anscheinend im Moment ne echte brainfarts-Epedemie zu geben, wenn man sich die Threads in letzter Zeit mal so anschaut ;D

Ich finds halt immer noch sehr seltsam, da ich nicht seh, wo man denn so viel einsparen will. So groß unterscheiden sich ja reine DP-Units nicht von SP-DP-Units. Zumal ja nVidia selbst erkannt hat, das die Energiekosten für das hin und her schicken der Daten schnell die größte Bedeutung hat. :ka:

[PCGH_Carsten]

Was braucht man an Ansteuerlogik außerhalb der eh vorhandenen Warp-Scheduler und Dispatcher denn noch so alles? Was das Wiring angeht, spart man schon eine ganze Menge dadurch, dass da 1.536 bzw. 2.880 Adder und Muls nicht drei oder vier Bits (wieviel sinds noch gleich für Dual-Precision fähige Einheiten? 27 Bit Muls? Ich weiß es grad auf der Couch nicht) extra mit rumschleppen müssen, die dann hinterher noch gemuxt werden müssen usw. usf.

[Gipsel]

Erstens ist es angeblich unter <0.05 und zweitens unter 40nm. Alle Kepler chips werden bisher unter 28HP hergestellt.Dann ist es mit Sicherheit ein praktisch nacktes FMA. Ich habe kürzlich mal ein Paper gesehen, in denen die Implementation eines FMA64 (nicht multiprecision-fähig) in 28nm (für knapp 1GHz Zielfrequenz synthetisiert) mit ~0,025mm² angegeben war, ein FMA32 mit ~0,01mm².
Multi-Precision-Ausführungen gibt es mit recht geringem Zusatzaufwand (<20%, und da werden die ungenutzten Bitlanes auch bereits per clockgating inaktiv geschaltet). Das ist auf jeden Fall billiger und vermutlich sogar insgesamt stromsparender, als 2 FMA32 + 1 FMA64 zu verbauen.
Wenn es nur schaetzungsweise 24-26mm2@28nm fuer GK110 sind wird wohl die surrounding logic auf keinen Fall mehr sein :PDa kann man sich täuschen, insbesondere, da wir hier mit dem Stromverbrauch argumentieren. Ein FMA macht noch lange keine vollständige ALU bzw. keinen SP. Das Ding muß zum einen noch deutlich mehr können (Integer, Vergleiche, Bitmanipulationen und und und). Und zum Anderen ist die Anbindung an die Registerfiles (bei AMD noch zusätzlich die Result-Forwarding-Logik) nicht zu unterschätzen. Und da Du Dally angesprochen hast, sollte man hier vielleicht nochmal erwähnen, daß er auch gesagt hat, daß bei Fermi das Lesen der Operanden aus dem Registerfile mehr Energie kostet als die Berechnung eines FMA. Die Datenpfade nun zu einer weiteren (im Zweifelsfall also weiter entfernten) Einheit ziehen zu müssen, kann da nicht wirklich gut für die Gesamtbetrachtung sein (wobei Fermi in dieser Beziehung vermutlich deutlich schlechter ist als Kepler).

Aber wie schon mal gesagt: grau ist alle Theorie. Wenn irgendjemand mal seine Finger an einen GK110 bekommt und nachmißt, wie viele SP und DP-Operationen simultan möglich sind, sollte man das rausbekommen.
Und irgendwie hat nV ja auch im Vergleich zu GCN kräftig an den RegFiles gespart (die 8MB bei Tahiti quetschen sich allerdings auf nur knapp 25mm² zusammen :eek:). Mit irgendwas müssen sie ja die Fläche belegen und wer weiß, was die da wirklich intern machen (die Durchsätze für Integer-, Vergleichs- und Logikoperationen sind z.B. etwas dubios). ;)
Naja, zumindest sehen die ALUs bei GK110 deutlich anders aus als bei GK104 (also wenn man nV hier mal mit den Dieshots vertrauen kann). Der interne Aufbau kann also durchaus deutlich unterschiedlicher sein, als man von den nominell ähnlichen Daten der SMx erwarten würde.

[Ailuros]

Dann ist es mit Sicherheit ein praktisch nacktes FMA. Ich habe kürzlich mal ein Paper gesehen, in denen die Implementation eines FMA64 (nicht multiprecision-fähig) in 28nm (für knapp 1GHz Zielfrequenz synthetisiert) mit ~0,025mm² angegeben war, ein FMA32 mit ~0,01mm².

Erwarte jetzt bloss nicht dass ich jeglichen Fetzen in die Oeffentlichkeit schiesse. Das Prinzip der Sache duerfte aber schon stimmen insgesamt. Komisch dass ich den synthesis Wert schon schlagartig getroffen habe ohne besondere Ahnung von der Materie zu haben oder?


Da kann man sich täuschen, insbesondere, da wir hier mit dem Stromverbrauch argumentieren. Ein FMA macht noch lange keine vollständige ALU bzw. keinen SP. Das Ding muß zum einen noch deutlich mehr können (Integer, Vergleiche, Bitmanipulationen und und und). Und zum Anderen ist die Anbindung an die Registerfiles (bei AMD noch zusätzlich die Result-Forwarding-Logik) nicht zu unterschätzen. Und da Du Dally angesprochen hast, sollte man hier vielleicht nochmal erwähnen, daß er auch gesagt hat, daß bei Fermi das Lesen der Operanden aus dem Registerfile mehr Energie kostet als die Berechnung eines FMA. Die Datenpfade nun zu einer weiteren (im Zweifelsfall also weiter entfernten) Einheit ziehen zu müssen, kann da nicht wirklich gut für die Gesamtbetrachtung sein (wobei Fermi in dieser Beziehung vermutlich deutlich schlechter ist als Kepler).

Aber wie schon mal gesagt: grau ist alle Theorie. Wenn irgendjemand mal seine Finger an einen GK110 bekommt und nachmißt, wie viele SP und DP-Operationen simultan möglich sind, sollte man das rausbekommen.
Und irgendwie hat nV ja auch im Vergleich zu GCN kräftig an den RegFiles gespart (die 8MB bei Tahiti quetschen sich allerdings auf nur knapp 25mm² zusammen :eek:). Mit irgendwas müssen sie ja die Fläche belegen und wer weiß, was die da wirklich intern machen (die Durchsätze für Integer-, Vergleichs- und Logikoperationen sind z.B. etwas dubios). ;)
Naja, zumindest sehen die ALUs bei GK110 deutlich anders aus als bei GK104 (also wenn man nV hier mal mit den Dieshots vertrauen kann). Der interne Aufbau kann also durchaus deutlich unterschiedlicher sein, als man von den nominell ähnlichen Daten der SMx erwarten würde.

Ich hab ja selber den floorplan mit den dedizierten FP64 ALUs von Anfang bezweifelt. Es ist eben nicht so dass ich das obrige und jegliche durchaus gerechtfertigte Zweifel nicht verstehen kann, ueberhaupt da ich was die Perspektive betrifft vor kurzem noch auf der gleichen Seite lag.

Ich bin mir nichtmal sicher dass wenn man wirklich (ausserhalb von IHVs/engineers) von unserem Standpunkt einen GK110 unter die Lupe nimmt (so weit wie es ueberhaupt ohne die richtigen tools geht), dass alles zu 100% eindeutig wird.

Sonst wird es immer teilweise tradeoffs geben egal ob man so verschwenderisch mit die area umgeht wie NV oder nicht. AMD hat und braucht es nicht fuer ihre Strategie so brutal grosse dies zu entwickeln, eben weil sie mit sehr gutem perf/mm2 ankommen und auch keine so hohe Ziele wie NV fuer workstations und HPC anlegen. Wenn man dann mit einem ziemlich kleineren die in 3D nur noch einen relativ kleinen Leistungsunterschied hat als ein 550mm2/GK110 dann Hut ab.

Das eigentliche Ziel fuer Kepler war N Leistung zu erreichen ohne den Stromverbrauch um brutale Prozentuale zu sprengen. So weit haben sie es bis zu GK104 geschafft, bleibt abzusehen wie es genau auf GK110 aussehen wird.

Nebenbei und ich hab es schon etliche Male erwaehnt: laut NV engineering haben sie jegliche Architektur vor Kepler analysiert wo und bis zu welchem Punkt hotclocking ein Vorteil sein koennte. Nur weil Kepler hotclocking abgeschafft hat heisst es jetzt nicht unbedingt dass es von G80 bis GF1x0 eine Schnappsidee war. Du weisst besser als ich wie kompliziert GPUs sind und wenn man nicht alle Einzelheiten genau weiss, man kinderleicht auf Glatteis stampfen kann. Nur wenn man eine gesunde Anzahl von Teilen eines Puzzles kann man raten wie in etwa das komplette Bild aussieht.

[Gipsel]

Was braucht man an Ansteuerlogik außerhalb der eh vorhandenen Warp-Scheduler und Dispatcher denn noch so alles?Na außer eine zusätzliche Einheit da mit einzubeziehen, muß man z.B. auch sicherstellen, daß die gelesenen Daten aus den Regfiles bei der richtigen Einheit landen und das Ergebnis wieder im Regfile. Wenn man da nicht gleich einen weiteren Port ans Regfile kleben will (das tut man sicher nicht), so muß man zumindest die 3x 64 Bit Eingangsoperanden und die 64Bit Resultat an die entsprechenden Register-Read- und Result-Busse anflanschen und die entsprechend zu der FMA64-Einheit durchschalten, wenn die was tun soll ist.
Was das Wiring angeht, spart man schon eine ganze Menge dadurch, dass da 1.536 bzw. 2.880 Adder und Muls nicht drei oder vier Bits (wieviel sinds noch gleich für Dual-Precision fähige Einheiten? 27 Bit Muls? Ich weiß es grad auf der Couch nicht) extra mit rumschleppen müssen, die dann hinterher noch gemuxt werden müssen usw. usf.Na, da sind dann aber nur die drei Bits redundant. Wenn man separate SP und DP-Einheiten verbaut, liegen die jeweils anderen komplett ungenutzt rum. ;)

Bei einer 1:4 Rate DP:SP benötigt man entweder vier 27x27 Multiplier oder
vier 24x24 Multiplier + einen 53x53 Multiplier:
4 * 27² = 2916
4 * 24² + 53² = 5113
3 * 24² + 53² = 4537 [edit: Sparversion, wo der breite Multiplier mit ein paar Modifikationen auch für SP genutzt wird, oft schwierig wegen Latenzunterschieden, erschwert das Scheduling]

Bei einer 1:2 Rate benötigt man entweder zwei 27x53 Mutiplier oder zwei 24x24 Multiplier + einen 53x53 Multiplier:
2 * 27 * 53 = 2862 (fast gleicher Aufwand aber nur die Hälfte der SP-Performance im Vergleich zur 1:4-Variante!)
2 * 24² + 53² = 3961
24² + 53² = 3385 [edit: Sparversion]

Und noch für 1:3 (als 1:2+1 angenommen):
24² + 2*27*53 = 3438
3 * 24² + 53² = 4537
2 * 24² + 53² = 3961 [edit: Sparversion]

Das ist jetzt nur der Aufwand für den Multiplier-Teil (pro FP64 MUL), aber eine Addition ist vergleichsweise billig (und skaliert auch nicht quadratisch mit der Operandengröße). Wie man sieht, lohnt sich 1:2 eigentlich nur, wenn die Versorgung mit Operanden nicht günstig zu erweitern ist (die 1:4-Varianten benötigen ja für SP die doppelte Registerbandbreite), wie z.B. bei hochtaktenden CPUs. Steht genügend Bandbreite mit wenig Aufwand zur Verfügung bzw. ist der eigentliche Logikaufwand dominierend, nimmt man wohl lieber die höhere SP-Performance mit (sogar Bobcat und Jaguar machen MULs nur mit 1:4), solange die nicht nebensächlich ist.

[Coda]

CPU!=GPU
Spielt dafür keine Rolle. Die Clock ist einfach nur ein weiteres Signal.

Das Problem ist das Power-Gating, weil das tatsächlich erhebliche Latenzen verursacht, weil die großen Transistoren dafür sehr langsam schalten.

[PCGH_Carsten]

Na außer eine zusätzliche Einheit da mit einzubeziehen, muß man z.B. auch sicherstellen, daß die gelesenen Daten aus den Regfiles bei der richtigen Einheit landen und das Ergebnis wieder im Regfile. Wenn man da nicht gleich einen weiteren Port ans Regfile kleben will (das tut man sicher nicht), so muß man zumindest die 3x 64 Bit Eingangsoperanden und die 64Bit Resultat an die entsprechenden Register-Read- und Result-Busse anflanschen und die entsprechend zu der FMA64-Einheit durchschalten, wenn die was tun soll ist.
Ah ja, gut, die Ports am Regfile könnte man die nicht quasi doppelt verdrahten, bzw. je zwei für SP-Einheiten auf eine DP schalten? Als Laie würde ich mir da sowas wie ein Y-Kabel inkl. Weiche zwischen Reg-File und FP-Einheiten vorstellen.


Na, da sind dann aber nur die drei Bits redundant. Wenn man separate SP und DP-Einheiten verbaut, liegen die jeweils anderen komplett ungenutzt rum. ;)
Der Unterschied, den ich mir so vorstelle - besonders unter dem Gesichtspunkt von Power > Area - wäre halt, dass die überflüssigen Bits bei Multi-Precision-Einheiten immer mitschalten müssten, man komplette Einheiten aber mindestens clock- wenn nicht sogar powergaten kann. Die von Coda angeführten, großen Latenzen dafür wären ja kein Problem, da bereits der Treibercompiler weiß, wann ein DP kommt und entsprechend ein Flag setzen kann, die DP-Einheiten aufzuwecken.


Bei einer 1:4 Rate DP:SP benötigt man entweder vier 27x27 Multiplier oder
vier 24x24 Multiplier + einen 53x53 Multiplier:
4 * 27² = 2916
4 * 24² + 53² = 5113
3 * 24² + 53² = 4537 [edit: Sparversion, wo der breite Multiplier mit ein paar Modifikationen auch für SP genutzt wird, oft schwierig wegen Latenzunterschieden, erschwert das Scheduling]

Bei einer 1:2 Rate benötigt man entweder zwei 27x53 Mutiplier oder zwei 24x24 Multiplier + einen 53x53 Multiplier:
2 * 27 * 53 = 2862 (fast gleicher Aufwand aber nur die Hälfte der SP-Performance im Vergleich zur 1:4-Variante!)
2 * 24² + 53² = 3961
24² + 53² = 3385 [edit: Sparversion]

Und noch für 1:3 (als 1:2+1 angenommen):
24² + 2*27*53 = 3438
3 * 24² + 53² = 4537
2 * 24² + 53² = 3961 [edit: Sparversion]

Das ist jetzt nur der Aufwand für den Multiplier-Teil (pro FP64 MUL), aber eine Addition ist vergleichsweise billig (und skaliert auch nicht quadratisch mit der Operandengröße). Wie man sieht, lohnt sich 1:2 eigentlich nur, wenn die Versorgung mit Operanden nicht günstig zu erweitern ist (die 1:4-Varianten benötigen ja für SP die doppelte Registerbandbreite), wie z.B. bei hochtaktenden CPUs. Steht genügend Bandbreite mit wenig Aufwand zur Verfügung bzw. ist der eigentliche Logikaufwand dominierend, nimmt man wohl lieber die höhere SP-Performance mit (sogar Bobcat und Jaguar machen MULs nur mit 1:4), solange die nicht nebensächlich ist.

Irgendwie klingen nun dedizierte Einheiten gar nicht mal mehr sooo teuer. ;)

edit:
Damit ich nicht nochmal das durchgekaute Thema weiter unten aufwärme:
Das lernt man einfach schon in der Uni, in Chipdesign/ASIC-Entwurf, wie "einfach" es ist aus SP-Einheiten DP-Einheiten zu bauen. Das sind halt echt basics, und ich hab noch NIE jemanden gehört, der sich auch nur minimal in der Materie auskennt, der das auch nur im entferntesten realistisch hält.
Schön, dass sich das nun aufgeklärt hat - und nicht jemand der anderes behauptete, nun als jemand dasteht, der sich „nichtmal minimalst mit der Materie auskennt.“

[Skysnake]

Spielt dafür keine Rolle. Die Clock ist einfach nur ein weiteres Signal.
[\quote]
Jaein. Wenn du die DP-Units in einem Block zusammenfasst, dann ja, da geb ich dir absolut recht, das ist dann kein Problem.

Wenn die das aber "einfach" in die SMX mit reingewurschtelt haben, und, wie das bei GPUs eher der Fall ist, relativ weit verstreut ist, um eben alles unter zu bekommen, ohne die Latenzen zu weit auseinander driften zu lassen, dann stelle ich mir das SEHR schwierig vor, das vernünftig zu machen. Du musst ja auch wieder Ansteuerungslogik implementieren, und dann den Overhead für die paar Units pro SMX? Da laufen Kosten und Nutzen auch ziemlich schnell wieder auseinander. Ist ja auch nicht so, dass die Clocks sich von allein ab und wieder an schalten, und schon gar nicht so, dass die Clock auch gleich wieder stabil anliegt...

Daher halte ich dedizierte DP-Units gleichmäßig aufgeteilt auf alle SMX eher unwahrscheinlich.

[quote]
Das Problem ist das Power-Gating, weil das tatsächlich erhebliche Latenzen verursacht, weil die großen Transistoren dafür sehr langsam schalten.
Da eh

Ah ja, gut, die Ports am Regfile könnte man die nicht quasi doppelt verdrahten, bzw. je zwei für SP-Einheiten auf eine DP schalten? Als Laie würde ich mir da sowas wie ein Y-Kabel inkl. Weiche zwischen Reg-File und FP-Einheiten vorstellen.

Sollte mit recht wenig Aufwand möglich sein. Ich erinnere mich grad leider nur noch dunkel an das entsprechende Schaltbild, aber das sollte in einem Full-Custom-ASIC mit sehr wenig Aufwand machbar sein. Das Problem ist an der Stelle aber gar nicht, ob das überhaupt geht, sondern wie man denn die zusätzlichen Leitungen unter bekommt. Mit dedizierten Leitungen hat man ja sehr viele zusätzliche Wires.

Dazu kommt eben noch, das man auch pinibel darauf achten muss, das es zu keinen Kollisionen kommt, was aber jetzt kein unlösbares Problem darstellt. Man muss das aber eben auch noch beachten. Und genau das ist halt der Knackpunkt. Es gibt jetzt nicht DAS unlösbare Problem, und nicht DAS Totschlagargument, aber in Summe sinds einfach so unglaublich viele Kleinigkeiten, die dagegen sprechen, und die einem das Leben einfach schwerer machen, das es einem schwer fällt, zu glauben, dass Sie das wirklich gemacht haben. Wir reden hier ja nicht um Effizienzsteigerungen von 100% oder so, sondern vielleicht von 10 oder vielleicht auch 20% (nur auf die einzelne ALU bezogen, welche ja aber nichtmal DER Ausschlaggebende Punkt ist, sondern ganz andere Sachen...) Da laufen einfach Aufwand und Nutzen selbst bei optimaler Implementierung ziemlich schnell meiner Meinung nach auseinander.


Der Unterschied, den ich mir so vorstelle - besonders unter dem Gesichtspunkt von Power > Area - wäre halt, dass die überflüssigen Bits bei Multi-Precision-Einheiten immer mitschalten müssten, man komplette Einheiten aber mindestens clock- wenn nicht sogar powergaten kann. Die von Coda angeführten, großen Latenzen dafür wären ja kein Problem, da bereits der Treibercompiler weiß, wann ein DP kommt und entsprechend ein Flag setzen kann, die DP-Einheiten aufzuwecken.

Jaein.

Kommt halt auch wieder drauf an. Wenn die paar dedizierten DP-Units abschaltbar sind, und es sich lohnt, kann man sicherlich auch die nicht benötigten DP-Teile bei den DP-SP-Units abschalten, oder eben andersrum.

Läuft mehr oder weniger auf die gleiche Problemstellung hinaus.


Irgendwie klingen nun dedizierte Einheiten gar nicht mal mehr sooo teuer. ;)
Naja, denk immer dran, dass du eben jeweils noch die Wires brauchst, und bei solchen Designs hat man innerhalb der ALUs eigentlich schön alles nacheinander geschaltet, so das man richtige Wires nicht wirklich braucht zu einem guten Teil. Wenn man jetzt aber einfach nochmal X "Wires" verlegen muss, wirds enger, wenns enger wird, muss man weitere Wege gehene, wenn man weitere Wege geht, braucht man wieder mehr Energie....

Ich hoffe du siehst worauf das hinaus läuft.

Es ist ja nicht so, das man auf ner GPU freie Flächen hätte, wo man einfach mal was dazu pappen könnte. Das sind schon ziemlich dicht gepackte Chips.

Kurz um, ich seh das noch immer ziemlich skeptisch, und bezweifle stark, das es real so aussieht, wie das Marketing und weis machen will. Der Teufel steckt eben im Detail, und da wird dann schon hier und da was getrickst worden sein.

Ansonsten kann ich mich da Gipsel nur anschließen, auch wenn ich mir in der Erklärung deutlich schwerer tu als er. Ich hab ins Chipdesign halt reinschnuppern können, und auch immer wieder mit Leuten zu tun, die eben genau das machen. Da entwickelt man langsam eine Nase dafür, wo die Fallstricke sind. Bei mehr wirds eh SEHR schwierig, da man eben vieles im Gesamtkontext sehen muss, und für Design A Lösung X super sein kann, für Design B aber der letzte Rotz... Es muss halt alles zusammen passen.

[Ailuros]

Ich vereinfache es mal so idiotisch wie moeglich damit es vielleicht etwas verstaendlicher wird:

Angenommen die zusaetzlichen DP Einheiten auf GK110 nehmen grosszuegig geschaetzt mit allem drum und dran um die 50-60mm2@28nm ein. Bei einem ~550mm2 Monster-die sind es =/>10%. Ergo hypothetisch "nackt" mit nur FP32 ALUs und all dem ueblichen drum und dran 490-500mm2.

Ich lass mich gern eines besseren belehren aber waere rein theoretisch es nicht die billigste Alternative 256 FMA32 mit einem 4:1 SP/DP ratio gewesen?

Milchmaedchen-rechnung:

14 SMXs * 256SPs * 2 FLOPs * 0.732GHz = 5247 GFLOPs / 4 = 1312 GFLOPs DP

Die brennende Frage im zweiten Fall waere eben ob das Resultat immer noch bei einem 235W TDP liegen wuerde oder ob es vielleicht doch mehr am Ende gewesen waere. Nochmal es hat keiner der befragten mehr die area fuer dedizierte FMA64 bezweifelt; es hat aber auch keiner weniger Stromverbrauch fuer jegliche loop Alternative bestaetigt, eher das Gegenteil.

Noch naiver: wie sieht es auf ersten Blick beim DP perf/W auf einer Tahiti genau aus? Es ist zwar schoen und gut mit die area Zahlen herumzuspielen aber es sollte wohl doch in Richtung Stromverbrauch gehen in solch einem Fall.

***edit: es ist zwar albern aber die originale Info fuer weit ueber 3k SPs fuer GK110 war wohl am Ende doch nicht so albern. Uebel vermittelt ja, denn es haette sich kein Schwein vorstellen koennen dass das Tier dedizierte FMA Einheiten haben wird.

Um auch das Thema langsam wieder auf Maxwell Ebene zurueckzubringen: ich hab keinen einzigen Zweifel dass sich der Trend mit den dedizierten 64b FPU auch ueber Maxwell und wohl auch Einstein erweitert. Wenn man auf NV's roadmap zurueckgeht, duerfte Maxwell eine noch brutalere Anzahl an 64b Einheiten haben als Kepler.

[Skysnake]

Ailuros, du vernachlässigst aber wieder komplett den Verdrahtungsaufwand, und die steigenden Entfernungen durch die größere Anzahl an Transistoren. Es ist halt nicht so einfach, das man sagen kann ALU X verbraucht x Watt und ALU Y verbraucht y Watt.

Gerade der von dir gepostete nVidia Link sollte doch klar machen, das eben die reine Weiterleitung von Daten sehr schnell deutlich mehr ausmacht, als die Berechnung an und für sich.

Wenn man dedizierte DP-Units rein packt, dann verändert sich aber das komplette Design. Da wird dir auch niemand apriori sagen können, was nun effizienter ist. Kommt ja ganz darauf an, wo und wie man denn die ganzen Sachen anordnen kann. Einfacher wird das Chipdesign dadurch auf jeden Fall nicht.

Es ist eigentlich eine ganz "einfache" Gleichung. Einsparung durch spezialisierte Einheiten vs Mehrverbrauch durch längere Wege.

Und die längeren Wege sollte man wirklich nicht unterschätzen. Es ist ja nicht so, das man nur einmal die 0,0xmm² hat, sondern zich mal + die ganze Wires/Logik zur Ansteuerung.

Bzgl dem 1:4
Natürlich wäre es "billiger" gewesen, aber nur auf den ersten Blick. Man hätte damit einfach nicht die DP-Leistung erreicht, die man wollte/braucht. Das ist ja die Abwägung die man machen muss. Größerer Chip für gleiche SP-Leistung, oder weniger SP-Leistung bei gleicher Chipgröße, wenn man statt 1:4, 1:2 oder 1:3 nutzt.

SP-Leistung ist halt "billig" zu haben. Für HPC wäre 1:2 optimal gewesen. Bzgl 3D/Gameing hätte man damit aber Potenzial brach liegen lassen.

1:3 ist halt ein Kompromiss.

[Ailuros]

Ailuros, du vernachlässigst aber wieder komplett den Verdrahtungsaufwand, und die steigenden Entfernungen durch die größere Anzahl an Transistoren. Es ist halt nicht so einfach, das man sagen kann ALU X verbraucht x Watt und ALU Y verbraucht y Watt.

Wenn Du handfeste Details dazu hast fuer GK110 schiess gerne los.

Wenn man dedizierte DP-Units rein packt, dann verändert sich aber das komplette Design. Da wird dir auch niemand apriori sagen können, was nun effizienter ist. Kommt ja ganz darauf an, wo und wie man denn die ganzen Sachen anordnen kann. Einfacher wird das Chipdesign dadurch auf jeden Fall nicht.

Sicher wird es nicht einfacher und schon gar nicht wenn man so ein Monster entwickelt das auch dazu noch eine der besten Loesungen sowohl fuer 3D als auch fuer HPC sein soll. Man hat A Leistungsziel bei B maximaler Chipkomplexitaet mit C Stromverbrauchsziel.

Es ist eigentlich eine ganz "einfache" Gleichung. Einsparung durch spezialisierte Einheiten vs Mehrverbrauch durch längere Wege.

Und die längeren Wege sollte man wirklich nicht unterschätzen. Es ist ja nicht so, das man nur einmal die 0,0xmm² hat, sondern zich mal + die ganze Wires/Logik zur Ansteuerung.

Wenn alles wirklich eine so "einfache" Gleichung waere gaebe es um zich Mal mehr hw engineers dort draussen. Ich hab erwaehnt dass ich es mit Absicht verdammt vereinfacht habe, eben weil es von Eurer Seite keine so "einfache" Formel gibt sich das alles auszurechnen, ausser Du hast NV's gesamte Kepler Dokumentantion in der Hand.

Bzgl dem 1:4
Natürlich wäre es "billiger" gewesen, aber nur auf den ersten Blick. Man hätte damit einfach nicht die DP-Leistung erreicht, die man wollte/braucht. Das ist ja die Abwägung die man machen muss. Größerer Chip für gleiche SP-Leistung, oder weniger SP-Leistung bei gleicher Chipgröße, wenn man statt 1:4, 1:2 oder 1:3 nutzt.

SP-Leistung ist halt "billig" zu haben. Für HPC wäre 1:2 optimal gewesen. Bzgl 3D/Gameing hätte man damit aber Potenzial brach liegen lassen.

1:3 ist halt ein Kompromiss.

3:1 SP/DP ratio sowohl auf hw als auch auf sw Nivaeu. Ein wahrer Kompromiss waere es eher gewesen wenn man jeweils 2*SIMD32 fuer FP64 loopen wuerde. In diesem Fall hat wohl NV bewusst die hoehere die area Anforderungen dieser Alternative geschluckt fuer einen maessigeren Stromverbrauch stets nach ihren eigenen Behauptungen. Jetzt rueck mal raus mit der "einfachen" Formel die das Gegenteil beweisst :biggrin:

[Skysnake]

Wenn alles wirklich eine so "einfache" Gleichung waere gaebe es um zich Mal mehr hw engineers dort draussen. Ich hab erwaehnt dass ich es mit Absicht verdammt vereinfacht habe, eben weil es von Eurer Seite keine so "einfache" Formel gibt sich das alles auszurechnen, ausser Du hast NV's gesamte Kepler Dokumentantion in der Hand.

Na, das Prinzip ist eigentlich schon "einfach", nur die reale Umsetzung ist halt mit unglaublich vielen Variablen gespickt, die dafür sorgen, das einem die Ideen ständig um die Ohren fliegen :ugly:

Stabhochsprung ist im Prinzip auch "einfach". Wer von uns kann aber auch die reale Umsetzung zeigen? ;D

Und genau deswegen braucht man ja auch wirklich gute Leute dafür. Du brauchst einfach zu einem gewissen Grad das "Näschen" dafür, was funktioniert und was nicht, da man alle Variablen gar nicht überblicken kann, und auch gar nicht in der Lage ist das Problem mit dem Rechner brutforce mäßig zu lösen. Dafür ist es einfach zu komplex :freak:

[Ailuros]

Na, das Prinzip ist eigentlich schon "einfach", nur die reale Umsetzung ist halt mit unglaublich vielen Variablen gespickt, die dafür sorgen, das einem die Ideen ständig um die Ohren fliegen :ugly:

Stabhochsprung ist im Prinzip auch "einfach". Wer von uns kann aber auch die reale Umsetzung zeigen? ;D

Und genau deswegen braucht man ja auch wirklich gute Leute dafür. Du brauchst einfach zu einem gewissen Grad das "Näschen" dafür, was funktioniert und was nicht, da man alle Variablen gar nicht überblicken kann, und auch gar nicht in der Lage ist das Problem mit dem Rechner brutforce mäßig zu lösen. Dafür ist es einfach zu komplex :freak:

Nochmal ich hab mit Absicht nicht NV gefragt weil jeder wohl nur eine Antwort erwartet haette. Ich hab auch nicht neutral gefragt ob Loesung A oder B theoretisch besser waere sondern klipp und klar ueber GK110. Es wird mir doch keiner einreden wollen, dass in der Zwischenzeit kein engineer von anderen IHVs einen solchen chip unter die Lupe genommen hat. Die Antworten waren nicht dass es immer und ueberall Sinn macht, sondern dass es frei uebersetzt unter den spezifischen Variablen die logischere Loesung war wenn einem Stromverbrauch nicht egal ist. Und Stromverbrauch ist eben nicht egal heutzutage selbst fuer high end desktop.

Kann durchaus sein dass eine aehnliche Masche fuer die Grundlagen der GCN Architektur nicht fuer dedizierte FP64 Einheiten gesprochen haben; es haette sich aber im Gegenfall mit Sicherheit keiner beschwert wenn der Tahiti die etwas groesser ausgefallen waere aber mit maessigerem Stromverbrauch. Mir kann solche Fragen auch keiner beantworten bzw. auch wieso AMD ihre mGPU Plaene diesmal storniert hat oder wieso ihre mGPU fuer den Profi-Markt so viel Strom verdonnert. Wir mussten ja selber beide darueber lachen wie AMD's marketing fuer das letzte die beste perf/W behauptete und es im unmittelbarem Anklang der Tesla K20-er absolut laecherlich klang.

[Skysnake]

Das wird dir auch NIE jemand sagen können, was du wissen willst. Dafür müsste man den Chip eben 1:1 rekonstruieren. Das kannste aber knicken. Selbst mit den orginal Designentwürfen von nVidia wäre es nicht leicht zu zeigen, dass das besser oder schlechter ist als es anders zu machen. Dafür müsste man eben die Alternative mit dem gleichen Aufwand implementieren. Alles andere ist halt reine Spekulation und "Bauchgefühl".

Ich hab schon synthetisierte Routings gesehen, und da fasst du dir teilweise einfach nur noch an den Kopf, was die Tools da machen. Es funktioniert aber.... "Verstehen" oder gar Vorhersagen, was Änderungen bewirken, kannste aber komplett knicken. Da heist es oft "Try and Error"

[|MatMan|]

Meinst du nicht man trifft solche wichtigen Entscheidungen nicht auf Basis eines Bauchgefühls sondern anhand von Simulationen und /oder Messungen von (Test-) Chips?

[Skysnake]

Naja, klar, man hat Erfahrungwerte, und verucht die Sachen auch zu unterteilen, um das Problem kleiner zu machen, aber ab nem gewissen Grad dreht man halt hier und dort an Schräubchen.

Man muss da ganz klar von Hand gezeichnete Designs mit solchen unterscheiden, die aus Tools kommen.

Die "Kunst" ist es halt, den Tools die richtigen constraints zu geben. Je nachdem kommt bei einer Simulation eben auch nen Chip raus, der gar nicht funktioniert wie gedacht.

Ne SRAM-Zelle kann man optimieren wie blöd, aber Logik ist immer so ne Sache. Wenn man was hier und dort hin schiebt, verändert sich teilweise recht viel am Chip.

Es ist ja nicht so, das man nur die reine Logik hat, die funktionieren muss. Das kann man auf mathematischem Weg lösen ohne Probleme. Das ist aber nur die halbe Miete. Die Signallaufzeigen müssen halt auch noch stimmen, UND man muss gleichzeitig die Prozess-constraints vom Hersteller einhalten, bzw. Firmen wie AMD und nVidia gehen weiter als die constraints es eigentlich zulassen. Die reizen halt die Prozesse aus.

Und genau da wirds halt extrem mit der Anzahl an Variablen. Das kann kein Mensch mehr wirklich überblicken. Das geht irgenwann wirklich nur noch durch Bauchgefühl, und nicht das man vorher weiß, dass das besser sein wird um x%.

Wie soll man auch das verhalten von hundertausenden Transistoren und Vias genau vorhersagen? Die tools rechnen aus so was ja nicht ohne Grund Stunden/Tage/Wochen rum.

Und das sind nur Teilbereiche... Und genau da kommt eben der Hacken an der Sache. Wenn man das gesamte Problem in die Tools schmeisen würde, würden die "nie" fertig werden. Wenn man aber partitioniert, muss man sich Gedanken über die Schnittpunkte machen, welche aber gleichzeitig wieder das gesamte Design beeinflussen.

Was du da halt machst ist, nen Bestcase annehmen, und sich dann auf 8x.x%+ annähern. Das sind aber eben auch wieder nur lokale Lösungen des Gesamtproblems... Ergo brauchst du halt irgendwo nen Anfang, wie immer im Leben, von dem du ausgehst, und dich dann schrittweise vorwärts hangelst. Genau dafür braucht man aber Erfahrung, was funktioniert und was nicht.

Ist nen bischen wie das Lösen von so manchem mathematischem Problem. Wenn man die Lösung kennt, ist es meist gar nicht so schwer, das Ganze nach zu vollziehen. Wenn man die Lösung nicht kennt, muss man die Lösung meist durch "genaues hinsehen" lösen. Man braucht halt einfach ein Gespür, wohin die Reise gehen soll. Wenn man das nicht hat für das Problem, dann kann man sich unter umständen ewig im Kreis drehen und das Problem nie lösen, obwohl man so knapp vor der Lösung steht.

[Ailuros]

Um mal auf Maxwell zurueckzukommen:

http://www.xbitlabs.com/news/graphics/display/20120827223641_Nvidia_s_GPU_Roadmap_Slips_by_One_Year_Due_to_Manufacturing_Nodes _Report.html

http://www.xbitlabs.com/images/news/2011-08/nvidia_kepler_maxwell_roadmap.jpg

NV plant fuer diesen drei Mal so viel DP FLOPs/W ergo irgendwo ueber 15 FLOPs DP/W. Milchmaedchenrechnung:

235W * 15.5 = 3643 GFLOPs DP

Bei hypothetischen 14 operativen clusters und rein erfundener Frequenz von 830MHz irgendwo in der 160SP SP/cluster Region und bei wieder hypothetischem Vollausbau von 15 clusters 2400 SPs/chip, bei 16 clusters 2560.

Zahlen koennten natuerlich nach oben oder nach unten spielen, aber so oder so wird die Anzahl der DP Einheiten ziemlich gross sein. Und zu dem Zeug sollen auch noch eine gesunde Anzahl an Denver cores reinkommen....

[Skysnake]

Naja, schauen wir mal 2014 oder 2015 bzgl Maxwell mit richtig fett DP-Leistung.

[Ailuros]

Naja, schauen wir mal 2014 oder 2015 bzgl Maxwell mit richtig fett DP-Leistung.

Ich frag mich eher inwiefern 3D Leistung weiterhin skalieren wird. Ein quasi Faktor 3x ist kein kleiner Happen und 20nm im Vergleich zu 28nm schluckt den Unterschied erstmal nicht.

[AnarchX]

Dazu hatte sich Jensen doch schon mal geäußert:
Die von Nvidia angegebenen Werte lassen aber keinerlei Rückschlüsse auf die eigentliche 3D-Leistung zu. Auf Nachfrage zur Leistung erklärte Huang während der folgenden Pressekonferenz lediglich, dass der 2013 erwartete Maxwell-Chip etwa um den Faktor 10 schneller sein wird als der aktuelle GF100.
http://www.heise.de/newsticker/meldung/GTC-Nvidia-gibt-Ausblick-auf-kommende-Grafikchips-1083430.html
:D

Wahrscheinlicher ist wohl eine größere Steigerung (>=50%) für shaderlastige Anwendungen, in deren Shadern wenige Abhängigkeiten existieren.

[Skysnake]

Ich frag mich eher inwiefern 3D Leistung weiterhin skalieren wird. Ein quasi Faktor 3x ist kein kleiner Happen und 20nm im Vergleich zu 28nm schluckt den Unterschied erstmal nicht.
Was hat DP-Perf/Watt mit 3D Leistung zu tun?

Im Prinzip kann man aber schon allein dadurch nochmal ~10% Leistung raus kitzeln, wenn man reine 3D Wiedergabe und sonstige Berechnungen trennt die nicht zwingend notwendig sind.

Ich hab mal nen schönnen Test gemacht mit RMDA, also schreiben/lesen auf den Speicher einer anderen GPU. Das war wirklich extrem, was allein die dumpfe 2D Wiedergabe an Leistung frisst, und die ganze Sache vorallem total unberechenbar bzgl Latenz macht.

Also im gesamten Bereich des Renderings und Mappings des Problems auf die GPU steckt noch unglaublich viel potenzial.

[Ailuros]

Was hat DP-Perf/Watt mit 3D Leistung zu tun?

Verdammt viel; denn es sind Transistoren die eben nicht fuer 3D gebraucht werden koennen.

Im Prinzip kann man aber schon allein dadurch nochmal ~10% Leistung raus kitzeln, wenn man reine 3D Wiedergabe und sonstige Berechnungen trennt die nicht zwingend notwendig sind.

Im Fall wo es sich um ausschliessliche FP64 Einheiten handelt wie bei Kepler, kann man heutzutage und auch ein paar Jahren genau was unter 3D damit anfangen?

Ich hab mal nen schönnen Test gemacht mit RMDA, also schreiben/lesen auf den Speicher einer anderen GPU. Das war wirklich extrem, was allein die dumpfe 2D Wiedergabe an Leistung frisst, und die ganze Sache vorallem total unberechenbar bzgl Latenz macht.

Also im gesamten Bereich des Renderings und Mappings des Problems auf die GPU steckt noch unglaublich viel potenzial.

Ich hab als Laie jetzt nur Bahnhof kapiert. Aber selbst wenn ein theoretisches zusaetzliches Schnaeppchen an Leistung fuer Gott weiss wer wann Entwickler es wirklich benutzen koennen sagt mir gar nichts, falls Du das damit meinst. Schau Dich um wie lange wir schon multi-core CPUs haben und inwiefern die multi-core Optimierungen wo immer sinnvoll in Applikationen im absoluten Schneckentempo anschleichen.

[Skysnake]

Ok, jetzt hab ich verstanden, worauf du hinaus willst ;D Jo, da bringt einem das nichts für 3D.

Bzgl Multi-GPU. Das wird praktisch schon genutzt, und zwar mit den Tesla+Quadro. Zwar prinzipiell eher wegen dem Preis. Es gibt aber auch Leistungsverbesserungen, wenn man sich nicht ständig mit Ausgabe in die Berechnungen reinballert.

[Ailuros]

Ok, jetzt hab ich verstanden, worauf du hinaus willst ;D Jo, da bringt einem das nichts für 3D.

Bzgl Multi-GPU. Das wird praktisch schon genutzt, und zwar mit den Tesla+Quadro. Zwar prinzipiell eher wegen dem Preis. Es gibt aber auch Leistungsverbesserungen, wenn man sich nicht ständig mit Ausgabe in die Berechnungen reinballert.

Ich sagte multi-core CPUs ist aber auch nebensaechlich. Keine Ahnung ueber Quadros aber mGPU bei Teslas skalieren relativ miserabel und wenn ich mich nicht irre haben wir es anhand eines NV pdfs mit Leistungszahlen auch im Kepler thread besprochen.

[Skysnake]

Also wenn du Visualisierung+GPGPU machen willst, dann ist das teilweise schon ziemlich gut, wenn man das auf getrennte Karten packen kann.

[Hübie]

Da GK110 für mich gestorben ist:
[x] Abo

Was ist stand der Dinge? Maxwell@28nm, ARM-Core (welche Aufgaben?) und schon 512 Bit SI?

[Ailuros]

Da GK110 für mich gestorben ist:
[x] Abo

Was ist stand der Dinge? Maxwell@28nm, ARM-Core (welche Aufgaben?) und schon 512 Bit SI?

So wie ich es bis jetzt verstehe wird der erste Maxwell core unter 28nm maximal ein GK104 Nachfolger sein. Ich kann mir nicht vorstellen dass Maxwell top dog je auf 28nm erscheinen wird, ueberhaupt wenn sich das Transistoren-budget fuer diesen nochmal grob verdoppeln sollte fuer GK110 (zumindest).

Fuer den ersten Fall waere wohl ein 512bit SI totaler overkill, wobei schon 384bit fraglich waere. Fuer den top dog keine Ahnung; aber es klingt mir auch hier 512bit uebertrieben.

[dargo]

Ich kann mir nicht vorstellen dass Maxwell top dog je auf 28nm erscheinen wird, ueberhaupt wenn sich das Transistoren-budget fuer diesen nochmal grob verdoppeln sollte fuer GK110 (zumindest).

Du meint ~14 Milliarden Transistoren? OMG... mir wird bei den Zahlen langsam schwindlich. :uroll:

[boxleitnerb]

Kann man mit einem verbesserten Cachesystem und 7Gbps GDDR5 vielleicht noch einmal mit 256bit antanzen bei GM104 oder wie er auch heißt?
Wann soll GDDR6 fertig sein? Falls es zeitlich nicht passt, könnte man ja auch nativ 320bit verbauen, wenn man nicht gleich in die Vollen gehen will.

Btw was ich mich die ganze Zeit schon frage:
Kommt jetzt ein normaler Kepler-Refresh oder nicht? Wenn man bis Mitte 2013 das Maxwell-Design fertig hätte, wäre es doch sinniger, das auf 28nm zu bringen, statt Kepler für 10-15% nochmal aufzuplustern, was dessen OC-Versionen eh schon schaffen.

[Ailuros]

Du meint ~14 Milliarden Transistoren? OMG... mir wird bei den Zahlen langsam schwindlich. :uroll:

Mich wuerden knapp unter 4 TFLOPs DP fuer Maxwell Tesla (wenn NV ihre roadmap einhalten kann) nicht ueberraschen. Unter der Vorraussetzung dass Teslas stets etwas kastriert sind in Frequenzen und NV bleibt bei 3:1 SP/DP bekomm ich theoretisch wie viele SP TFLOPs? Natuerlich wohl nicht vor H2 2014 wenn nicht sogar Anfang 2015.

[john carmack]

Du meint ~14 Milliarden Transistoren? OMG... mir wird bei den Zahlen langsam schwindlich. :uroll:

dann warte mal ab bis die Nvidia "Einstein" GPU kommt... also irgendwann 2016 oder 2017 :D

[fondness]

Übrigens, wenn man sich die aktuelle Roadmap ansieht, dann muss man nicht nur feststellen, das Fermi und Kepler ein bisschen rauf gerutscht sind, sondern auch das Maxwell ein bisschen runter gerutscht ist was DP GFLOPs/Watt betrifft:

http://img6.imageshack.us/img6/1315/nvroadmapsmall.png

http://img189.imageshack.us/img189/7966/keplermaxwellyearslip.jpg

Aus Faktor 3 wird so eine Steigerung von Faktor ~2.5 von Kepler auf Maxwell.

[Skysnake]

Rechnen wir mal lieber mit 2015...

Bzgl Speicher:
Ist GDDR6 überhaupt in Entwicklung?

Also ich hab davon bisher noch nichts gehört.

GDDR5 wird halt nochmals voll ausgequetscht mit nem 512 BIt Interface, und das wars dann auch.

Ich gehen eher von XDRAM oder Memory-Cube aus. Da hat man dann auch wirklich Entwicklungspotenzial, und gerade Memory-Cube kommt HSA EXTREM! entgegen.

EDIT:
Das ist doch schon lange bekannt.

Und wenn man nach den Werten, die man so hat/bekommt, hat Kepler das Perf/W Ziel real nicht ganz erreicht. War zumindest mal das, was ich nachgerechnet hatte.

[Ailuros]

Btw was ich mich die ganze Zeit schon frage:
Kommt jetzt ein normaler Kepler-Refresh oder nicht? Wenn man bis Mitte 2013 das Maxwell-Design fertig hätte, wäre es doch sinniger, das auf 28nm zu bringen, statt Kepler für 10-15% nochmal aufzuplustern, was dessen OC-Versionen eh schon schaffen.

Ich bezweifle dass sie die gesamte GK20x (oder wie immer das Zeug heisst) Entwicklung eingestampft haben. Ja es wird wohl um irgendwo 15% schneller sein aber uebertakten lassen sich die Dinger dann auch.

Wenn NV Maxwell performance fuer 28nm auslegen sollte (und es nicht irgend ein ersten low end notebook OEM Scheiss sein sollte), dann wird die die area auch ziemlich gross sein unter 28nm.

[boxleitnerb]

Hm, kann man mit Maxwell ohne Shrink die Perf/mm2 nicht verbessern?
Ich meine so ein Refresh kostet viel Geld und die Frage ist, ob der Aufwand in Verhältnis zum Nutzen steht. GT200 konnte man beim Refresh kleiner machen (65nm -> 55nm), Fermi musste man refreshen, weil v1 kaputt war. Aber bei Kepler hat man weder 20nm noch ist irgendwas kaputt. Lohnt sich das wirklich?

P.S.
Wofür steht das "T" in GT200(b)? Tesla? Beisst sich das nicht mit der Tesla-Serie?

[john carmack]

Rechnen wir mal lieber mit 2015...

Bzgl Speicher:
Ist GDDR6 überhaupt in Entwicklung?

Also ich hab davon bisher noch nichts gehört.

GDDR5 wird halt nochmals voll ausgequetscht mit nem 512 BIt Interface, und das wars dann auch.

Ich gehen eher von XDRAM oder Memory-Cube aus. Da hat man dann auch wirklich Entwicklungspotenzial, und gerade Memory-Cube kommt HSA EXTREM! entgegen.



.
soll ja 2014 kommen laut einer aktuellen Meldung... verträge datieren auch auf 2014 :)

[Ailuros]

Hm, kann man mit Maxwell ohne Shrink die Perf/mm2 nicht verbessern?

GF114 = 1.95Mrd Transistoren
GK104 = 3.54Mrd Transistoren
"GM104" = ???

Angenommen es steigern sich Transistoren zwar um weniger als 80%, sagen wir mal irgendwo =/>5.5Mrd bei welcher Packdichte genau willst Du das Ganze in 28nm genau reinquetschen? (stets frei erfundene Zahlen fuer Maxwell fuers Beispiel...)

Ich meine so ein Refresh kostet viel Geld und die Frage ist, ob der Aufwand in Verhältnis zum Nutzen steht. GT200 konnte man beim Refresh kleiner machen (65nm -> 55nm), Fermi musste man refreshen, weil v1 kaputt war. Aber bei Kepler hat man weder 20nm noch ist irgendwas kaputt. Lohnt sich das wirklich?

Und es ist billiger jeglichen bisherigen Entwlickungs-aufwand einzustampfen?


P.S.
Wofür steht das "T" in GT200(b)? Tesla? Beisst sich das nicht mit der Tesla-Serie?

Ja Tesla afaik. Es blieb halt bei HPC GPUs als Vorname stecken und man benutzt wohl den ersten Buchstaben vom Codenamen der Generation danach. Kepler ist Tesla K20 und Maxwell koennte Tesla M20 z.B. heissen.

[AnarchX]

GF114 = 1.95Mrd Transistoren
GK104 = 3.54Mrd Transistoren
"GM104" = ???

Angenommen es steigern sich Transistoren zwar um weniger als 80%, sagen wir mal irgendwo =/>5.5Mrd bei welcher Packdichte genau willst Du das Ganze in 28nm genau reinquetschen? (stets frei erfundene Zahlen fuer Maxwell fuers Beispiel...)

Warum sollten ein paar aufgepumpte SMX mit vielleicht 256SPs und mehr Cache nicht nur 10-20% mehr Transistoren kosten?

[boxleitnerb]

GF114 = 1.95Mrd Transistoren
GK104 = 3.54Mrd Transistoren
"GM104" = ???

Angenommen es steigern sich Transistoren zwar um weniger als 80%, sagen wir mal irgendwo =/>5.5Mrd bei welcher Packdichte genau willst Du das Ganze in 28nm genau reinquetschen? (stets frei erfundene Zahlen fuer Maxwell fuers Beispiel...)

Und es ist billiger jeglichen bisherigen Entwlickungs-aufwand einzustampfen?

Ja Tesla afaik. Es blieb halt bei HPC GPUs als Vorname stecken und man benutzt wohl den ersten Buchstaben vom Codenamen der Generation danach. Kepler ist Tesla K20 und Maxwell koennte Tesla M20 z.B. heissen.

Transistorcount != Performance. Jedenfalls nicht unbedingt. Was weiß ich, ob man nicht an Stellschraube A oder B drehen kann, ohne dass sich die Transistorzahl groß verändert, wo trotzdem 10-20% Performance rauskommt (oder weniger Verbrauch, so dass man höher takten kann bei gleicher Fläche)? Oder man ändert das Design so, dass man die Dinger noch geringer packen kann.

Bzgl. Entwicklungsaufwand:
Wenn es früh genug gemacht wird, vielleicht schon? Oder wenn ein Refresh gar nicht erst entwickelt wird? Ich hab keine Ahnung :)

[Ailuros]

Warum sollten ein paar aufgepumpte SMX mit vielleicht 256SPs und mehr Cache nicht nur 10-20% mehr Transistoren kosten?

Wieviel eingeschaetzte Zusatz-leistung soll Dir das Beispiel genau bringen? Sind wir schon so weit dass GPU 3D Leistung nur durch mehr GFLOPs und etwas mehr cache skalieren?

[Skysnake]

P.S.
Wofür steht das "T" in GT200(b)? Tesla? Beisst sich das nicht mit der Tesla-Serie?
Ja, das steht für Tesla

GT->Tesla
GF->Fermi
GK->Kepler
GM->Maxwell
GE->Einstein (?) weiß nicht, ob es einen Einstein gibt, aber der Name schwirrt bei nVidia auch rum ;)

Gibt dann auch noch ne Menge anderer
Lorenz und Dirak z.B.

.
soll ja 2014 kommen laut einer aktuellen Meldung... verträge datieren auch auf 2014 :)
Naja, schauen wir mal, was da dann genau kommen mag, und welche "Kinderkrankheiten" das ganze hat, oder auch nicht hat.

Zudem sollte man Memory-Cube und Hybrid-Memory-Cube NICHT durcheinander bringen ;)

Mehr werdet ihr dazu aber von mir nicht hören, also spart euch welche wie auch immer gearteten fragen :tongue:

[Ailuros]

Transistorcount != Performance. Jedenfalls nicht unbedingt. Was weiß ich, ob man nicht an Stellschraube A oder B drehen kann, ohne dass sich die Transistorzahl groß verändert, wo trotzdem 10-20% Performance rauskommt (oder weniger Verbrauch, so dass man höher takten kann bei gleicher Fläche)? Oder man ändert das Design so, dass man die Dinger noch geringer packen kann.

Dann geh mal geschichtlich zurueck von sagen wir mal G80 bis heute und mach eine Parallelisierung der Transistoren und Endleistung zwischen allen Generationen.

Man kann mit Packdichten auch nicht nur so herumschmeissen; wagen kann man es schon aber es gibt auch vorgeschlagene limits von der foundry monsieur.

Bzgl. Entwicklungsaufwand:
Wenn es früh genug gemacht wird, vielleicht schon? Oder wenn ein Refresh gar nicht erst entwickelt wird? Ich hab keine Ahnung :)

:tongue:

[AffenJack]

Es sieht ja gerade eher so aus, als wenn sich die 20nm Generation auf H2 2014 von beiden verschiebt. Wäre da der Ram nicht durchaus auch nen Grund das so zu machen, auch unabhängig davon wie der Prozess läuft. Gddr5 ist in 20nm nicht mehr ausreichend, gddr6 noch lange nicht verfügbar. Aber die memory cubes sollen anfang 2014 in Produktion gehen. Damit sollte nen Launch bei den Grafikkarten ende 2014 möglich sein. Wenn man schon lange damit geplant hat, dann ist das vielleicht viel mehr die Zeitbestimmende Komponente als der Prozess.

[Skysnake]

Wer will bitte noch GDDR5/6 wenn er nen Memory-Cube haben kann? :ugly:

Eventuell hohe Kosten mal außen vor.

[john carmack]

Wer will bitte noch GDDR5/6 wenn er nen Memory-Cube haben kann? :ugly:

Eventuell hohe Kosten mal außen vor.

:up:
wäre aber schön wenn es wie angekündigt klappt.

Produktionsstart 2013/2014 :)

[HPVD]

noch ein Gedanke zur Verzögerung ausgelöst durch Verfügbarkeit eines geeigneten Speichers:

kann statt warten auf eine neue Speichertechnologie,
nicht auch die "Nicht-Verfügbarkeit" einer geeigneten Speichermenge in geeigneter Form ein Grund sein?

GF110 und auch GK110 haben beide max 6GB DDR5.
Bedingt ist das ganze ja dadurch, dass lediglich 2gbit Module verfügbar sind und man für mehr Speicher doch m.W. entweder einen noch nicht im Design vorhandenen breiteren Bus bräuchte oder aber 4gbits DDR5 Module.
Letztere sind aber irgendwie nicht wirklich in Sicht.

Vielleicht macht ein Tesla Maxwell mit max 6GB einfach keinen Sinn oder nicht genug Sinn, da man ihn in der Praxis nicht schnell genug aus einem kleinen Speichern "füttern" kann und so die Geschwindigkeitsziele von GK110 X 3 DP nicht erreicht werden können
deshalb muss man:
=> den Bus doch noch verbreitern oder
=> auf 4gbit Module warten

beides kostet natürlich Zeit...

Wäre das möglich?

[Knuddelbearli]

wurde nicht vor kurzem erst GK110 Teslas mit 12Gb in Aussicht gestellt?

[Skysnake]

Die Speichermenge ist absolut ausreichend.

Zur Not macht man, was Intel ja auch macht, einfach ein 512 Bit Interface und hat seine 8 GB RAM. Das ist erstmal mehr als ausreichend...

Das Problem ist eher die Stagnation bei der Bandbreite, die mit der Steigerung der Rechenleistung eben nicht schritt hält und der extreme Aufwand, den man betreiben muss, um entsprechende Bandbreiten zu erhalten. Ein 512 Bit Interface ist kein Pappenstiel....

Für GPUs würde ich aber fast schon eher mir eDRAM mit 128/256/512 MB wünschen. Damit könnte man nochmal GDDRx eine zeitlang einsetzen. Für HSA wäre es halt ein bischen doof.

[HPVD]

wurde nicht vor kurzem erst GK110 Teslas mit 12Gb in Aussicht gestellt?

schon vor nem 3/4 Jahr wurden Varianten mit 12 und 24GB verkündet. Zusehen ist davon aber irgendwie gar nix.
und selbst wenn man nur nach 4gbit GDDR5 sample googelt findet man irgendwie nichts. Außer das Samsung aus dem GDDR5 Markt ausgeschieden ist...

[HPVD]

...
Zur Not macht man, was Intel ja auch macht, einfach ein 512 Bit Interface und hat seine 8 GB RAM.


genau, aber wenn man das anders geplant hatte weil man auf die Verfügbarkeit von 4gbit chips (vielleicht sogar bereits für K20) gesetzt hat, braucht man nun Zeit zum umdesignen und verspätet sich somit...

[Knuddelbearli]

schon vor nem 3/4 Jahr wurden Varianten mit 12 und 24GB verkündet. Zusehen ist davon aber irgendwie gar nix.
und selbst wenn man nur nach 4gbit GDDR5 sample googelt findet man irgendwie nichts. Außer das Samsung aus dem GDDR5 Markt ausgeschieden ist...

zusehen wirst du eh nicht viel kommen die werden nur auf anforderung produziert werden

[Skysnake]

Die 6 GB sind aber in praktisch allen Situationen, also selbst im HPC-Bereich wacker genug.

[HPVD]

zusehen wirst du eh nicht viel kommen die werden nur auf anforderung produziert werden
ne Pressemitteilung o.ä. dass diese neuen Chips nun an interessierte Verwender gesampelt werden gibts ja sonst eigentlich immer zu jedem sch...
ist ja auch für Aktionäre etc wichtig zu zeigen dass man neues tolles tut...

[HPVD]

Die 6 GB sind aber in praktisch allen Situationen, also selbst im HPC-Bereich wacker genug.
auch wenn ein Maxwell 3x so schnell ist und folglich ggf 3mal so schnell gefüttert werden muss?

[Skysnake]

Was hat Speichermenge mit Bandbreite zu tun?

[Knuddelbearli]

denke mal er meinte damit eher das PCI-E Interface

[HPVD]

Was hat Speichermenge mit Bandbreite zu tun?
mit Bandbreite GPU zu GPU-Speicher natürlich nichts,

aber (vereinfacht): Daten die von der CPU oder aus dem RAM kommen müssen auch zur GPU und da braucht man ggf etwas wie nen großen Buffer...
anders herum produziert eine sehr schnelle GPU-Berechnung auch sehr große Mengen Zwischenergebnisse die irgendwo gespeichert werden müssen bis sie entweder wieder gebraucht werden oder bis sie "abtransportiert" sind.
Kann ich die Daten nicht schnell genug zwischenspeichern/abrufen (dies geht nur direkt im GPU Speicher der Weg ins Ram dauert viel länger) ist die GPU quasi im Leerlauf und muss warten und kann damit keine Vorteile mehr gegenüber einer CPU Berechnung bringen.

Wenn man zum Beispiel mit Ansys rechnet entscheidet die GPU-Speichergröße darüber was überhaupt auf der GPU und was auf der CPU gerechnet wird: nämlich nur das was sich "lohnt"
=> zu groß für GPU Speicher: bleibt auf der CPU
=> klein: bleibt auf der CPU da die Datentransfer Dauer die Vorteile auffrisst
vgl. z.B. http://www.irisa.fr/orap/Forums/Forum30/Presentations/01-%20NVIDIA_30th_ORAP.pdf Folie 11

=> size does matter :-)

[AnarchX]

Wieviel eingeschaetzte Zusatz-leistung soll Dir das Beispiel genau bringen? Sind wir schon so weit dass GPU 3D Leistung nur durch mehr GFLOPs und etwas mehr cache skalieren?
Aber Veränderungen in dieser Richtung werden wohl hinter Maxwells Leistungssteigerung stehen.

Oder sollte man bei einem Performance-Maxwell @ 28nm deutlich über 400mm² erwarten? Da könnte man wohl schon eine mächtigere Lösung bauen: 3072SPs, 384-Bit @ ~450mm². Wohl durchaus etwas was man bei einem reifen 28nm Prozess im H2/2014 für <=$499 anbieten könnte.

Bleibt natürlich die Frage, was man von GK114/GK204 erwarten kann.

[Ailuros]

Aber Veränderungen in dieser Richtung werden wohl hinter Maxwells Leistungssteigerung stehen.

Oder sollte man bei einem Performance-Maxwell @ 28nm deutlich über 400mm² erwarten? Da könnte man wohl schon eine mächtigere Lösung bauen: 3072SPs, 384-Bit @ ~450mm². Wohl durchaus etwas was man bei einem reifen 28nm Prozess im H2/2014 für <=$499 anbieten könnte.

Angenommen sie gehen mit Maxwell performance auf 28nm, dann sehe ich keinen anderen Ausweg als ueber 400mm2 zu steigen, wenn sie davon auch zumindest eine Leistungsteigerung von 50% im Vergleich zum GK104 sehen wollen. Es ist immer noch besser =/>400mm2@28nm bei voller oder fast voller Prozessreife herzustellen, als sich mit dem wahrscheinlich unvorhersehbaren/ueberteuren 20nm herumzuquaelen am Anfang.

Bleibt natürlich die Frage, was man von GK114/GK204 erwarten kann.

Ich bezweifle dass in dem Ding mehr als ~15% Zusatzleistung zu GK104 steckt. Das Ding ist meine allerletzte Hoffnung dass wir 28nm GPUs noch bei anstaendigeren Preisen sehen werden :redface:

[Skysnake]

mit Bandbreite GPU zu GPU-Speicher natürlich nichts,

aber (vereinfacht): Daten die von der CPU oder aus dem RAM kommen müssen auch zur GPU und da braucht man ggf etwas wie nen großen Buffer...
anders herum produziert eine sehr schnelle GPU-Berechnung auch sehr große Mengen Zwischenergebnisse die irgendwo gespeichert werden müssen bis sie entweder wieder gebraucht werden oder bis sie "abtransportiert" sind.
Kann ich die Daten nicht schnell genug zwischenspeichern/abrufen (dies geht nur direkt im GPU Speicher der Weg ins Ram dauert viel länger) ist die GPU quasi im Leerlauf und muss warten und kann damit keine Vorteile mehr gegenüber einer CPU Berechnung bringen.

Wenn man zum Beispiel mit Ansys rechnet entscheidet die GPU-Speichergröße darüber was überhaupt auf der GPU und was auf der CPU gerechnet wird: nämlich nur das was sich "lohnt"
=> zu groß für GPU Speicher: bleibt auf der CPU
=> klein: bleibt auf der CPU da die Datentransfer Dauer die Vorteile auffrisst
vgl. z.B. http://www.irisa.fr/orap/Forums/Forum30/Presentations/01-%20NVIDIA_30th_ORAP.pdf Folie 11

=> size does matter :-)
In Games hast du aber einen fixen Wert, und das ist dann scheis egal, ob du 10 oder 10.000 FPS hast, weil du einfach die Buffer immerwieder überschreibst, die du benötigst.

Und im GPGPU-Bereich, muss man erstmal Probleme haben, die die größe haben...

Für den Heimanwender völlig illusorisch, und für HPC kann man noch immer mit streaming arbeiten. Man braucht so oder so ~40-60 Datenzugriffe pro Datensatz, damit man die GPU gut ausgelastet bekommt. Also von daher kann man da mit Streaming bei 6 GB schon einiges reisen.

Mehr ist natürlich immer toll, aber man darf die Kosten nicht aus den Augen verlieren, und daher macht das aktuell einfach keinen Sinn mehr als maximal 8 GB zu verbauen.

Angenommen sie gehen mit Maxwell performance auf 28nm, dann sehe ich keinen anderen Ausweg als ueber 400mm2 zu steigen, wenn sie davon auch zumindest eine Leistungsteigerung von 50% im Vergleich zum GK104 sehen wollen. Es ist immer noch besser =/>400mm2@28nm bei voller oder fast voller Prozessreife herzustellen, als sich mit dem wahrscheinlich unvorhersehbaren/ueberteuren 20nm herumzuquaelen am Anfang.

Dem kann ich mich anschließen.

Ich erwarte allerdings ziemlich sicher zumindest die ersten Maxwell-Chips auf 28nm. Mich würde es wundern, wenn nicht. Man sollte aus 40, 32 und 28nm gelernt haben.

Lieber ein Produkt sicher bringen, als die ganze Zeit bangen müssen, wann man denn endlich was fertigen lassen kann...


Ich bezweifle dass in dem Ding mehr als ~15% Zusatzleistung zu GK104 steckt. Das Ding ist meine allerletzte Hoffnung dass wir 28nm GPUs noch bei anstaendigeren Preisen sehen werden :redface:
Wenns überhaupt so viel wird... Man setzt damit nur GK110 unter druck, und macht sich das Leben für einen Maxwell auf 28nm unnötig schwer...

Ich gehe eher davon aus, das es im großen und Ganzen einfach ein Taktupdate wird.

[Ailuros]

Wenns überhaupt so viel wird... Man setzt damit nur GK110 unter druck, und macht sich das Leben für einen Maxwell auf 28nm unnötig schwer...

Ich gehe eher davon aus, das es im großen und Ganzen einfach ein Taktupdate wird.

Wuerde aber ebenso fuer AMD's naechste echte GPU Generation gelten und ich wuerde nicht vorschlagen dass sich AMD so leicht aufs 20nm Glatteis wagen koennte wenn der Prozess wirklich so miserabel ist wie es heissen soll.

Was jetzt GK110 betrifft, wenn "GK204" erst im Herbst kommt gibt es genug Blut abzusaugen bis dann mit dem heutigen Titan und sie koennen stets alle SMXs einschalten und nochmal 10% Takt mit einem spin draufstecken. So erhalten sie problemlos das heutige status quo und koennen weiterhin froehlich absurde MSRPs verlangen...and they lived happily ever after :D

[Skysnake]

Du darfst aber mit GK110 auch nicht zu stark werden! Sonst sieht Maxwell scheise aus...

Das ist doch das was ich schon lange sage... nVidia hat mit Kepler einen Bummerang geworfen, bei dem sich jetzt entscheidet, ob er zurück kommt und ihnen in die Fresse fliegt, oder vorher abstürzt, und Sie nochmal davon gekommen sind. Gedreht hat der Bummerang auf jeden Fall schonmal.

@20nm:
Ich hoffe doch, das AMD aus Cayman gelernt hat...

Ich denke/hoffe, dass Sie den Chip auf 28nm auslegen, und zur Not dann auf 20nm "einfach" shrinken, ohne große Optimierung.

AMD (also der ATI teil) ist ganz gut was tools und neue Prozesse anbelangt. Ich traue denen durchaus zu, das relativ schnell über die Bühne zu bekommen. Halt ohne große Optimierung, wodurch man keinen großen Vorteil haben würde bzgl der Konkurrenz. 5-10% können aber schon entscheidend sein über Top und Flop.

Zudem halt der psychologische Faktor beim Kunden auch ne Rolle spielt.

Kurz um, realistisch beide nochmal 28nm mit den neuen Generationen, und mit viel Hoffen bei AMD ein "kurzfristiger Schwenk" auf 20nm,

[HPVD]

In Games hast du aber einen fixen Wert, und das ist dann scheis egal, ob du 10 oder 10.000 FPS hast, weil du einfach die Buffer immerwieder überschreibst, die du benötigst.

Und im GPGPU-Bereich, muss man erstmal Probleme haben, die die größe haben...

Für den Heimanwender völlig illusorisch, und für HPC kann man noch immer mit streaming arbeiten. Man braucht so oder so ~40-60 Datenzugriffe pro Datensatz, damit man die GPU gut ausgelastet bekommt. Also von daher kann man da mit Streaming bei 6 GB schon einiges reisen.

Mehr ist natürlich immer toll, aber man darf die Kosten nicht aus den Augen verlieren, und daher macht das aktuell einfach keinen Sinn mehr als maximal 8 GB zu verbauen.



für die Consumer-Seite & alles mit Grafik hast Du schon Recht. Da braucht man nicht mehr. Für HPC GPGPU aber mit Sicherheit:
Die GPUs sollen ja die Arbeit von CPUs übernehmen und noch besser machen.
Selbst "kleine" Berechnungsworkstations haben heute für Ihre 2 CPUs 64GB RAM, mittlere 128-256GB und die großen auch gerne noch mehr z.B. 24x16GB = 384GB RAM für aktuell 2400€...
und das RAM kriegt man immer voll: warum sollte dann bei GPUs 8GB dicke reichen?
ok man braucht nicht die gleichen Mengen weil man als Fallback immer noch das RAM hat und nicht ne lahme Festplatte/SSD - aber auch das RAM ist nur per PCIe zu erreichen...

[Hübie]

Weil man effizienter streamen und stärker komprimieren kann? Ausserdem ist GDDR5-RAM immer noch weitaus teurer als DDR3-RAM. Vergiss auch nicht Fehlerkorrektur und Paritätsprüfung.

[ndrs]

@ Ram-Diskussion
Warum können nicht einfach mehr Speicherchips an einen Kanal gehängt werden? Wenn ein oder zwei geht, warum nicht drei oder vier? Das ginge ohne das Interface im Chip anzufassen. Oder gibt es einen Grund der dagegen spricht (vom brauchen oder nicht brauchen mal abgesehen)?

[Skysnake]

für die Consumer-Seite & alles mit Grafik hast Du schon Recht. Da braucht man nicht mehr. Für HPC GPGPU aber mit Sicherheit:
Die GPUs sollen ja die Arbeit von CPUs übernehmen und noch besser machen.
Selbst "kleine" Berechnungsworkstations haben heute für Ihre 2 CPUs 64GB RAM, mittlere 128-256GB und die großen auch gerne noch mehr z.B. 24x16GB = 384GB RAM für aktuell 2400€...
und das RAM kriegt man immer voll: warum sollte dann bei GPUs 8GB dicke reichen?
ok man braucht nicht die gleichen Mengen weil man als Fallback immer noch das RAM hat und nicht ne lahme Festplatte/SSD - aber auch das RAM ist nur per PCIe zu erreichen...
Na, du kennst doch schon die Lösung ;)

Man braucht bei der CPU den richtig fetten RAM, weil man ansonsten bei den Clustern eben auf die extrem langsame Festplatte, oder was sogar noch wahrscheinlicher, da garkeine Festplatte verbaut, übers Netzwerk gehen muss, und das willst du ganz sicher nicht...

Da sind die 8/16 GB über den PCI-E Slot ein reiner Segen! Denk dran. Übers Netz kommste nicht mehr als ~40 GBit/s also 5 GB/s. Dafür müssen deine I/O Nodes aber erstmal mitspielen, und das werden Sie NIE.

Zudem hast du eben auf GPUs immer Probleme, wo du "sehr oft" immer wieder die gleichen Daten anfasst. Ansonsten bekommst du aus der GPU gar keine Leistung raus. Daher kommst du auch ganz gut mit dem Streamen hinterher ;)

Natürlich wäre es GÖTTLICH wenn man z.B. 512 GB RAM für die GPU hätte, aber das könnteste einfach nicht bezahlen.

Da nimmt man die Ist-Situation halt als gegeben hin, und fängt eben mit so Tricks wie Streaming an.

@ndrs:
Du musst auch die Chips dazu befähigen.

Keine Ahnung, wie breit die Adressierung ist, aber es kann gut sein, das man nur mit einer begrenzten Adressierung wie 33 Bits arbeitet. Keine Ahnung, wie das geregelt ist bei den GPUs. 33 Bit braucht man aber akuell mindestens, da man mit 32 nut 4 GB addressiert bekommt. Ich glaube aber eher nicht, das man direkt auf 40 Bit wie bei CPUs gegangen ist. Ich kann und will es aber nicht ausschließen.

[HPVD]

ok ich geb' mich in dieser Diskussion erstmal geschlagen :-)

hatte ja gar nichts dagegen das die aktuellen Karten "nur" 6GB haben. Der Aufhänger war ob das auch bei ner in DP 3 mal so schnellen Maxwell Berechnungs GPU noch reicht/sinnvoll ist oder ob man da nicht 12 oder 24GB sinnvoller Weise anstreben müsste.

Mein "gefühlter" Vergleich ist einfach dass die Workstations früherer Generationen auch mit weniger RAM gut ausgelastet werden konnten aber man bei den aktuellen schnelleren CPUs schnell auch mehr RAM brauchen kann...

[Skysnake]

Das liegt aber eher an der Art der Probleme.

Vor allem Probleme mit vielen Branches usw profitieren davon, also dass du keine/kaum Vorhersagen zum Programmablauf machen kannst.

Sowas passt aber eh nicht gut auf GPUs ;)

[Ailuros]

Du darfst aber mit GK110 auch nicht zu stark werden! Sonst sieht Maxwell scheise aus...

Bei einem gesunden Zeitabstand ist es scheissegal da GK110 ein high end chip ist und Maxwell/28nm als performance chip eine ganz andere Kategorie sein wird. GK104 war auch "nur" ca. 30% schneller als GF110 beim launch obwohl beide den gleichen MSRP hatten.

Das ist doch das was ich schon lange sage... nVidia hat mit Kepler einen Bummerang geworfen, bei dem sich jetzt entscheidet, ob er zurück kommt und ihnen in die Fresse fliegt, oder vorher abstürzt, und Sie nochmal davon gekommen sind. Gedreht hat der Bummerang auf jeden Fall schonmal.

Die Strategie ist bis jetzt ausgezeichnet fuer NV's Umsatz, aber eben ziemlich beschissen fuer den Verbraucher.

@20nm:
Ich hoffe doch, das AMD aus Cayman gelernt hat...

Ich denke/hoffe, dass Sie den Chip auf 28nm auslegen, und zur Not dann auf 20nm "einfach" shrinken, ohne große Optimierung.

Der Punkt war dass Curacao mit der naechsten Generation wieder theoretisch auf 28nm aehnliche Prozess-bedingte Limitierungen haben wird wie auch NV mit Maxwell performance 28nm.


Kurz um, realistisch beide nochmal 28nm mit den neuen Generationen, und mit viel Hoffen bei AMD ein "kurzfristiger Schwenk" auf 20nm,

Und wer sagt dass NV es schwer haben wird mit hypothetischen shrinks fuer 20HP spaeter?

[Skysnake]

AMD ist da in meinen Augen etwas flexibler. nVidia neigt ja eher dazu neue Prozesse später an zu gehen.

Ich seh da AMD einfach als flexibler an, gerade auch weil nVidia sich bei Tegra ran halten muss. Ich seh eher Tegra als ersten 20nm chip bei nVidia denn irgend ne GPU.

Ich lass mich aber GERN vom Gegenteil überraschen :D

[Ailuros]

AMD ist da in meinen Augen etwas flexibler. nVidia neigt ja eher dazu neue Prozesse später an zu gehen.

Seit Kepler hat sich aber auch einiges geaendert. Die paar Monate Unterschied zwischen Tahiti und GK104 waren nicht der Rede wert und es ist eben auch kinderleicht so etwas von einer ziemlich sicheren Ecke zu behaupten wenn man als IHV keinen hochkomplizierten chip mehr entwickelt. Dass GK110 exakt nach Plan seinen tape out hatte und A1 silicon nach genau 6 Monaten danach vom Laufband kam ist nicht gerade wenig.

Ich seh da AMD einfach als flexibler an, gerade auch weil nVidia sich bei Tegra ran halten muss. Ich seh eher Tegra als ersten 20nm chip bei nVidia denn irgend ne GPU.

Qualcomm ist unter den wenigen SoC Herstellern die besondere Verspaetungen mit ihren Projektionen sehen; wann gab es von denen die ersten 28LP/TSMC SoCs und warum nicht frueher? Rein zufaellig fast zeitgleich zu Tahiti und GK104?

Sonst was haben low power Prozess Varianten genau mit HP Prozessen bei TSMC gemeinsam?

[Skysnake]

Das du nur jeden Engineer einmal einsetzen kannst ;)

Ansonsten natürlich nichts. Man hat aber eben keine unendliche Personaldecke, und bei Tegra muss auf die Tube gedrückt werden.

Ja, das stimmt mit den kleinen Chips bei den GPUs. Da könnte/hat sich bei nVidia wirklich einiges ändern/geändert....

Schaumer einfach mal.

Ich bezweifle aber, dass sich alle wie wild auf den 20nm Prozess stürzen werden.

[Ailuros]

Das du nur jeden Engineer einmal einsetzen kannst ;)

Du willst mir doch im Gegensatz nicht einreden dass bei AMD die exakt gleichen engineers fuer deren SoC und GPU chip tape outs verantwortlich sind oder?

Ansonsten natürlich nichts. Man hat aber eben keine unendliche Personaldecke, und bei Tegra muss auf die Tube gedrückt werden.

Was die GPU Bloecke in Tegras betrifft wohl schon; sonst hat generell NV hier und da ein paar Verspaetungen mit SoCs aber nie ueber ein Quartal im schlimmsten Fall. Im Angesicht dass ihre Erfahrung mit SoCs nicht so gross ist wie bei anderen kann man locker ein Auge zudruecken. Und es ist eben nicht so dass bei AMD SoCs (die auch zugegeben groesser sind) immer alles nach Plan laeuft. Es stottert leicht hier und da mal sogar bei Intel obwohl sie ihre eigene Herstellung haben.

Ich bezweifle aber, dass sich alle wie wild auf den 20nm Prozess stürzen werden.

Uhmm ich behaupte die ganze Zeit genau das Gegenteil und das sowohl fuer NVIDIA als auch fuer AMD. Es ist auch nicht so dass ATI nicht ihre eigenen bitteren Erfahrungen mit zweifelhaften Prozessen hatte. Neben den paar fraglichen Design-Entscheidungen fuer R600 war ein sehr fetter Batzen von seinen relativen Problemen auch mit TSMC's 80nm verbunden, welches NV nie beruehrt hat aus gutem Grund.

[Konami]

Also, wie schauts aus: 20nm-Performance-Maxwell im Zeitfenster H2 14 / H1 15, oder noch ein Jahr später? Möglich wäre ja durchaus ein Wurst-Käs-Szenario, sodass erstmal Kepler-Refresh kommt, dann ein Jahr später Maxwell Performance @ 28nm und nochmal ein Jahr später erst der Refresh in 20nm (also 2015/16).

Aber daran will ich nicht so recht glauben. Hat jemand zufällig eine Glaskugel parat? :)

[boxleitnerb]

@Ailuros:

Ich hab bitte nochmal ne Frage zur Potential einer neuen Architektur. Du sagst, Performance ist recht eng an die Transistorenzahl gekoppelt und Packdichte kann nicht beliebig erhöht werden im selben Prozess. Was genau bringt ein Maxwell@28nm dann überhaupt? Warum sollte man sich die Mühe machen, wenn man sich ohne neuen Prozess nicht wirklich ggü. Kepler verbessern kann bei gleichen Randbedingungen (TDP, Die Size)?

[Ailuros]

@Ailuros:

Ich hab bitte nochmal ne Frage zur Potential einer neuen Architektur. Du sagst, Performance ist recht eng an die Transistorenzahl gekoppelt und Packdichte kann nicht beliebig erhöht werden im selben Prozess. Was genau bringt ein Maxwell@28nm dann überhaupt? Warum sollte man sich die Mühe machen, wenn man sich ohne neuen Prozess nicht wirklich ggü. Kepler verbessern kann bei gleichen Randbedingungen (TDP, Die Size)?

Was genau brachte G80 im Vergleich zu G71 unter dem gleichen 90nm Prozess? Offensichtlich korrigiert bei einem theoretischen Maxwell performance chip ein direkter 20nm shrink spaeter sowohl weniger die area als auch weniger TDP oder gleichen TDP bei mehr Leistung. Wenn die Leistung stimmen sollte und der Stromverbrauch sagen wir mal nicht ueber 200-210W steigt, interessiert es Dich als Endverbraucher ob der die sogar 450mm2 gross ist oder willst Du lieber noch ca. ein Jahr dazuwarten und noch einen +10% GK204 Kepler performance refresh erleben?

Wuerdest Du mich ueber den high end chip fragen koennte ich die Frage noch verstehen; da es sich aber um maximal performance chips handeln soll bei den bisherigen Thesen und Du einen Ausgangspunkt von 294mm2/3.54b/28nm hast wundert es mich schon was so schwer daran zu verstehen sein soll. Ich bin mit den bisherigen Thesen auch nicht auf eine =/>100% Transistoren-Erhoehung gegangen um es so konservativ wie moeglich zu halten.

Sonst was machte wohl NV genau ab NV40 bis zu GF100 als sie selbst fuer high end chips immer noch den vorigen Prozess benutzten. Natuerlich war es dann auch so dass high end chips bis zu GT200 auch nicht ueber 500mm2 ragten. Ab GT200/65nm waren sie schon an der kritischen Grenze.

[boxleitnerb]

Selbst wenn du Transistorzahl und Die Size nur mäßig steigerst (sagen wir mal +40%), was genau hat das mit Maxwell zu tun? Könnte man nicht dasselbe auch mit Kepler erreichen? Darum geht es mir.

Und wie kommst du darauf, dass der Verbrauch so niedrig bleibt, wenn man sagen wir mal +35% auf GK204 drauflegen wollte? Kann Nvidia zaubern? Mit einem noch reiferen Prozess, einem breiteren Chip und etwas niedrigeren Taktraten/Spannungen wäre das vielleicht erreichbar. Aber das hätte immer noch nichts mit Maxwell zu tun, oder täusche ich mich da?

Meine Frage ist eben, wie weit man die Leistung steigern kann, wenn alle Parameter wie Verbrauch und Die Size in etwa konstant bleiben. Nur durch die Architektur an sich.

Aus der CPU-Welt würde mir da P4 vs C2D einfallen. Beides 65nm, Conroe war kleiner, sparsamer und schneller.

[Ailuros]

Selbst wenn du Transistorzahl und Die Size nur mäßig steigerst (sagen wir mal +40%), was genau hat das mit Maxwell zu tun? Könnte man nicht dasselbe auch mit Kepler erreichen? Darum geht es mir.

Wenn sie bei 20nm bleiben koennten waere es wenn ich mich richtig erinnere irgendwo =/>80% gewesen. 50% wuerde ich schon erwarten. Wie weit willst Du das GK104 Geruest denn wirklich aufpumpen? Titan hat es heute schon schwer mit 14SMXs um einen wirklichen glatten +50% Unterschied zu erreichen.

Und wie kommst du darauf, dass der Verbrauch so niedrig bleibt, wenn man sagen wir mal +35% auf GK204 drauflegen wollte? Kann Nvidia zaubern?

Erstens wehe wenn jegliche neue Architektur nicht effizienter ist als die vorige und GK110 verbraucht bei 551mm2/7.1/6GB auch "nur" 250W. Nennst Du das auch "zaubern" oder nur eine stinknormale Weiterentwicklung der Technologie?

Mit einem noch reiferen Prozess, einem breiteren Chip und etwas niedrigeren Taktraten/Spannungen wäre das vielleicht erreichbar. Aber das hätte immer noch nichts mit Maxwell zu tun, oder täusche ich mich da?

NV hat GF110 auf 28nm geshrumpft um mit 28nm zu experimentieren. Frag sie doch mal wie das Resultat im Bereich Leistung und Stromverbrauch genau ausgesehen hat.

Meine Frage ist eben, wie weit man die Leistung steigern kann, wenn alle Parameter wie Verbrauch und Die Size in etwa konstant bleiben. Nur durch die Architektur an sich.

Kann ich doch nicht schon jetzt wissen. Traditionell ist es immer so dass sich die beiden IHV einander bewaehrte Methoden kopieren und aehnliches selber in ihre Architekturen integrieren. Ich weiss wirklich nicht was Maxwell anstellen koennte, aber wenn ich auf GCN rueberschiel gibt es noch genug low hanging fruit fuer NVIDIA und natuerlich auch anders rum.

Aus der CPU-Welt würde mir da P4 vs C2D einfallen. Beides 65nm, Conroe war kleiner, sparsamer und schneller.

Intel wird nach allen Indizien tick tock aufgeben.

[boxleitnerb]

Wenn sie bei 20nm bleiben koennten waere es wenn ich mich richtig erinnere irgendwo =/>80% gewesen. 50% wuerde ich schon erwarten. Wie weit willst Du das GK104 Geruest denn wirklich aufpumpen? Titan hat es heute schon schwer mit 14SMXs um einen wirklichen glatten +50% Unterschied zu erreichen.


Tut mir leid, aber ich verstehe nicht, wie +50% so besonders sind, wenn man den Chip auch gleichzeitig größer macht und die Transistorenzahl deutlich erhöht.
Titan schafft seine 50% beinahe schon, wenn ihm die eingebaute Temperatur- bzw. Taktdrossel nicht reinpfuscht.


Erstens wehe wenn jegliche neue Architektur nicht effizienter ist als die vorige und GK110 verbraucht bei 551mm2/7.1/6GB auch "nur" 250W. Nennst Du das auch "zaubern" oder nur eine stinknormale Weiterentwicklung der Technologie?


Das ist ja der Kernpunkt meiner Frage. Wieviel Flächen- und Energieeffizienz kommt von der Architektur an sich und wieviel vom Shrink?
Und ich nenne es nicht zaubern, ich nenne es
a) reiferer Prozess
b) breiterer Chip, niedriger Takt
Beides sollte die Effizienz naturgemäß verbessern.


NV hat GF110 auf 28nm geshrumpft um mit 28nm zu experimentieren. Frag sie doch mal wie das Resultat im Bereich Leistung und Stromverbrauch genau ausgesehen hat.

Scheinbar nicht sonderlich gut, wenn du es schon so formulierst ;)
Btw, da stimmt doch was nicht! Wenn NV nicht zufrieden war mit GF110@28nm, wie sollen sie dann zufrieden sein mit der Umstellung von Maxwell von 28nm auf 20nm? Ist das nicht genau dasselbe wie dein Beispiel?

[Duplex]

Laut LZ soll Maxwell 90% schneller als GK104 beim selben Verbrauch sein
http://www.hardwareluxx.de/community/f14/xxl-test-nvidia-geforce-gtx-titan-im-3-way-sli-942899-21.html#post20235394

[boxleitnerb]

LZ, im Ernst jetzt? Seit wann ist der eine legitime Quelle? :freak:
Außerdem ging es da auch um die Variante mit Shrink.

[Ailuros]

Tut mir leid, aber ich verstehe nicht, wie +50% so besonders sind, wenn man den Chip auch gleichzeitig größer macht und die Transistorenzahl deutlich erhöht.
Titan schafft seine 50% beinahe schon, wenn ihm die eingebaute Temperatur- bzw. Taktdrossel nicht reinpfuscht.

Nur wiegt GK110 ganze 551mm2. Waere der PUnkt einer neuen Architektur nicht effizienter zu sein? Der clue halt oder besser die Herausforderung wird eben darin liegen aus um einiges weniger Transistoren vergleichbare Leistung kitzeln zu koennen.

Das ist ja der Kernpunkt meiner Frage. Wieviel Flächen- und Energieeffizienz kommt von der Architektur an sich und wieviel vom Shrink?
Und ich nenne es nicht zaubern, ich nenne es
a) reiferer Prozess
b) breiterer Chip, niedriger Takt
Beides sollte die Effizienz naturgemäß verbessern.

Der Unterschied zu einem shrink duerfte schaetzungsweise nicht brutal gross sein, aber IHVs wuerden heutzutage selbst fuer den letzten Flecken an perf/W jemand umbringen.

Von dem abgesehen wie oft noch dass ich Dir Deine Fragen noch nicht beantworten kann? GPUs gehen traditionell in die Breite und Frequenz steigt nur marginal. Zwischen G80 und GF110 stieg die core-Frequenz nur von 575 auf 772MHz.

Scheinbar nicht sonderlich gut, wenn du es schon so formulierst ;)

Ganz im Gegenteil; der Unterschied in perf/W war schon sehenswert.

Btw, da stimmt doch was nicht! Wenn NV nicht zufrieden war mit GF110@28nm, wie sollen sie dann zufrieden sein mit der Umstellung von Maxwell von 28nm auf 20nm? Ist das nicht genau dasselbe wie dein Beispiel?

GF110@28nm war NIE als Produkt geplant; um fuer 28nm Erfahrung zu sammeln haben sie den chip einfach zu einem shrink geschickt. Bei einem direkten shrink kann es sein dass Du von 40G auf 28HP sagen wir mal 40% eingeschaetzt sparst aber wohl eben NICHT 40% TDP! Welche GK104 SKU erreicht so in etwa GTX580 3D Leistung? Wie sieht es mit dem TDP bei diesem aus?

Und nein es hat mit meinem Beispiel nichts direkt zu tun wenn Maxwell auf der richtigen Schiene entwickelt wurde. Ergo wenn sie es schaffen sollten ca. 50% unter 28nm aus einem Maxwell Performance core zu kitzeln (im Vergleich zu Kepler performance) und der TDP ist noch immer innerhalb der ~210W TDP Grenze dann wird es mit einem 20nm shrink zwar besser aber wohl nicht 150W z.B.

Der Haken der Geschichte ist dass ich nicht die blasseste Ahnung habe was Maxwell haben koennte. Das ganze Gefusel mit den moeglichen Denver cores ist noch ein weiteres Raetsel. Erreicht aber NV ihr Ziel fuer den Maxwell top dog dann muss ein 20HP Tesla Maxwell etwas unter 12 TFLOPs SP unter weniger als 240W TDP erreichen sonst ist ihre gesamte Projektion im Arsch.

Laut LZ soll Maxwell 90% schneller als GK104 beim selben Verbrauch sein
http://www.hardwareluxx.de/community/f14/xxl-test-nvidia-geforce-gtx-titan-im-3-way-sli-942899-21.html#post20235394

Unter 20HP im Idealfall schon; und damit ist die Diskussion bei weitem nicht beendet :biggrin:

[boxleitnerb]

Nur wiegt GK110 ganze 551mm2. Waere der PUnkt einer neuen Architektur nicht effizienter zu sein? Der clue halt oder besser die Herausforderung wird eben darin liegen aus um einiges weniger Transistoren vergleichbare Leistung kitzeln zu koennen.


Darf ich zitieren?
Ich:
Transistorcount != Performance. Jedenfalls nicht unbedingt. Was weiß ich, ob man nicht an Stellschraube A oder B drehen kann, ohne dass sich die Transistorzahl groß verändert, wo trotzdem 10-20% Performance rauskommt (oder weniger Verbrauch, so dass man höher takten kann bei gleicher Fläche)?

Du:
Dann geh mal geschichtlich zurueck von sagen wir mal G80 bis heute und mach eine Parallelisierung der Transistoren und Endleistung zwischen allen Generationen.


Ja was denn nu? Erst widersprichst du mir und jetzt sagst du was in die gleiche Richtung.
Wenn schon du als Experte unsicher bist, wie soll es dann erst mir gehen? :wink:

[HPVD]

... Erreicht aber NV ihr Ziel fuer den Maxwell top dog dann muss ein 20HP Tesla Maxwell etwas unter 12 TFLOPs SP unter weniger als 240W TDP erreichen sonst ist ihre gesamte Projektion im Arsch.

jein - bisher gibt es doch m.W. nur Aussagen zur DP Effizienz-Steigerung um Faktor 3-4, oder hab ich was verpasst?
vielleicht drehen sie ja auch beim top-dog am SP/DP verhältnis...

[Ailuros]

Darf ich zitieren?

Ja Du darfst. Nur meinte ich fuer meine Maxwell performance 28nm These eben NIE 7.1Mrd. Transistoren welches 2x Mal GK104 Transistoren sind.

Ja was denn nu? Erst widersprichst du mir und jetzt sagst du was in die gleiche Richtung.
Wenn schon du als Experte unsicher bist, wie soll es dann erst mir gehen? :wink:

Siehe oben.

[boxleitnerb]

Wo wir wieder bei der Frage wären, ob man GK104 nicht weiter aufblasen kann, um dasselbe zu erreichen. Allein das Weglassen der DP-Einheiten, von HyperQ und DynamicParallelism dürfte einiges sparen an Fläche im Vergleich zu GK110. Ob der Unterschied dann noch nennenswert ist?

Aber gut, du hast schon Recht - wenn es bislang noch keine konkreten Informationen gibt, ist das Spekulieren müßig. Ich hab keine Ahnung von GPU-Design, aber ich hätte halt gerne ein konkretes Architekturbeispiel gewusst, wo man eben ansetzen könnte bei Maxwell@28nm. Cache, Scheduling, sowas. Halt etwas, wo Kepler Verbesserungspotential hat. Nichts ist perfekt, es geht immer besser. Nur kann ich mir eben mangels Wissen nicht vorstellen, wie.

[Ailuros]

jein - bisher gibt es doch m.W. nur Aussagen zur DP Effizienz-Steigerung um Faktor 3-4, oder hab ich was verpasst?
vielleicht drehen sie ja auch beim top-dog am SP/DP verhältnis...

Vielleicht oder es bleibt vielleicht doch bei einem 1:3 Verhaeltnis.

http://www.nvidia.com/content/GTC/documents/SC09_Dally.pdf

Exascale war nur eine hypothetische Uebung fuer das was wir bis jetzt als "Einstein" verstehen. Angenommen es sind grobe Grundlagen fuer Einstein wobei natuerlich bei so viel Zeit zich Aenderungen vorkommen koennen, aber was genau verstehst Du unter 40 TFLOPs SP 13 TFLOPs DP?

Uebrigens boxleiternerb,

Falls Du es noch nicht gelesen haben solltest, ist es schon eine interessante Lektuere, ab Fermi natuerlich auf theoretischer Basis.

Wo wir wieder bei der Frage wären, ob man GK104 nicht weiter aufblasen kann, um dasselbe zu erreichen. Allein das Weglassen der DP-Einheiten, von HyperQ und DynamicParallelism dürfte einiges sparen an Fläche im Vergleich zu GK110. Ob der Unterschied dann noch nennenswert ist?

GK104 hat zwar wenige aber immer noch DP Einheiten. 960 DP GK110 - 64 DP GK104 = ergo sparst Du erstmal 896 DP.

Wie wir mal im Kepler besprochen haben, nach oeffentlicher Dokumentation 1 FP64 Einheit = 0.025mm2 unter 28HP 1GHz aber nur fuer synthesis. Waere 0.035 grosszuegig genug fuer die Milchmaedchenrechnung pro Einheit?

Wenn ja dann = 896 * 0.035mm2 = 31,36mm2 ergo sind wir hier wohl immer noch bei ~520mm2. Fuer HyperQ, dynamic parallelism keine Ahnung aber unter 480mm2 kann ich es mir schwer vorstellen.


Aber gut, du hast schon Recht - wenn es bislang noch keine konkreten Informationen gibt, ist das Spekulieren müßig. Ich hab keine Ahnung von GPU-Design, aber ich hätte halt gerne ein konkretes Architekturbeispiel gewusst, wo man eben ansetzen könnte bei Maxwell@28nm. Cache, Scheduling, sowas. Halt etwas, wo Kepler Verbesserungspotential hat. Nichts ist perfekt, es geht immer besser. Nur kann ich mir eben mangels Wissen nicht vorstellen, wie.

Die multi-level chache bzw. register cache Patente sind ziemlich interesssant, falls sie wirklich fuer Maxwell gelten sollten. Es gab damals ja eine ganze Debatte hier darueber aber ich kann mich nicht mehr erinnern in welchem sub-forum.

[HPVD]

Vielleicht oder es bleibt vielleicht doch bei einem 1:3 Verhaeltnis.

http://www.nvidia.com/content/GTC/documents/SC09_Dally.pdf

Exascale war nur eine hypothetische Uebung fuer das was wir bis jetzt als "Einstein" verstehen. Angenommen es sind grobe Grundlagen fuer Einstein wobei natuerlich bei so viel Zeit zich Aenderungen vorkommen koennen, aber was genau verstehst Du unter 40 TFLOPs SP 13 TFLOPs DP?
.

aus dem pdf (läd gerade sehr langsam):

An NVIDIA ExaScale Machine in 2017
2017 GPU Node
–300W (GPU + memory + supply)
2,400 throughput cores (7,200 FPUs), 16 CPUs
–single chip40TFLOPS (SP) 13TFLOPS (DP)
Deep, explicit on-chip storage hierarchy
Fast communication and synchronizationNode


kühne Progose damals in 2009...
Man darf gespannt sein :smile:

[Ailuros]

aus dem pdf (läd gerade sehr langsam):

An NVIDIA ExaScale Machine in 2017
2017 GPU Node
–300W (GPU + memory + supply)
2,400 throughput cores (7,200 FPUs), 16 CPUs
–single chip40TFLOPS (SP) 13TFLOPS (DP)
Deep, explicit on-chip storage hierarchy
Fast communication and synchronizationNode

kühne Progose damals in 2009...
Man darf gespannt sein :smile:

Steht aber darunter dass es nur eine Prognose ist auf Moore's Law basierend. Dally duerfte einen begrenzten Einfluss auf Kepler schon geschafft haben IMHO.

[boxleitnerb]

Das mit der Datenlokalität ist schon sehr interessant, aber ein Problem löst es nicht - man muss immer noch auf Texturen zugreifen, und die passen nicht in Caches, sondern müssen immer aus externen Speichern geholt werden. Kannst du abschätzen, was tendenziell der größte Bandbreitenfresser ist? Texturzugriff, MSAA oder was anderes? Um Ersteres wird man wohl nie herumkommen, die Datenmengen steigen ja auch stetig.

[HPVD]

Steht aber darunter dass es nur eine Prognose ist auf Moore's Law basierend. Dally duerfte einen begrenzten Einfluss auf Kepler schon geschafft haben IMHO.

jo, vorab implizieren sie aber irgendwie dass CPUs das Moore's Law nicht schaffen aber GPUs schon - obwohl sie extra sagen das ist keine Roadmap...

[Ailuros]

Das mit der Datenlokalität ist schon sehr interessant, aber ein Problem löst es nicht - man muss immer noch auf Texturen zugreifen, und die passen nicht in Caches, sondern müssen immer aus externen Speichern geholt werden. Kannst du abschätzen, was tendenziell der größte Bandbreitenfresser ist? Texturzugriff, MSAA oder was anderes? Um Ersteres wird man wohl nie herumkommen, die Datenmengen steigen ja auch stetig.

Ich wuerde auf Texturgriffe tippen obwohl an Bandbreiten-Verbrauch (stets je nach Fall) auf framebuffer traffic nicht als "unschuldig" ansehen wuerde. Fuer's erste bessere TC Algorithmen fuer's zweite framebuffer compression.

Ich meckere ja schon seit einer Ewigkeit dass Microsoft <8bpp TC Formate entwickeln sollte: http://www.khronos.org/news/press/khronos-releases-atsc-next-generation-texture-compression-specification

ASTC ist open source fuer SFF mobile und wird bald in hw erscheinen.

Alter B3D thread:

http://forum.beyond3d.com/showthread.php?t=20963

[Skysnake]

Laut LZ soll Maxwell 90% schneller als GK104 beim selben Verbrauch sein
http://www.hardwareluxx.de/community/f14/xxl-test-nvidia-geforce-gtx-titan-im-3-way-sli-942899-21.html#post20235394
:facepalm:
Mehr muss man dazu eigentlich nicht sagen...

Oder soll man LZs 15 SMX >80 (eher >100)% Leistung der GTX690 @stock alles wieder raus ziehen?
Das mit der Datenlokalität ist schon sehr interessant, aber ein Problem löst es nicht - man muss immer noch auf Texturen zugreifen, und die passen nicht in Caches, sondern müssen immer aus externen Speichern geholt werden. Kannst du abschätzen, was tendenziell der größte Bandbreitenfresser ist? Texturzugriff, MSAA oder was anderes? Um Ersteres wird man wohl nie herumkommen, die Datenmengen steigen ja auch stetig.
Datenlokalität ist DAS, was GPUs schon immer das Genick gebrochen hat, und was ihnen auch in Zukunft das Genick brechen wird...

Da muss einfach massiv dran gearbeitet werden, den Sweetspot zwischen Cachesize und Energieverbrauch für Übertragungen zu finden.

HIER liegt das wirkliche Entwicklungspotenzial von GPUs für GPGPU.

Bzgl Gameing (Texturen) sollte man sich keine großen Hoffnungen machen. So lange man sicht keine radikalen neuen Gedanken macht, wie man das Problem der Datenlokalität angeht, wird man beim Gameing immer mehr vor eine Wand rennen.

Da muss einfach massiv umgedacht werden. AMD hat das ja durchaus schon erkannt, und arbeitet bei Texturen ziemlich raffiniert rum. Also das Zeug aus der Leo (?) Demo meine ich.

[Ailuros]

Datenlokalität ist DAS, was GPUs schon immer das Genick gebrochen hat, und was ihnen auch in Zukunft das Genick brechen wird...

Da muss einfach massiv dran gearbeitet werden, den Sweetspot zwischen Cachesize und Energieverbrauch für Übertragungen zu finden.

HIER liegt das wirkliche Entwicklungspotenzial von GPUs für GPGPU.

Bzgl Gameing (Texturen) sollte man sich keine großen Hoffnungen machen. So lange man sicht keine radikalen neuen Gedanken macht, wie man das Problem der Datenlokalität angeht, wird man beim Gameing immer mehr vor eine Wand rennen.

Da muss einfach massiv umgedacht werden. AMD hat das ja durchaus schon erkannt, und arbeitet bei Texturen ziemlich raffiniert rum. Also das Zeug aus der Leo (?) Demo meine ich.

Ich schmeiss nochmal Xmas' Aussagen vom B3D link rein obwohl von 2005 bezweifle ich dass sich seither etwas wirklich so fundamental geaendert hat:

Bandwidth usage per frame goes up of course, but since there's only a limited number of processing units, bandwidth usage per clock or per second goes down.

As always, it depends on several factors. Considering bandwidth required per frame, vertex bandwidth usually stays the same as long as there is no resolution-dependent geometry LOD system.

Texturing bandwidth does scale less than linear, because more pixels per triangle means more coherency and more texture magnification. So it depends on texture resolution and how they're mapped to polygons. In today's games, texture bandwidth requirements per frame may scale proportionally when going from 640x480 to 800x600. But going from 2048x1536 to 3840x2880, you'll almost always see mip level 0 magnified. So there's practically an upper bound of how much texture bandwidth you might require per frame.

When no framebuffer compression is used, framebuffer (color, Z, and DAC readout) bandwidth scales about linear with resolution. However, framebuffer compression becomes more efficient with higher resolution, because the ratio of "interior tiles" to incompressible "edge tiles" increases.

Es haengt stets auch davon ab was Applikationen wirklich anstellen. Es ist eben auch nicht so dass IHV stets zu 100% sicher sind bei hw Entwicklung fuer die weitere Zukunft. Zu einem grossen Anteil sind es stets Einschaetzungen was fuer die moegliche Mehrzahl der Faelle der beste insgesamt tradeoff waere und natuerlich wird es immer einen gewissen Anteil an falschen design-Entscheidungen geben (entweder hw bug oder einfach N Faktor unterschaetzt). Ist ja wohl schon alles bekannt und die meisten wenn nicht alle verstehen schon dass es weder Allheilmittel geben wird noch das es eine einfache Formel fuer alle Probleme geben wird.

Eben weil GPUs so verdammt kompliziert sind, ist es auch immer verdammt schwer eine gesunde Balance von allen Faktoren zu finden. Zumindest sind wir heutzutage bei einem Punkt wo generell eingesehen wird dass Bandbreite nie an Wichtigkeit abgenommen hat; vor etlichen Jahren war der Konsensus bei spezifischen fanboys eben leider woanders. Noch besser Dally hat aus gutem Grund ein grosse Schwaeche fuer alles Bandbreiten-relatives.

Was jetzt caches noch betrifft: wir brauchen IMHO nicht unbedingt verrueckte Unmengen an caches auf zukuenftigen GPUs. Ich hab das Bauchgefuehl dass cache-freundlichere Architekturen bzw. effizientere caching Methoden der naechste logische Schritt sein koennte. Wie auch bei Bandbreite ist es weniger wichtig wie viel man davon hat, als wieviel Bandbreite man eigentlich verbraucht bzw. sparen kann.

[Skysnake]

Jup, deswegen ist AMDs Ansatz bzgl Texturen auch ziemlich vielversprechend. :up:

Damit umgeht man nämlich den explodierenden Bedarf an Cachesize, wenn man mit den bisherigen Methoden und gleichzeitig immer stärker ansteigender Variation an Texturen arbeitet.

Genau da seh ich eben eine ziemliche "Gefahr"

Die neuen Konsolen haben endlich richtig gut Platz für Texturen. Das wird man wohl auch nutzen, insbesondere auch sehr sehr sehr viel unterschiedliche Texturen gleichzeitig in einem Frame.

Das wird wirklich sehr interessant, wie sich das auf die benötigten Bandbreite/Performance auswirken wird.

ICH für meinen Teil kann das gar nicht abschätzen, außer halt, das ich mir absolut keine Hoffnung mache, das man mit den bisherigen Mitteln (ausgenommen die Technik von AMD) da noch große Leistungssteigerungen bei GPUs hinbekommen wird, ohne sich mal grundlegend ran zu setzen, und Texturing usw komplett zu überdenken.

Genug Chancen, frischen Wind rein zu bekommen hat man ja. HSA, DXz, das Texturmanagement von AMD (kann man ja bei nVidia sicherlich gut nachbauen) usw.

Man muss nur halt die Chance ergreifen.

[ndrs]

Was ist denn diese ominöse "die Technik von AMD"? Hat die auch nen Namen oder so?

[Skysnake]

http://www.compiware-forum.de/index.php?page=Thread&threadID=8060

Das meine ich. Sollte eigentlich klar sein durch den Bezug auf die Leo-Demo.

Keine Ahnung, wie das jetzt genau heist, weil PRT Tiles, also PartiallyResident Texutes, ist ja jetzt nichts, was man über Software nicht schon kennt.

Und nein, ich wurschtel mich jetzt nicht durch halbe WWW, um genau DEN einen Ausdruck zu finden, der das bezeichnet. Ich denke es ist klar, worum es geht, und das genügt ja.

[ndrs]

http://www.compiware-forum.de/index.php?page=Thread&threadID=8060

Das meine ich. Sollte eigentlich klar sein durch den Bezug auf die Leo-Demo.

Danke. Also quasi Megatextures in Hardware.

Keine Ahnung, wie das jetzt genau heist, weil PRT Tiles, also PartiallyResident Texutes, ist ja jetzt nichts, was man über Software nicht schon kennt.

Und nein, ich wurschtel mich jetzt nicht durch halbe WWW, um genau DEN einen Ausdruck zu finden, der das bezeichnet. Ich denke es ist klar, worum es geht, und das genügt ja.
Hätt' ich auch nicht verlangt :) Der Link langt mir schon.

[RLZ]

Amd hat in der Demo Ptex (http://ptex.us/ptexpaper.html)implementiert.

[Skysnake]

Danke. Also quasi Megatextures in Hardware.

Hätt' ich auch nicht verlangt :) Der Link langt mir schon.
Kein Ding, ich habs nur nicht so mit Namen :ugly:

Ist halt ne feine Sache, die gerade bei den zu erwartenden steigenden Texturauflösungen usw eben am Kern der Sache ansetzt, und nicht durch stiegende Cachesize/Bandbreite versucht die "Symptome" zu behandeln.

In dem Artikel heist es ja auch, das nVidia wohl an was ähnlichem arbeitet, was ich unterm Strich wieder scheise finde, wenns auf ne Softwarelösung raus läuft, die man dann expliziet nutzen muss.

Man muss echt schauen, wie sich das in der Zukunft entwickelt, aber der Ansatzpunkt ist in meinen Augen definitiv gut.

[Ailuros]

Megatextures in hw werden momentan von beiden IHVs unterstuetzt. Wie die Effizienz auf A oder B Architektur aussieht werden wir wohl mit der Zeit sehen. Heisst das Zeug auf GFs nicht "bindless textures" oder irre ich mich jetzt?

Entschuldige aber ich sehe in solchen Faellen keine absolute Loesung des eigentlichen Problems sondern eher temporaere Pflaster. Theoretisch wuerde auch jemand von MIR erwarten dass ich TBDR bzw. deferred texturing als Alternative erwaehne (und nein es spricht nichts gegen megatexturing auf einem DR), aber die sind nach wie vor auch kein Allheilmittel. Sie gewinnen heutzutage in Feld A und verlieren in Feld B; im Durchschnitt bezweifle ich dass es ein sehenswerter Vorteil wird.

Wenn mir jemand sagen koennte wie man es schafft eine anstaendige Unterstuetzung in zukuenftigen APIs zu entwickeln, dann waere tiling generell eine um einiges bessere Idee.

[Skysnake]

Naja, das läuft doch praktisch darauf hinaus, oder nicht?

Bzgl "bindless textures": Sicher, dass die da so was ähnliches machen? Also ich weiß, dass Sie da auch irgendwas in die richtung machen, aber die Unterschiede kann ich wirklich nicht benennen. Ich meine mich nur zu erinnern, dass das ne Softwarelösung war.

Ich finde es schade, dass da beide wieder mal ihr eigenes Süppchen kochen :down: Die sollten sich da zusammen tun, und aus beiden Ideen das Beste nehmen. Das wäre für uns Kunden das Beste.

[AffenJack]

Die beiden Lösungen sind doch sowieso gerade sinnlos, selbst wenn beide das gleiche machen würden, da nicht in DX implementiert. Auf OpenGl entwickeln nunmal viel zu wenige. Wichtig wirds wenns dann in Zukunft auf DX12 zu geht, aber davon hört man ja irgendwie gar nix oder gibts da schon Infos wann das kommen soll und ob die 20nm Generationen das haben werden?

[Gipsel]

Bindless Textures sind nicht ganz identisch mit dem PRT feature von GCN. Bindless Textures nutzen im Prinzip nur den Fakt aus, daß heutige GPUs den globalen Speicher (also den VRAM auf der Karte) beliebig adressieren können und nicht mehr nur auf eine limitierte Anzahl von Texturreferenzen angewiesen sind (gelöst wird es dadurch, daß Sampler und Texturen nicht mehr nur über eine von der API limitierten Anzahl an Referenzen angesprochen werden, sondern auch über Zeiger auf solche Strukturen; das können sowohl GCN als auch nV-GPUs ab Fermi). Es könne also mehr Texturen benutzt werden, allerdings müssen diese immer noch in den Speicher passen.

Die PRT-Implementation von AMD geht darüber etwas hinaus. Wie der Name schon sagt, müssen die 64kB Pages einer "MegaTexture" nicht mehr unbedingt alle im RAM liegen, die können im Zweifelsfall auch noch auf der Festplatte sein (das von GCN momentan unterstützte Größenlimit liegt bei maximal 32 TB). Ein Load von einer nicht im VRAM der Karte liegenden Adresse wird signalisiert und kann so (unter Entwicklerkontrolle) eine Exception auslösen. Im entsprechenden Handler kann man dann das Nachladen anstoßen.
Ein Vorteil von GCN gegenüber aktuellen nV-Karten kommt hier zum Tragen: beide unterstützen zwar noch keine Preemption, aber bei GCN kann jederzeit ein Exception-Handler auf der GPU laufen. Die Wavefront (und nur die eine, bei der es passiert) unterbricht in dem Fall ihre Ausführung des normalen Ablaufs und springt zu einem Exception-Handler (man kann mehrere definieren, eben wie auf CPUs auch). Da kann man dann entscheiden, was man (neben dem Anstoßens des Nachladens über die Erzeugung eines Interrupts für die CPU) machen will. Benutzt man eine bereits im Speicher befindliche niedriger aufgelöste MipMap und macht damit weiter, um Nachladeruckler zu vermeiden oder wartet man, bis das Nachladen fertig ist? Diese Wahl hat man bei nV nicht. Wenn eine Textur nicht da ist, ist sie nicht da und es gibt nichts, was man da tun kann.

Edit:
AMDs PRT Extension für OpenGL nutzt offensichtlich keine Exceptions. Es signalisiert lediglich dem Shader, daß man entweder versucht hat, von einer nichtvorhandenen Stelle zu lesen bzw. von einer zwar vorhandenen, aber gefährlich nah an einer nicht-vorhandenen.

[Coda]

Bindless Textures sind nicht ganz identisch mit dem PRT feature von GCN.
"Nicht ganz identisch"? Das ist doch komplett unabhängig und löst völlig unterschiedliche Probleme. Man will beides haben.

das können sowohl GCN als auch nV-GPUs ab Fermi).
Da bin ich mir nicht so sicher. Die TMUs in GCN könnten immer noch Register haben, die für die Bind-Slots die Speicheradressen der Texturen halten. Bisher sieht nichts danach aus, als würde AMD ähnliches unterstützen.

Die PRT-Implementation von AMD geht darüber etwas hinaus. Wie der Name schon sagt, müssen die 64kB Pages einer "MegaTexture" nicht mehr unbedingt alle im RAM liegen, die können im Zweifelsfall auch noch auf der Festplatte sein (das von GCN momentan unterstützte Größenlimit liegt bei maximal 32 TB). Ein Load von einer nicht im VRAM der Karte liegenden Adresse wird signalisiert und kann so (unter Entwicklerkontrolle) eine Exception auslösen. Im entsprechenden Handler kann man dann das Nachladen anstoßen.
Leider nicht. Die Texload-Instruction im Shader gibt nur einen Fehlercode zurück, den man sich dann in ein entsprechendes Target schreiben muss und dann auf der CPU wieder dem Treiber sagen, was er nachzuladen hat.

Zumindest funktioniert so die OpenGL-Extension. Das ist natürlich enttäuschend.

[Gipsel]

Da bin ich mir nicht so sicher. Die TMUs in GCN könnten immer noch Register haben, die für die Bind-Slots die Speicheradressen der Texturen halten. Bisher sieht nichts danach aus, als würde AMD ähnliches unterstützen.Nein, die kommen aus den Skalarregistern. Damit ist das in Hardware im Prinzip genauso implementiert, wie das bei nV auf der abstrahierten Ebene funktioniert (Zeiger auf kombinierte Textur-/Samplerreferenzen, bei AMD ist nur beides immer getrennt). Oder um mal das Southern Island ISA Manual zu zitieren:
All VM [vector memory] operations use an image resource constant (T#) that is a 128- or 256-bit value in SGPRs. This constant is sent to the texture cache when the instruction is executed. This constant defines the address, data format, and characteristics of the surface in memory. Some image instructions also use a sampler constant that is a 128-bit constant in SGPRs. Typically, these constants are fetched from memory using scalar memory reads prior to executing VM instructions, but these constants can also be generated within the shader.Wie diese "resource constants" aussehen, ist auch spezifiziert (da steht wirklich die virtuelle 48Bit Base-Adresse der Textur drin, welches Texturformat das ist, wie das Tiling aussieht, Scaling-Werte für LOD-Bias und AF-Grad usw.). Mit der Sampler-Konstante ganz genauso. Das ist einfach eine Datenstruktur in den Skalarregistern, die genau spezifiziert, was der Sampler tun soll. Irgendwelche Indizes dafür gibt es bei GCN nicht mehr. Die Hardware hat also Null Einschränkungen, was die Anzahl der verwendeten Texturen oder Sampler angeht. Im Prinzip muß der Shader nur irgendwie an die Adresse mit diesen Beschreibungen kommen (oder sich die Beschreibungen sogar selber zusammenbauen), genau wie bei nVs bindless textures.
Leider nicht. Die Texload-Instruction im Shader gibt nur einen Fehlercode zurück, den man sich dann in ein entsprechendes Target schreiben muss und dann auf der CPU wieder dem Treiber sagen, was er nachzuladen hat.

Zumindest funktioniert so die OpenGL-Extension. Das ist natürlich enttäuschend.Ja, auf die Idee, mal bei der OpenGL Extension nachzuschauen, bin ich dann auch gekommen. Und Du hast Recht, es ist doch nur die Schmalspurversion davon, was die Hardware eigentlich könnte.

[del_4901]

AMDs PRT Extension für OpenGL nutzt offensichtlich keine Exceptions. Es signalisiert lediglich dem Shader, daß man entweder versucht hat, von einer nichtvorhandenen Stelle zu lesen bzw. von einer zwar vorhandenen, aber gefährlich nah an einer nicht-vorhandenen.
Leider nicht. Die Texload-Instruction im Shader gibt nur einen Fehlercode zurück, den man sich dann in ein entsprechendes Target schreiben muss und dann auf der CPU wieder dem Treiber sagen, was er nachzuladen hat.

Zumindest funktioniert so die OpenGL-Extension. Das ist natürlich enttäuschend.
Und Du hast Recht, es ist doch nur die Schmalspurversion davon, was die Hardware eigentlich könnte.
Die Frage ist will man ueberhaupt mehr? Unvorhergesehene Laufzeiten sind eigentlich nicht erwuenscht. Zum Debugging ist so ein Exceptionhandler super, aber zur Laufzeit? Wie geht man mit den Einschraenkungen um? Naja ich les die Textur, und wenn das Tile nicht vorhanden ist dann gehe ich solange die Mip Stufen runter bis ich was finde. Die niedrigste Mip halte ich mir immer im Speicher, mehr braucht man eigentlich nicht.

[Coda]

Nein, die kommen aus den Skalarregistern. Damit ist das in Hardware im Prinzip genauso implementiert, wie das bei nV auf der abstrahierten Ebene funktioniert (Zeiger auf kombinierte Textur-/Samplerreferenzen, bei AMD ist nur beides immer getrennt). Oder um mal das Southern Island ISA Manual zu zitieren:
Wie diese "resource constants" aussehen, ist auch spezifiziert (da steht wirklich die virtuelle 48Bit Base-Adresse der Textur drin, welches Texturformat das ist, wie das Tiling aussieht, Scaling-Werte für LOD-Bias und AF-Grad usw.). Mit der Sampler-Konstante ganz genauso. Das ist einfach eine Datenstruktur in den Skalarregistern, die genau spezifiziert, was der Sampler tun soll. Irgendwelche Indizes dafür gibt es bei GCN nicht mehr. Die Hardware hat also Null Einschränkungen, was die Anzahl der verwendeten Texturen oder Sampler angeht. Im Prinzip muß der Shader nur irgendwie an die Adresse mit diesen Beschreibungen kommen (oder sich die Beschreibungen sogar selber zusammenbauen), genau wie bei nVs bindless textures.
Cool, umso besser.

Ja, auf die Idee, mal bei der OpenGL Extension nachzuschauen, bin ich dann auch gekommen. Und Du hast Recht, es ist doch nur die Schmalspurversion davon, was die Hardware eigentlich könnte.
Sicher? Steht das auch alles im Reference Manual? Muss ich mir mal genau durchlesen bei Gelegenheit.

[Gipsel]

@AlphaTier:
Stimmt vielleicht auch wieder.

Aber um mal wieder auf's Thema zu kommen, beide IHVs können so langsam virtuelle Adressen. Vielleicht sieht man sogar Ansätze, die Pages auslagern zu können (in langsameren Host-Speicher, auf die Festplatte?). Das könnte durchaus ein Bereich sein, in dem die GPUs mit den kommenden Generationen mit den CPUs beinahe gleichziehen. Ich denke nicht nur AMD mit ihrem HSA, sondern auch nV mit dem ominösen Project Denver (in der Maxwell Generation) werden uns da schon was in die Richtung zeigen.

[Gipsel]

Sicher? Steht das auch alles im Reference Manual? Muss ich mir mal genau durchlesen bei Gelegenheit.
Da steht natürlich nicht drin, wie die das PRT-Feature implementieren (außer der Erwähnung der beiden Bits LOD Warning Enable und Texture Fail Enable im Encoding der Vector Memory Instruktionen). Aber mit dem Exception-Support (edit: der bei nochmaligem Reinschauen doch auch seine Limitierungen hat) habe ich einfach vermutet, daß die das irgendwie nutzen. Aber wenn ich nochmal genauer darüber nachdenke, hat AlphaTier vermutlich recht. Man will ja auch nicht, daß in einem Frame, gleich ein paar hundert Mal der Exception-Handler anspringt und dann auch gleich ein paar hundert Mal Nachrichten an die CPU schickt (man kann mit Shadercode CPU-Interrupts auslösen, um da eine Aktion zu triggern, sollte der Treiber dann aber entsprechend an die Anwendung durchreichen). Da ist die Lösung über das Schreiben in einen kleinen Buffer (den die CPU dann liest und entscheidet, was gemacht wird) für diesen Zweck vermutlich sogar die bessere.

[Coda]

Das Problem ist halt, dass man dann wieder den Rage-Effekt hat, das heißt sichtbar nachladende Texturen.

Der einzige große Vorteil den ich gerade noch sehen kann ist, dass AF ohne Probleme funktioniert und es vielleicht ein bisschen schneller ist gegenüber der reinen Shader-Lösung.

[Gipsel]

Das Problem ist halt, dass man dann wieder den Rage-Effekt hat, das heißt sichtbar nachladende Texturen.Ansonsten hast Du halt hängende Frames und Ruckler. Keine Ahnung, ob das besser ist.

[del_4901]

Ansonsten hast Du halt hängende Frames und Ruckler. Keine Ahnung, ob das besser ist.
Dann lieber den RAGE Effekt.

Da steht natürlich nicht drin, wie die das PRT-Feature implementieren (außer der Erwähnung der beiden Bits LOD Warning Enable und Texture Fail Enable im Encoding der Vector Memory Instruktionen). Aber mit dem Exception-Support (edit: der bei nochmaligem Reinschauen doch auch seine Limitierungen hat) habe ich einfach vermutet, daß die das irgendwie nutzen. Aber wenn ich nochmal genauer darüber nachdenke, hat AlphaTier vermutlich recht. Man will ja auch nicht, daß in einem Frame, gleich ein paar hundert Mal der Exception-Handler anspringt und dann auch gleich ein paar hundert Mal Nachrichten an die CPU schickt (man kann mit Shadercode CPU-Interrupts auslösen, um da eine Aktion zu triggern, sollte der Treiber dann aber entsprechend an die Anwendung durchreichen). Da ist die Lösung über das Schreiben in einen kleinen Buffer (den die CPU dann liest und entscheidet, was gemacht wird) für diesen Zweck vermutlich sogar die bessere.Also ich wuerde jeden Miss in ein UAV schreiben, und dann in einem extra Pass Compute drueber laufen lassen, gleich sortieren, dann hast du auch gleich die Menge der Anfragen. Das kann man dann auf die CPU laden. Da kann man dann noch kombinieren mit Anfragen der letzten n-Frames, um dann irgendwie ne "clevere" Heuristik zu bauen.

Der einzige große Vorteil den ich gerade noch sehen kann ist, dass AF ohne Probleme funktioniert und es vielleicht ein bisschen schneller ist gegenüber der reinen Shader-Lösung.
Es gibt noch einen anderen man kann damit ja ganze Mip-Map Pyramide drin halten, damit hat man echtes HW beschleunigtes trilinear anisotropes filtering, und muss nicht entweder so umstaendlich mit einer zusaetzlichen Mip "hacken" oder alternativ selber im Shader filtern.

[Skysnake]

Ja, auf die Idee, mal bei der OpenGL Extension nachzuschauen, bin ich dann auch gekommen. Und Du hast Recht, es ist doch nur die Schmalspurversion davon, was die Hardware eigentlich könnte.
Und das ist ja nicht die einzige Stelle, wo man "Schmalspurversionen" von dem nur nutzt, was eigentlich in Hardware machbar ist, bzw. es sogar gar nicht nutzt :mad:

Cool, umso besser.

Sicher? Steht das auch alles im Reference Manual? Muss ich mir mal genau durchlesen bei Gelegenheit.
Und gleich weiter im reigen. Selbst Coda wird noch überrascht. Das ist SO plem plem... :(

Ich hoffe echt AMD drückt da mal RICHTIG auf die Tube, was die APIs anbelangt, damit man die ganzen Sachen auch nutzen kann. Immer wenn ich mich mit GCN beschäftige und über die Möglichkeiten der Architektur nachdenke, dann blutet mir das Herz, wenn ich dran denke, wieviel ungenutztes Potenzial da drin steckt :frown:



Aber um mal wieder auf's Thema zu kommen, beide IHVs können so langsam virtuelle Adressen. Vielleicht sieht man sogar Ansätze, die Pages auslagern zu können (in langsameren Host-Speicher, auf die Festplatte?). Das könnte durchaus ein Bereich sein, in dem die GPUs mit den kommenden Generationen mit den CPUs beinahe gleichziehen. Ich denke nicht nur AMD mit ihrem HSA, sondern auch nV mit dem ominösen Project Denver (in der Maxwell Generation) werden uns da schon was in die Richtung zeigen.
Jup, seh ich auch so. Beide müssen im Prinzip die gleichen Probleme lösen. Halt gemeinsamme Adressräume einer CPU+GPU. Da ist es einfach ganz logisch, was da an Rattenschwanz hinter her kommt.

Leider fährt nVidia mit Project Denver ja wieder ne Extratour... Mir wäre es sehr viel lieber, wenn die bei HSA mitmachen würden. Dann würde die Positionierung von HSA gegen Intel nochmals gesterckt, und man würde nicht wieder mit mindestens 2 Systemen daherkommen wie schon bei GPGPU...

Btw:
Gipsel sollte die Exception nicht limitierbar sein?
Wenn ich die Workgroupe, die die Exception auslöst, einfach nur schlafen lege, und mir in nem Bit/Register merke, das schon ne Exception ausgelöst wurde, und einen Schritt zurück gehe, dann kann ich ja anhand dessen, das nochmals ne Exception ausgelöst wird sehen, dass das noch nicht da ist, und dann einfach die alte nutzen.

Also so wirklich schlimm finde ich das jetzt nicht. Man kann es ja auf 1x limitieren, bzw auch über den Global shared Memory sich ein Limit setzen.

PS: Die Diskussion eventuell auslagern?

[del_4901]

Gipsel sollte die Exception nicht limitierbar sein?
Wenn ich die Workgroupe, die die Exception auslöst, einfach nur schlafen lege, und mir in nem Bit/Register merke, das schon ne Exception ausgelöst wurde, und einen Schritt zurück gehe, dann kann ich ja anhand dessen, das nochmals ne Exception ausgelöst wird sehen, dass das noch nicht da ist, und dann einfach die alte nutzen.

Also so wirklich schlimm finde ich das jetzt nicht. Man kann es ja auf 1x limitieren, bzw auch über den Global shared Memory sich ein Limit setzen.Und was soll die GPU solange machen, stallen? Da ist ein bissel mehr Latenz dahinter, jeh nachdem wo die Seite grade steckt. (Dann ist das nachschauen im GDS noch das kleinste Problem) Und was machst du wenn Exceptions auf unterschiedlichen Seiten ausgefuehrt werden? Wie soll die wiederverwendet werden? Ist dann nicht die Gefahr gross das sich die Threads gegenseitig den Cache/Speicher trashen? Und was passiert im worst case, wenn der GDS voll ist? Faengt man dann an die Sachen im Speicher zu merken?

[Skysnake]

Und was soll die GPU solange machen, stallen? Da ist ein bissel mehr Latenz dahinter, jeh nachdem wo die Seite grade steckt. (Dann ist das nachschauen im GDS noch das kleinste Problem) Und was machst du wenn Exceptions auf unterschiedlichen Seiten ausgefuehrt werden? Wie soll die wiederverwendet werden? Ist dann nicht die Gefahr gross das sich die Threads gegenseitig den Cache/Speicher trashen? Und was passiert im worst case, wenn der GDS voll ist? Faengt man dann an die Sachen im Speicher zu merken?
Wieso sollte der GDS voll werden? :ugly: Das nutzt du nur als scratchpad, um ein limit fest zu legen. Da kann man sich sogar überlegen NICHT mit atomaren funktionen drauf zu arbeiten, und dafür das limit niedriger zu wählen.

Und bzgl "flashen des RAMs", das sollte kein Problem sein. Man kann da ja lru oder sonst was machen, und eben z.b. Niedrigsten Stufen NICHT swapbar machen. Ich seh an nem Stall an sich kein Problem. Der Threadwechsel auf GPUs kostet ja praktisch nichts. Wir gehen ja nicht davon aus, das alle stallen müssen. Und selbst wenn, hauts einem halt die ersten x mal rein, und dann wenn das limit überschritten ist läufts mormal ab.

Also machbar ist das, und wenn mans ganz intelligent macht, macht man das ganze selbstoptiemierend. Bencht also das Syste erstmal, um einen Ausgangswert zu haben, also max limit für die stalles, und verwendet ansonsten ne heuristik über FPS und stalles, um das limit an zu heben/senken.

Gib dem Nutzer jetzt noch nen Schieberegler in die Hand, und er kann bestimmen, ob er lieber flüssige FPS, oder lieber keine aufploppenden Texturen, dafür aber ruckler haben will.

[del_4901]

@Skysnake Ich glaube du stelltst dir das etwas zu einfach vor.

[Chris Lux]

Das Problem ist halt, dass man dann wieder den Rage-Effekt hat, das heißt sichtbar nachladende Texturen.

Der einzige große Vorteil den ich gerade noch sehen kann ist, dass AF ohne Probleme funktioniert und es vielleicht ein bisschen schneller ist gegenüber der reinen Shader-Lösung.und man ein globales memory management auf der GPU implementieren kann. alle texturen werden in gleichgroße memory pages (64KiB hört man immer wieder) unterteilt. somit kann man den gesammten ram zwischen texturen unterschiedlichen formats und typ sharen im gegensatz zu den atlas lösungen bisher...

[john carmack]

nach Maxwell kommt Volta?

Dachte immer das Einstein der Nachfolger von Maxwell wäre?

Da kommt doch die Frage auf, wo hab ich Einstein als Nachfolger aufgeschnappt? :D



Nvidia Volta - ab 2016 (bis 1TB/s - könnte auf HMC´s hinweisen...)
1. http://www.forbes.com/sites/jasonevangelho/2013/03/19/nvidias-volta-gpu-launches-in-2016-delivers-1tbs-of-memory-bandwidth/

2. http://www.tweakpc.de/news/27209/nvidia-grafikkarten-serie-volta-enthuellt/

[Knuddelbearli]

ne Einstein war schon korrekt haben sie scheinbar geändert

[Ailuros]

Obwohl ich weiss auf was "Volta" genau anspielt rein zufaellig steht es in meiner Muttersprache fuer "Spaziergang" :devil:

[Fetza]

Obwohl ich weiss auf was "Volta" genau anspielt rein zufaellig steht es in meiner Muttersprache fuer "Spaziergang" :devil:

Jetzt machst du mich total ot-neugierig: Was ist denn deine muttersprache? :)

[Knuddelbearli]

Griechisch ...
der lebt mit eurem deutschen Geld *duck*

[Fetza]

Griechisch ...
der lebt mit eurem deutschen Geld *duck*

Das ist schon ok, er macht wenigstens was draus. :)

[Iruwen]

Wenn die Griechen denn mal was von unserem Geld sehen würden...

/e: ok zu OT :D

[Iruwen]

http://www.heise.de/newsticker/meldung/GTC-2013-Nvidia-kuendigt-Next-Gen-GPU-Volta-mit-Stacked-DRAM-an-1826130.html
Mh nice.

[Skysnake]

Nvidia Volta - ab 2016 (bis 1TB/s - könnte auf HMC´s hinweisen...)
1. http://www.forbes.com/sites/jasonevangelho/2013/03/19/nvidias-volta-gpu-launches-in-2016-delivers-1tbs-of-memory-bandwidth/

2. http://www.tweakpc.de/news/27209/nvidia-grafikkarten-serie-volta-enthuellt/
HMC und StackedDRAM haben apriori nichts miteinander zu tun.

Das sind zwei komplett unterschiedliche Sachen, außer halt das es beides Speichertechnologien sind.

[Nightspider]

Wenn man kein GDDR5 Speicher mehr verwendet sondern normalen DDR3/4 Speicher würde man wohl die Mehrkosten durch die StackedDRAM-Technik kompensieren und vielleicht am Ende noch Geld sparen.
Vielleicht kommt Volta dann schon mit 8-12GB VRAM.

[Skysnake]

GDDRx und DDR3/4 sind Interfaces, keine Speichertechnologien an sich...

[Ailuros]

Wenn die Griechen denn mal was von unserem Geld sehen würden...

/e: ok zu OT :D

Wenn ich wirklich Zeit und Lust haette auf solches OT Zeug zu antworten, wuerde Dir meine Antwort garantiert nicht schmecken genauso eben wie meinen Landsmaennern auch nicht. Sonst ist es wirklich nicht schoen mit solchem Unsinn da zu provozieren wenn Ihr alle genau weisst dass ich darauf nicht reagieren sollte und es auch nicht tun werde.

Zurueck zum Thema.