nVidia - GK110 - High-End-Kepler - Q1 2013 [Archiv] - Seite 6

Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidia - GK110 - High-End-Kepler - Q1 2013

Seiten : 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16

Ailuros

2012-10-13, 22:11:51

Ja, aber wieso gibt ein einziger Softwarekonzern das vor? Wieso nicht eine Gruppierung aus Spiele-(Engine)-Entwickler, Hardware-Vendor und OS-Hersteller??? Du könntest so etwas auf viel breiterer Front aufstellen. Aber irgendwie will ja jeder nur sein Süppchen verkaufen.
Gabe Newell ist wohl der einzige der es geschnallt hat ;D

Der Mythos duerfte auch sterben. Microsoft setzt APIs in Zusammenarbeit mit allen relevanten GPU IHVs fest und nicht alleine. Da die IHVs aber die alberne Tendenz haben sich oefters nicht einig werden zu wollen, stampft irgendwann M$ den Fuss auf den Boden und drueckt fuer finale Entscheidungen.

Wenn Du jetzt noch mehr Beteiligten auf das board bringst hast Du wieviel mehr Chancen dass sie sich einig werden?

Hübie

2012-10-13, 22:20:23

Ich lass mich gerne eines besseren belehren aber HyperQ bzw. dynamic parallelism duerften alles andere als billig sein in hw. Also 50% mehr Einheiten fuer GK114, womoeglich auch noch mit einem 384bit bus oder? und dann oben drauf HyperQ und dynamic parallelism? Das Ganze klingt mir nicht nach weniger als 450mm2 auf keinen Fall und das Ding soll dann auch noch mit Sea Islands konkurrieren?

Nach allen Indizien wird GK114 ein stinknormaler refresh zum GK104 mit ziemlich maessigem Leistungsunterschied.

Auf den Gedanken mit HQ/DyP kam ich, weil du meintest dass die 1 in der Mitte ein Alleinstellungsmerkmal dieses Chips repräsentieren soll ;D

[immy]oder den kleinsten gemeinsamen nenner

Das eben wohl zu häufig. Wenn man so sieht über was für Kleinigkeiten sich z.B. Coda bei DX10 gefreut hat :rolleyes: Ich sag ja nicht, dass es grundsätzlich schlecht ist, aber momentan ist es doch eindeutig so, dass die Softwareindustrie total überfordert ist. Unter anderem wegen der Probleme die Ailuros schon sagte:
Da die IHVs aber die alberne Tendenz haben sich oefters nicht einig werden zu wollen

Wahrscheinlich entscheiden das zu häufig BWL´er als die armen Schweine (Programmierer) oder ein mix aus beiden..?!

Ailuros

2012-10-13, 22:47:23

Auf den Gedanken mit HQ/DyP kam ich, weil du meintest dass die 1 in der Mitte ein Alleinstellungsmerkmal dieses Chips repräsentieren soll ;D

Kann sein dass ich falsch liege aber ich hab das Gefuehl dass Sachen wie HyperQ eher auf GK110 Sinn machen als woanders.

Das eben wohl zu häufig. Wenn man so sieht über was für Kleinigkeiten sich z.B. Coda bei DX10 gefreut hat :rolleyes: Ich sag ja nicht, dass es grundsätzlich schlecht ist, aber momentan ist es doch eindeutig so, dass die Softwareindustrie total überfordert ist. Unter anderem wegen der Probleme die Ailuros schon sagte:

Wahrscheinlich entscheiden das zu häufig BWL´er als die armen Schweine (Programmierer) oder ein mix aus beiden..?!

Um es einfacher zu machen: IHVs wie AMD und NVIDIA hoeren auf das was Entwickler zu sagen haben und auch moechten wollen aber stets im Raum des moeglichen.

Sonst wenn Du schon DX10 erwaehnst: am Anfang war dafuer programmierbare Tessellation geplant (aber natuerlich nicht so fortschrittlich wie am Ende in DX11); mit jeglichem neuen draft wurde die Progammierbarkeit geringer bis zum Punkt wo es irgendwo kurz vor der Entscheidung noch als ff optionale Tessellations-Einheit vorgeschlagen wurde und am Ende dann gleich entfernt. Wenn Intel u.a. nur so bruellten dass sie es nie schaffen werden so viel in hw zu giessen ist es auch klar dass nichts daraus wird.

Aber da nicht alles schwarz und weiss ist: angenommen es haette programmierbare Tesselation gegeben schon in DX10 haetten IHVs N% an Transistoren dafuer widmen muessen was wieder an der Leistung einer jeglichen DX10 GPU geknabbert haette. Solche Fortschritte sollten eher ankommen wenn die Zeit dafuer reif ist und hw es auch sinnvoller unterbringen kann. Es nutzt wohl nicht viel eine endlose lange Liste an neuen features auf einer neuen Technologie-Generation zu haben mit der man aber nicht besonders viel anfangen kann.

Nicht dass DX11 Tessellation das gelbste vom Ei waere, aber immer noch besser als gar nichts oder um einiges weniger. Damit micro-polygons erstmal richtig Sinn machen muessen sich in der weiteren Zukunft Architekturen IMHO radikal aendern, aber das ist auch ein ganz anderes Kapitel.

Hübie

2012-10-13, 23:07:37

Kann sein dass ich falsch liege aber ich hab das Gefuehl dass Sachen wie HyperQ eher auf GK110 Sinn machen als woanders.

Sehe ich anders. Man denke mal an Threads für Partikel-Physik, Fluid-Physik, KI-Routinen (geht das per GPU??), dann die "übliche" Raster- und/oder Vektorgrafiken, Kollisionsberechnungen... Sinvoll im Sinne von ertragreich mag aber sein. Ich kann mir noch nicht so richtig vorstellen wie sich das in HW gliedert. Du müsstest ja recht große/viele load/store-units haben. Und ein thread-scheduler der ziemlich umfangreich ist. Öhm - ja und was sonst noch...? :|

Wie aber zuvor erwähnt bin ich kein Programmierer (hab damals keine Lust mehr gehabt ;D).

Irgendwie hatten AMD/ATi schon mit R600 einen Tesselator, der wahrscheinlich nicht sehr leistungsfähig war aber bis zum RV9xx mitgeschleppt wurde ohne von irgendwen oder was genutzt zu werden :rolleyes:
Steinige mich wenn es ein Programm gibt welches diesen Teil unter OGL nutzte.

Ailuros

2012-10-13, 23:24:48

Sehe ich anders. Man denke mal an Threads für Partikel-Physik, Fluid-Physik, KI-Routinen (geht das per GPU??), dann die "übliche" Raster- und/oder Vektorgrafiken, Kollisionsberechnungen... Sinvoll im Sinne von ertragreich mag aber sein. Ich kann mir noch nicht so richtig vorstellen wie sich das in HW gliedert. Du müsstest ja recht große/viele load/store-units haben. Und ein thread-scheduler der ziemlich umfangreich ist. Öhm - ja und was sonst noch...? :|

Alles was GK110 zusaetzlich hat + mehr brauchbare Bandbreite. IMHO.

Irgendwie hatten AMD/ATi schon mit R600 einen Tesselator, der wahrscheinlich nicht sehr leistungsfähig war aber bis zum RV9xx mitgeschleppt wurde ohne von irgendwen oder was genutzt zu werden :rolleyes:
Steinige mich wenn es ein Programm gibt welches diesen Teil unter OGL nutzte.

Ohne API Unterstuetzung wird so ein Ding auch nichts nuetzen; erstens war es nichts anderes als ein quasi fixed function Tessellator was auch nicht besonders viel Transistoren gefressen hat und zweitens waere es fuer Ati teurer gewesen das Zeug zu entfernen als es stecken zu lassen.

Das hat jetzt nichts direkt mit dem vorigen zu tun. Denk anders dran: angenommen NV haette eine programmierbare Tessellations-pipeline in G80 integrieren muessen weil es unter DX10 Pflicht gewesen waere. Das Ding war riesig unter 90nm und sie haetten keine andere Wahl gehabt als woanders zu sparen um das Zeug unterzubringen und natuerlich haette die Leistung darunter leiden muessen. Mir ist als Verbraucher die zusaetzliche Leistung in solch einem Fall um Zich Male lieber oder auch von einer anderen Perspektive gegen die G70 die ich vor G80 hatte war die Bildqualitaet und Leistung mit AF generell ein Paradies.

Ich bin durchaus nicht gegen Fortschritt, aber es muss auch Sinn machen und eben die hw stark und flexibel genug sein um A, B oder C sinnvoll unterzubringen.

Hübie

2012-10-13, 23:32:08

Ja aber zeigte auch eindeutig wer den Ton angibt. G80 war schon ein Brett, ohne Zweifel. Aber mal angenommen alle hätten an einem Strang gezogen: dann hätten wir heute schätzungsweise schon breitflächiger eingesetzte HiPolyCount-modelle.
Na ja: das was wäre wenn Spielchen. Ich verlange wohl immer zu große Schritte, da ich mit der Salamitaktik nie konform gehen konnte und kann.

Ailuros

2012-10-14, 03:47:40

Ja aber zeigte auch eindeutig wer den Ton angibt. G80 war schon ein Brett, ohne Zweifel. Aber mal angenommen alle hätten an einem Strang gezogen: dann hätten wir heute schätzungsweise schon breitflächiger eingesetzte HiPolyCount-modelle.

Das klingt mir zu vereinfacht optimistisch, denn zwischen Theorie und Realitaet gibt es oefters so manchen Abstand. Ich erwarte selbst mit den heutigen GPUs keine besondere high poly count Explosion in zukuenftigen Spielen. Wenn diese kommt werden wohl heutige GPUs nicht mehr besonders relevant sein.

Uebertreibt man es mit heutigen GPUs mit Tessellation stocken andere Faktoren auf diesen und nicht die jeweiligen "Tessellation-pipelines".

Skysnake

2012-10-14, 10:12:19

Gar nichts ausser AMDs Gesamtperformance bei der GPU Palette. Wenn die gut ausfällt wird Nvidia genau das machen. Wenn sie nicht gut ausfällt wird Nvidia sich GK110 sparen und lieber die finanziell attraktivere Variante mit dem GK104 Nachfolger fahren. Nvidia muss im Prinzip nur jeweils knapp besser sein oder gleich schnell und das schnellste Halo Produkt haben. Das reicht für sie gegenwärtig um Marktanteile von AMD zu holen.
OMFG kommt jetzt wieder die "nVidia hat den GK100 eingestellt, nur weil AMD so schwach war"-Story oder was?

Meine Fresse, GK110 kommt wahrscheinlich für die Gamer erst (denke ich) in Q1-Q2 2013, und du faselst etwas von wege nvidia schaut sich das an, was AMD macht....

Die Produkte brauchen ziemlich lange, bis Sie fertig sind. Da änderst du absolut NICHTS mal so schnell in den letzten Monaten vor Veröffentlichung außer dem Takt um einige MHz nach oben oder unten...

Also bitte hört doch mit dem Rotz auf, ich kanns echt nicht mehr hören....

Kann sein dass ich falsch liege aber ich hab das Gefuehl dass Sachen wie HyperQ eher auf GK110 Sinn machen als woanders.

Meiner Meinung nach machts eigentlich sogar nur für Virtualisierungen Sinn, wo man nur sehr wenig Last hat, also wie beim schlichten darstellen des Desktops :ugly:

Bei allem anderen belegste ja normal die ganzen Ausführungseinheiten ohne Probleme.

Eventuell mischt nVidia aber auch Kernels, die viel Speicherbandbreite haben mit denen, die wenig brauchen. Halte ich aber für SEHR unwahrscheinlich, da Speicherbandbreite eigentlich meist der Flaschenhals ist.

In Kombination mit DynamikParalelism wirds dagegen wieder sinnvoll, da ja neue Kernel gestartet werden von einem laufenden Kernel, wo das Ganze auch ziemlich kleinkörnig werden kann.

DyP wirste aber ziemlich sicher expliziet programmieren müssen und eben nur unter CUDA laufen. Kannste im Gamermarkt also komplett knicken.

V2.0

2012-10-14, 10:27:42

Man darf nicht vergessen,dass die bisherigen Chips in 28nm bereits sehr gut laufen. Wir haben hier keine First Generation Fermis vor uns. 20% mehr Leistung gegenüber GK104 wird imho eher durch ein Verbreiterung der Architektur erfolgen, als über mehr Takt. Aber selbst das dürfte nicht einfach werden,dam man bereits jetzt böse an der Bandbreite nuckelt.
Viele neue Features würde ich nicht erwarten.

Duplex

2012-10-14, 10:59:51

GK110 ist interessanter als eine GK114 lücke, 40-50% mehr Leistung als GK104 sollte kein Problem sein, wenn die 28nm HP Produktion bei TSMC gut laufen sollte, dann gibt es auch keine Probleme mit der Anzahl der Wafer, wir reden hier über ein Produkt das wahrscheinlich ab April 2013 breit verfügbar sein wird.

Meine Vorstelung für 2013

Q2 - GK110 > High End (GTX780, GTX770)
Q3 - GK104 > Performance (GTX760, GTX760 TI)
Q4 - 2x GK110 > Enthusiast (GTX790)

Hübie

2012-10-14, 15:38:41

Die Produkte brauchen ziemlich lange, bis Sie fertig sind. Da änderst du absolut NICHTS mal so schnell in den letzten Monaten vor Veröffentlichung außer dem Takt um einige MHz nach oben oder unten...

Nanu. Du hast aber miese Laune :freak: Der Turbo wurde meines Wissens nach erst in einer sehr späten Phase installiert. Aber am Chipdesign an sich ändern die nix in letzter Minute, dass stimmt wohl ;) Wenn dem so wäre hätte die ja ne halbe Ewigkeit vorher Murks gemacht.

Aber reg dich mal net so auf - es ist Sonntag :smile:

Ailuros

2012-10-14, 19:01:46

V2.0

2012-10-15, 07:30:41

Nv mus sich umorientieren. Die APUs werden sie mächtig unter Druck setzen und den GPU Absatz im PC-Bereich massiv reduzieren. Wachstum findet größtenteils im mobilen Bereich statt und da eher in den SOCs als in den echten GPUs. Wenn AMD mich nnicht völlig überrascht werden deren Umorganisationen den Druck auf NV im GPU-Bereich sowieso eher senken, da man dort auch mehr in Richtung Fusion gehen wird (muss). Es würde mich nicht wundern wenn der 20nm Generation Top-Dog maximal 50-70% schneller als GK104 sein wird und man den Rest in eine geringe Chipgröße und weniger TDP investiert. Einzig Intels Angriff im Compute-Market könnte NV unter Druck setzen, aber ob NV den Kampf überhaupt gewinnen kann wenn Intel Ernst macht, ich habe da Zweifel.

Hübie

2012-10-15, 08:23:19

Nun ja. Ich agiere ggü. lernresistenten eben einfach anders und kannte so einen Ton von skysnake nicht ;) Was diese ganze Zukunftsprognosen angeht kann ich auch nur sagen dass wir bis 2015 in fast allen Bereichen mit Einbrüchen rechnen können. Selbst in meiner Branche siehts nich goldig aus (Metallveredelungs-Industrie).
Sowohl AMD als auch nVidia werden schon einen Weg finden. nVidia ist schon relativ stark im Mobilsegment während AMD mit HSA und cloud-Lösungen schon echte Schritte machte (SeaMicro war afaik der Anfang). Beide wollen jedoch in die Bereiche des Konkurrenten eindringen und da werden beide es erst wirklich schwer haben. Dedizierte Karten werden sicher (vorerst) nicht einfach verschwinden, sondern sich immer weiter nach oben bewegen. Performance wird imo wohl in Zukunft das Einstiegssegment von ded. Graka markieren. Alles darunter wird, sagen wir ab 2015, von iGPUs erledigt.
Ich berücksichtige bei meiner Theorie auch steigende Auflösungen/Pixeldichte.

Ailuros

2012-10-15, 09:19:59

Nv mus sich umorientieren. Die APUs werden sie mächtig unter Druck setzen und den GPU Absatz im PC-Bereich massiv reduzieren. Wachstum findet größtenteils im mobilen Bereich statt und da eher in den SOCs als in den echten GPUs.

Genau deshalb plant NV auch ab 20nm fuer higher end SoCs. NV's groesseres Problem duerfte Haswell heissen. Das letzte sieht von der GPU Seite alles andere als schwach aus, was erstmal keinen besonderen theoretischen Vorteil fuer NV am Ende laesst. Es sieht wohl eher danach aus dass es mit der CPU Schwaeche bei Denver, eher schwerer sein wird OEMs und Kunden damit zu ueberzeugen.

Wenn AMD mich nnicht völlig überrascht werden deren Umorganisationen den Druck auf NV im GPU-Bereich sowieso eher senken, da man dort auch mehr in Richtung Fusion gehen wird (muss). Es würde mich nicht wundern wenn der 20nm Generation Top-Dog maximal 50-70% schneller als GK104 sein wird und man den Rest in eine geringe Chipgröße und weniger TDP investiert.

Nur wenn NV einen unerwarteten Dreh macht und eine effiziente hw basierte mGPU Loesung auftischt. Beispiel waere ein maximaler 350-400mm2 top dog die mit HPC und direkt darunter ein 250-300mm2 performance GK1x4 Nachfolger. Bis jetzt sieht Maxwell aber eher nach einem weiteren >500mm2 single chip Monster aus; ich bezweifle dass sich daran so spaet in der Entwicklung viel aendern laesst.

Einzig Intels Angriff im Compute-Market könnte NV unter Druck setzen, aber ob NV den Kampf überhaupt gewinnen kann wenn Intel Ernst macht, ich habe da Zweifel.

Nein siehe oben. NV und AMD koennen weiterhin problemlos den >low end GPU Markt bedienen fuer den Intel fuer den Moment noch keine Plaene hat und zu grosse SoC die auch mainstream bedienen wuerden klingen fuer die naechsten paar Jahre IMO noch zu gewagt.

Anders NV hat was Intel betrifft sowohl die Sorge was low end/SoCs betrifft, als auch HPC. Intel's Erfolg im HPC Markt haengt IMHO eher von der eigentlichen Unterstuetzung ab und sie muessen auch dafuer sorgen dass der Stromverbrauch sich bei kommenden Knights-whatever Generation um einiges maessigt.

Persoenlich wuerde mir an NV's Stelle gegen Intel eher die low end PC/notebook SoCs sorgen machen als alles andere; unter der Vorraussetzung natuerlich dass Haswell auch wirklich eine so grosse Drohung wird wie es bis jetzt auf Papier bzw. Theorie aussieht.

Nun ja. Ich agiere ggü. lernresistenten eben einfach anders und kannte so einen Ton von skysnake nicht ;) Was diese ganze Zukunftsprognosen angeht kann ich auch nur sagen dass wir bis 2015 in fast allen Bereichen mit Einbrüchen rechnen können. Selbst in meiner Branche siehts nich goldig aus (Metallveredelungs-Industrie).

Mein Ton ist gelegentlich sogar schlimmer :wink:

Sowohl AMD als auch nVidia werden schon einen Weg finden. nVidia ist schon relativ stark im Mobilsegment während AMD mit HSA und cloud-Lösungen schon echte Schritte machte (SeaMicro war afaik der Anfang). Beide wollen jedoch in die Bereiche des Konkurrenten eindringen und da werden beide es erst wirklich schwer haben. Dedizierte Karten werden sicher (vorerst) nicht einfach verschwinden, sondern sich immer weiter nach oben bewegen. Performance wird imo wohl in Zukunft das Einstiegssegment von ded. Graka markieren. Alles darunter wird, sagen wir ab 2015, von iGPUs erledigt.
Ich berücksichtige bei meiner Theorie auch steigende Auflösungen/Pixeldichte.

Aufloesungen werden IMO kein Problem sein. Fuellraten gibt es mehr als genug auf GPUs heutzutage. 2015 ist noch etwas frueh. Zwischen der Ankuendigung und breiter Verfuegbarkeit von Denver basierenden SoCs gibt es schon einen Unterschied ueberhaupt da 20nm noch problematscher sein wird als 28nm. Von NV erwarte ich so etwas nicht bei dieser ersten PC/notebook SoC Generation und ich bezweifle dass es Intel auch schon so frueh plant.

Hübie

2012-10-15, 12:19:28

Was das angeht steht Intel denk ich gerade am Scheideweg. Deren erste Gehversuche im smartphone-Markt sehen nicht schlecht aus, aber bieten andererseits auch kein Alleinstellungsmerkmal. Die müssen also demnächst unheimlich viel Ressourcen (Zeit&Geld) in Softwareentwicklung/-distributoren stecken um langfristig ein Standbein da zu haben.
Über Denver weiß ich gerade aus dem Kopf nix um da nun mitzureden. Werd mich da später etwas belesen. Maxwell sieht für mich dagegen garnicht so schlecht aus.

Edit: Was mir noch einfiel: Die konservative CPU-Power wird ohne hin immer hintergründiger da u.a. HSA darauf abzielt die beiden verschiedenen Prozessoren je nach Rechenaufgabe zu belasten. Somit steht Denver mit der von dir angesprochenen CPU-Schwäche doch gar nicht in so schlechtem Licht - vorausgesetzt die Software kommt mit. Laut AMD ist es jedoch recht simpel zu implementieren.

Iruwen

2012-10-15, 14:33:47

Einzig Intels Angriff im Compute-Market könnte NV unter Druck setzen, aber ob NV den Kampf überhaupt gewinnen kann wenn Intel Ernst macht, ich habe da Zweifel.

Man kann nicht jedes Problem mit einem Haufen Geld lösen, siehe Larrabee.

Hübie

2012-10-15, 15:39:30

Irgendwie aber doch da Knights Ferry, oder wie XeonPhi´s codename nun auch sein mag, ja genau aus diesem Projekt entsprungen ist. MIC gäbe es ohne Daniel Pohl & Co (noch?) nicht.

HPVD

2012-10-15, 15:44:53

boxleitnerb

2012-10-15, 15:47:15

Tesla K20 Kepler (5GB ECC 2496 Core 1170-DP/3520-SP) 2950€

hier im Konfigurator:
http://www.cadnetwork.de/konfigurator/gpu_rackserver_proviz_g13/system=88

zum Vergleich (dort auch angebeben):
Tesla K10 Kepler (8GB ECC 3072 Core 119-DP/4577-SP)
Tesla M2090 (6GB ECC 512 Core 665-DP/1331-SP)

Klingt nach 320-bit und 13 SMX@703 MHz. Hoffen wir mal, das ist nicht der Vollausbau, den sie aktuell liefern können...

Charlie blubbert, das GK110 yields miserabel sind, dass GK110 schlecht performt, viel mehr Strom verbraucht...das Übliche eben :freak:

http://semiaccurate.com/2012/10/15/will-nvidia-make-a-consumer-gk110-card/

Ich glaube er stochert nur im Nebel herum, weil es sich nicht so liest, als habe er irgendwelche konkrete neue Informationen.

mczak

2012-10-15, 16:25:37

Klingt nach 320-bit und 13 SMX@703 MHz. Hoffen wir mal, das ist nicht der Vollausbau, den sie aktuell liefern können...

K20 soll doch der Top Compute Chip sein? Da machen 320-bit aber gar keinen Sinn - die 13 SMX wären auch am unteren Ende der Erwartung aber nicht weiter schlimm.
Es sei denn die "5GB" beziehen sich auf nutzbaren Speicher, nach Abzug von ECC sind's nämlich bei 384bit nur wenig mehr als 5GB bei 6GB Bestückung...

Charlie blubbert, das GK110 yields miserabel sind, dass GK110 schlecht performt, viel mehr Strom verbraucht...das Übliche eben :freak:

Scheint mir auch nur wenig plausibel. Die Probleme die nvidia mit der ersten Generation Fermis hatten scheinen doch bedeutend grösser gewesen zu sein als mit Kepler.
Dass da wahnsinnig mehr Strom verbraucht wird bin ich auch nicht überzeugt. Etwas mehr pro Gaming-Leistung wäre das sicher, aber durch die erwartete tiefere Taktfrequenz ist man wohl an einem günstigeren Punkt der Frequenz/Spannungskurve so dass imho am Ende die Desktop-gk110 mit einer ähnlichen Effizienz zu Buche stehen könnten wie die anderen Kepler-Karten.

boxleitnerb

2012-10-15, 16:36:29

AnarchX

2012-10-15, 16:36:58

Um möglichst viele verwendbare GPUs aus den Wafern zu bekommen, muss man wohl nun auch eine ROP-Partition deaktivieren.
Aber mit ~5,5Gbps GDDR5 hat man trotzdem noch deutlich mehr Bandbreite als die M2090.

Bei K10 werden auch die vollen 8GiB mit ECC angegeben.

Hübie

2012-10-15, 16:44:29

Es sei denn die "5GB" beziehen sich auf nutzbaren Speicher, nach Abzug von ECC sind's nämlich bei 384bit nur wenig mehr als 5GB bei 6GB Bestückung...

Würde dem restlichen Schema der Seite aber widersprechen, da die anderen auch mit 6 / 8 GB angegeben werden. Widerspricht auch meiner bisherigen Inforamtionsquelle. Entweder es gibt zwei Varianten der K20, meine sowie Ailuros´ Infos sind falsch oder der Händler hat noch nicht die korrekten Informationen. Wir werden sehen was nun bei herauskommt. :biggrin:

LG Hübie

Dural

2012-10-15, 16:48:44

nur 700MHz :rolleyes:

na dann läuft der chip wohl wirklich noch nicht rund, wenn Tesla GK110 jetzt im A2 stepping ausgeliefert wird, könnte desktop GK110 eventuell mit A3 kommen.

Gipsel

2012-10-15, 17:07:12

Na vielleicht kommt noch ein K25 mit dann 14 aktiven SMx und vollen 384Bit/6GB RAM (und auch leicht höherem Takt). Bei der Fermi-Generation gab es auch mit den M2050 und M2070 zwei Modelle (die sich allerdings nur in der Speichermenge unterschieden haben und später gab es von beiden höher getaktete Varianten und noch die M2090 als GF110-Version mit allen SMs aktiv). Wenn es denn 4GBit GDDR5-Chips gibt, sehen wir vielleicht auch noch 12 GB als K30.

Nightspider

2012-10-15, 18:24:33

Ach mit Wakü bekommt man das Teil sicherlich auch auf 1Ghz. =)

Das wären dann bestimmt GK104 +60-70% :ulol:

Zergra

2012-10-15, 18:48:51

Ach mit Wakü bekommt man das Teil sicherlich auch auf 1Ghz. =)

Das wären dann bestimmt GK104 +60-70% :ulol:
Solange du die Spannung Modifizieren kannst :D

Hübie

2012-10-15, 19:28:51

Waren die Ax steppings nicht metal spins? Hab mir eben mal die SA-News reingepfiffen: eine Seite die keine Zertifikatkette einhalten kann ist ohne hin nicht sehr vertrauenserweckend, oder?? ;D Bei mir kam nämlich erst mal ne fette Fehlermeldung!
Aber in der Vergangenheit machte Charlie immer zu gewissen Teilen wahrheitsgemäße Voraussagen ;)

CUDA 5 wurde veröffentlicht was konkret darauf hindeutet dass es bald erste speedtests geben wird. :naughty:

mczak

2012-10-15, 19:48:57

Die 5 GB legten die 320-bit eben nahe. Sollte auch machbar sein mit den Chips, also 20 Chips a 256 MByte, 10 vorne und 10 hinten. Dass ECC den nutzbaren Speicher verringert, wusste ich nicht, wieder was gelernt :)
Irgendwo müssen die Informationen für die Fehlerkorrektur ja gespeichert werden.
Bei PC-DIMMs bleibt die Kapazität dieselbe, die verwenden aber halt im Prinzip 72bit breite statt 64bit breite Riegel, mit entsprechend 9 statt 8 Chips (oder entsprechend mehr Chips) pro Seite. Wie genau ECC realisiert wird mit mehreren 64-bit Controllern bei GPUs weiss ich nicht aber jedenfalls wäre es unmöglich die physikalisch auf 72bit aufzubohren - schon nur weil die gddr5-Chips immer 32bit breit sind (das gilt auch im Clamshell-Mode da teilen sich halt 2 chips die 32bit).
ECC kostet also nicht nur nutzbare Speichermenge sondern genau so auch Speicherbandbreite.
Würde dem restlichen Schema der Seite aber widersprechen, da die anderen auch mit 6 / 8 GB angegeben werden. Widerspricht auch meiner bisherigen Inforamtionsquelle. Entweder es gibt zwei Varianten der K20, meine sowie Ailuros´ Infos sind falsch oder der Händler hat noch nicht die korrekten Informationen. Wir werden sehen was nun bei herauskommt. :biggrin:

LG Hübie
Das stimmt eine solche Angabe wäre nicht sehr konsistent.
2 Varianten mit verschieden breiten Interfaces könnten Sinn ergeben wenn man davon ausgeht dass 4gbit gddr5 Chips noch nicht erhältlich sind, denn eine Differenzierung bezüglich der Speichergrösse und Speicherbandbreite würde im Compute-Markt wohl sinnvoll sein (und 3GB vielleicht als zu klein angesehen, also 5GB/6GB). Das gilt allerdings imho nur wenn beide Versionen gleichzeitig erhältlich wären, denn später kann man doch sowieso mit 4gbit Chips viel mehr Speicher bieten.
Aber bisher hat man ja nur von K20 gehört, also einem einzelnen Produkt. Den Chip da ausgerechnet beim Speicherinterface zu beschneiden scheint mir nicht sehr sinnvoll. Ausserdem hat man dann ja sogar noch weniger Speicher zu bieten als beim Vorgänger M2090 und sogar dem Vor-Vorgänger M2070 - für ein Topmodell scheint mir das nicht in Ordnung zu sein. Wahrscheinlich erreicht man auch nicht dieselben Speichertaktraten wie bei den Desktop-Produkten, die effektiv nutzbare Speicherbandbreite wäre dann also mit 320bit (und ECC) geringer als bei einer GTX670/680 (ohne ECC) auch wenn ein solcher Vergleich ein bisschen unfair ist.

Ailuros

2012-10-15, 20:18:59

Wer will den Thread hier durchsuchen fuer einen Post wo ich sagte dass ich etwas rausgeschickt habe und auf die Resultate warte? Besser spaet als nie.

Korrekte Daten, falsche Schlussfolgerungen, sonst bin ich total unschuldig :freak:

Klingt nach 320-bit und 13 SMX@703 MHz. Hoffen wir mal, das ist nicht der Vollausbau, den sie aktuell liefern können...

Charlie blubbert, das GK110 yields miserabel sind, dass GK110 schlecht performt, viel mehr Strom verbraucht...das Übliche eben :freak:

http://semiaccurate.com/2012/10/15/will-nvidia-make-a-consumer-gk110-card/

Ich glaube er stochert nur im Nebel herum, weil es sich nicht so liest, als habe er irgendwelche konkrete neue Informationen.

Dummerweise: 13 SMXs * 196SPs = 2548

Anders rum: 2496 / 196 = 12.73 *seufz*

Gipsel

2012-10-15, 20:41:52

Dummerweise: 13 SMXs * 196SPs = 2548

Anders rum: 2496 / 196 = 12.73 *seufz*
Sind aber nur 192 SPs pro SMx. ;)

Ailuros

2012-10-15, 20:42:47

Sind aber nur 192 SPs pro SMx. ;)

Mist; vedammte brainfarts. Ich brauch Urlaub :mad:

***edit: nun die 705MHz waeren erstmal nicht schlecht, aber auch nicht so berrauschend wie die bisherigen Geruechte. Das eher beunruhigende ist dass es nur 13 SMXs fuer K20 Tesla sein koennten. Auf jeden Fall sind maximal theoretische 1.17TFLOPs eben nicht reale >1TFLOP DGEMM wie NV selber in ihrem Tesla Kepler whitepaper angiebt; wohl eher ~930GFLOPs DP@DGEMM.

1Based on DGEMM performance: Tesla M2090 (Fermi) = 410 gigaflops, Tesla K20 (expected) > 1000 gigaflops

http://www.nvidia.com/content/tesla/pdf/nv-ds-teslak-family-jul2012-lr.pdf

Hugo78

2012-10-15, 21:03:40

Wenn NV nicht grad die Preise senkt, dann ersetzt diese 13 SMX Version preislich auch nicht die M2090 (~4000€), eher die M2070 (~3000€).

HPVD

2012-10-15, 21:20:07

Wenn NV nicht grad die Preise senkt, dann ersetzt diese 13 SMX Version preislich auch nicht die M2090 (~4000€), eher die M2070 (~3000€).

hmm
ich find die M2090 zumindest aktuell für 3000€:
http://www.google.de/products/catalog?q=preis+m2090&hl=de&prmd=imvns&bav=on.2,or.r_gc.r_pw.r_qf.&bpcl=35277026&biw=1056&bih=652&um=1&ie=UTF-8&cid=9586790205147378895&sa=X&ei=RmF8UJ6FGonusgaf_IHACA&ved=0CGcQ8wIwADgU

mag sein dass sie früher teurer war - bei geizhals.at gibts leider keinen vernünftigen Preisverlauf zu diesem Produkt...

Hugo78

2012-10-16, 00:00:59

Bis auf die PNY liegt der Preis wie seit anfang an bei knapp 4000€.
- http://www.google.de/search?tbm=shop&hl=de&q=m2090&oq=m2090&gs_l=products-cc.3..0j0i5l2.15011.15011.0.15874.1.1.0.0.0.0.32.32.1.1.0...0.0...1ac.1.ZsN6hAl3 uCU
Eventuell ein erster Abverkauf seitens PNY.

Skysnake

2012-10-16, 10:42:03

Nanu. Du hast aber miese Laune :freak: Der Turbo wurde meines Wissens nach erst in einer sehr späten Phase installiert. Aber am Chipdesign an sich ändern die nix in letzter Minute, dass stimmt wohl ;) Wenn dem so wäre hätte die ja ne halbe Ewigkeit vorher Murks gemacht.

Aber reg dich mal net so auf - es ist Sonntag :smile:
Ja, aber das muss manchmal sein :mad: Ich kann manche Sachen einfach nicht mehr hören. nVidia kocht auch nur mit Wasser, genau wie alle anderen auch. AMD hat dieses mal echt ordentliche Produkte, genau wie nVidia auch, nur dass Sie eben beide etwas aus dem raus fallen, was man eigentlich gewohnt ist. Viele Leute schnallen aber nicht, das sich doch einiges geändert hat, und reiten auf alten Kamellen rum, die heute nicht mehr zutreffend sind. Ganz zu schweigen davon, das dem (viralen)Marketing nachgeblubbert wird...

Naja, und wenn man eben sieht, wie schwierig es ist, nen ASIC zu bauen, um mich rum sitzen genug Leute, die davon graue Haare bekommen, dann fässt man sich einfach nur noch an den Kopf, was sich einige hier vorstellen, und wenn man dann versucht denen klar zu machen, dass das einfach nicht so einfach ist, dann wird das gekonnt ignoriert... Da platzt einem halt irgendwann der Kragen, wenn man gewisse Dinge zum 10k-sten mal hört. Ist genau wie die Sache mit PCI-E 3.0 und den i-Core SB-E... Aber lassen wir das Thema lieber....

Nun ja. Ich agiere ggü. lernresistenten eben einfach anders und kannte so einen Ton von skysnake nicht ;) Was diese ganze Zukunftsprognosen angeht kann ich auch nur sagen dass wir bis 2015 in fast allen Bereichen mit Einbrüchen rechnen können. Selbst in meiner Branche siehts nich goldig aus (Metallveredelungs-Industrie).
Sowohl AMD als auch nVidia werden schon einen Weg finden. nVidia ist schon relativ stark im Mobilsegment während AMD mit HSA und cloud-Lösungen schon echte Schritte machte (SeaMicro war afaik der Anfang). Beide wollen jedoch in die Bereiche des Konkurrenten eindringen und da werden beide es erst wirklich schwer haben. Dedizierte Karten werden sicher (vorerst) nicht einfach verschwinden, sondern sich immer weiter nach oben bewegen. Performance wird imo wohl in Zukunft das Einstiegssegment von ded. Graka markieren. Alles darunter wird, sagen wir ab 2015, von iGPUs erledigt.
Ich berücksichtige bei meiner Theorie auch steigende Auflösungen/Pixeldichte.
Jaein,

Auf der einen Seite hast du natürlich recht, die APUs nagen schon am Absatz für die dedizierten GPUs. Dafür steigt die Leistung bei denen aber auch tendenziell etwas stärker an als zuletzt. Vor allem, wenn man die Effizienz berücksichtigt.

Auf der anderen Seite kommt aber eben auch Hasswell, wo man massiv die GPU nochmals ausbaut bei Intel, und das denke ich, genau wie du, wird nVidia schon hart treffen, da man eben sehr viele Chips in den Laptops mit Intel CPUs abgesetzt hat bis jetzt. Das wird in Zukunft wohl weiter zurück gehen. Insbesondere mit Haswell natürlich. Das Problem der mangelnden Bandbreite bleibt bei den APUs aber weiterhin bestehen! Da gibts auch mit DDR4 keine wirkliche Veränderung an der Gesamtsituation. Die MCMs mit ihrem eDRAM sind da auch nur eine "Notlösung".

Hybrid-MemoryCube könnte die Karten da allerdings komplett neu mischen, und Intel/Micron usw drücken da schon ziemlich auf die Tube, wie mir scheint. Wenn das kommt, dann könnten echt große APUs/SOCs realisierbar werden, mit denen auch der Performance-Sektor bei den GPUs angreifbar wird. Dafür könnten aber auch die High-End GPUs nochmal einen gewaltigen Sprung nach vorne machen...

Sowohl du als auch Ailuros haben da durchaus recht. Man kann einfach noch nicht genau abschätzen, wie sich die ganze Sache entwickelt. nVidia versucht halt auch im Mobile-Markt Fuß zu fassen, der ist aber sehr stark umkämpft, und im Moment tun Sie sich noch ziemlich schwer. Da ist also auch noch nicht abschätzbar, wie sich das entwickelt, zumal eben der PC-Markt massiv einbricht, was dann natürlich Gelder kostet, die einem in der Forschung fehlen... Da muss man aufpassen, das man nicht in einen Teufelskreis kommt.

Mit AMD muss man da auch extrem schauen, was da draus wird. Ich befürchte inzwischen wirklich, dass Sie sich mit HSA verzockt haben. Nicht weil es schlecht ist, sondern einfach weil Sie nicht einen lang genügenden Atem haben, um die Durststrecke zu überbrücken, bis es ein Erfolg wird.... AMD hat halt, wie es scheint echt hoch gepokert, und atm siehts für mich eher danach aus, als ob Sie dabei verlieren. Die Wirtschaftskrise hat aber auch keiner Vorhergesehen (also nicht wirklich einer mit Namen).

Genau deshalb plant NV auch ab 20nm fuer higher end SoCs. NV's groesseres Problem duerfte Haswell heissen. Das letzte sieht von der GPU Seite alles andere als schwach aus, was erstmal keinen besonderen theoretischen Vorteil fuer NV am Ende laesst. Es sieht wohl eher danach aus dass es mit der CPU Schwaeche bei Denver, eher schwerer sein wird OEMs und Kunden damit zu ueberzeugen.

Dem kann ich zustimmen. Intel legt da halt schon gut zu.

Nein siehe oben. NV und AMD koennen weiterhin problemlos den >low end GPU Markt bedienen fuer den Intel fuer den Moment noch keine Plaene hat und zu grosse SoC die auch mainstream bedienen wuerden klingen fuer die naechsten paar Jahre IMO noch zu gewagt.

Ich denke auch, so lange sich am Speicherinterface nicht grundlegend etwas ändert, also in Richtung (Hybrid-)MemoryCube, wird es wirklich große SOCs nicht geben. Maximal von AMD was mit nem Quad-Channel-DDRx Speichercontroller auf HSA basis, aber das dauert wohl auch noch einige Jahre (2+).

Anders NV hat was Intel betrifft sowohl die Sorge was low end/SoCs betrifft, als auch HPC. Intel's Erfolg im HPC Markt haengt IMHO eher von der eigentlichen Unterstuetzung ab und sie muessen auch dafuer sorgen dass der Stromverbrauch sich bei kommenden Knights-whatever Generation um einiges maessigt.

Oh ja ;D

Persoenlich wuerde mir an NV's Stelle gegen Intel eher die low end PC/notebook SoCs sorgen machen als alles andere; unter der Vorraussetzung natuerlich dass Haswell auch wirklich eine so grosse Drohung wird wie es bis jetzt auf Papier bzw. Theorie aussieht.

absolut /sign

Mein Ton ist gelegentlich sogar schlimmer :wink:

Und nochmal ein FETTES /sign ;D Ich bin eigentlich sehr geduldig :cool:

Man kann nicht jedes Problem mit einem Haufen Geld lösen, siehe Larrabee.
Oh JA!

Was aber noch nie Thematisiert wurde ist, das es neben Geld eben auch einen zweiten Faktor gibt. MANPOWER!

Wobei das meist in einem Zusammenhang steht, da man sich mit Geld zumeist Manpower leisten kann, was eben Intel gemacht hat/macht. Also eigene Fabs, mehrere Entwicklerteams usw usw. Sprich wenn was schief läuft, hat man was anderes noch in der Hinterhand. Das konnte sich neben IBM eigentlich nur Intel leisten, wobei IBM ja Grundlagenforschung macht, und daher etwas anders arbeitet.

Ich hatte diese Woche aber ein interessantes Gespräch, und wenn ich so darüber nachdenke, was ich da so gehört habe, dann wächst da im Moment wirklich ein gefährlicher Gegner für Intel, nVidia, IBM und vielleicht auch AMD heran. AMD vielleicht, weil die auch in dessen Fahrtwasser mitschwimmen könnten, oder schlicht geschluckt werden könnten. Das wird man sehen müssen. Mir war vor dem Gespräch schon klar, dass da ein gewaltiges Monster am schlummern ist, jetzt glaube ich aber gar nicht mehr, dass das Monster am schlummern ist, sondern dabei ist sich darauf vorzubereiten, in Erscheinung zu treten. Und da reden wir von einem paar Monster, das ein paar Milliarden Menschen trägt ;)

Klingt nach 320-bit und 13 SMX@703 MHz. Hoffen wir mal, das ist nicht der Vollausbau, den sie aktuell liefern können...

Charlie blubbert, das GK110 yields miserabel sind, dass GK110 schlecht performt, viel mehr Strom verbraucht...das Übliche eben :freak:

http://semiaccurate.com/2012/10/15/will-nvidia-make-a-consumer-gk110-card/

Ich glaube er stochert nur im Nebel herum, weil es sich nicht so liest, als habe er irgendwelche konkrete neue Informationen.
Schwer zu sagen.

Mist; vedammte brainfarts. Ich brauch Urlaub :mad:

***edit: nun die 705MHz waeren erstmal nicht schlecht, aber auch nicht so berrauschend wie die bisherigen Geruechte. Das eher beunruhigende ist dass es nur 13 SMXs fuer K20 Tesla sein koennten. Auf jeden Fall sind maximal theoretische 1.17TFLOPs eben nicht reale >1TFLOP DGEMM wie NV selber in ihrem Tesla Kepler whitepaper angiebt; wohl eher ~930GFLOPs DP@DGEMM.

http://www.nvidia.com/content/tesla/pdf/nv-ds-teslak-family-jul2012-lr.pdf
Naja, genau das, also das mit den 13 SMX, habe ich ja neulich erst thematisiert, wo du mir so ziemlich übers Maul gefahren bist :P

Bei mir wars halt nur eine Befürchtung, und ich glaube jetzt auch noch nicht daran, dass das mit den 13 SMX stimmt, aber es könnte sich eventuell als wahr herausstellen. Davor wollte ich nur mahnen, also das man nicht zu zuversichtlich/blauäugig sein sollte.

Bzgl DGEMM muss ich da aber ein ganz klein bischen widersprechen. DGEMM ist bei GPUs schon ziemlich Speicherabhängig. Gerade da wird man aber einen Schritt nach vorne machen. Dabei meine ich nicht mal direkt die Bandbreite des SI, sondern den L2 Cache. Der wächst massiv an. Damit steigt die Datenreuse Rate auch massiv an.....

Könnte also eventuell trotzdem ausgehen, einfach weil man bei diesem speziellen Problem mit massiver Optimierung gerade so über 1TFlop kommt. Ist halt einfach schwer zu sagen, wie da das Zusammenspiel aus größeren Caches usw ist. Ich trau mich da wirklich nicht eine Aussage zu treffen, außer die, das nVidia wohl alles daran setzen wird, zumindest mit dem Top-Dog die 1TFlop/s-Marke bei DGEMM zu knacken.

Ailuros

2012-10-16, 11:48:06

Naja, genau das, also das mit den 13 SMX, habe ich ja neulich erst thematisiert, wo du mir so ziemlich übers Maul gefahren bist :P

Du hast mich trotzdem lieb :tongue: Es ging nicht um die Anzahl der SMXs per se sondern wieso es bei einem so komplizierten chip nicht moeglich ist zu erwarten dass keine Einheiten deaktiviert werden beim ersten run.

Bei mir wars halt nur eine Befürchtung, und ich glaube jetzt auch noch nicht daran, dass das mit den 13 SMX stimmt, aber es könnte sich eventuell als wahr herausstellen. Davor wollte ich nur mahnen, also das man nicht zu zuversichtlich/blauäugig sein sollte.

NV gibt selber in einem Kepler whitepaper an dass es moeglicherweise Varianten mit 13 oder 14 SMXs geben wird. Genau sind sie auch nicht darueber. Aber ich traue ihnen locker zu dass sie Oak Ridge und anderen Kunden die Sahne geliefert haben und der Rest muss sich mit den 13 SMX Ueberresten zufrieden stellen. Das hat jetzt nichts mit den vorigen Oak Ridge Geruechten zu tun. So wie es aussieht mit den 13 SMX Dingern, sieht eine desktop Variante mit allen SMXs eingeschaltet fuer den Anfang zugegeben duester aus.

Bzgl DGEMM muss ich da aber ein ganz klein bischen widersprechen. DGEMM ist bei GPUs schon ziemlich Speicherabhängig. Gerade da wird man aber einen Schritt nach vorne machen. Dabei meine ich nicht mal direkt die Bandbreite des SI, sondern den L2 Cache. Der wächst massiv an. Damit steigt die Datenreuse Rate auch massiv an.....

Nach NV's eigenen Kepler Tesla whitepapers erreicht K20 unter DGEMM eine 80% Effizienz von der maximalen DFLOP Rate. 1.17TFLOPs DP * 80% = 936 GFLOPs/s DGEMM.

Könnte also eventuell trotzdem ausgehen, einfach weil man bei diesem speziellen Problem mit massiver Optimierung gerade so über 1TFlop kommt. Ist halt einfach schwer zu sagen, wie da das Zusammenspiel aus größeren Caches usw ist. Ich trau mich da wirklich nicht eine Aussage zu treffen, außer die, das nVidia wohl alles daran setzen wird, zumindest mit dem Top-Dog die 1TFlop/s-Marke bei DGEMM zu knacken.

Wie denn mit dem obrigen als Anhaltspunkt und WENN K20 nur als 13SMX@705MHz (einzige Variante) erscheint?

Skysnake

2012-10-16, 12:20:07

Mit weniger SMX steigt die Effizienz an, wenn der L2 unbeschnitten bleibt ;)

Genau so mit weniger GPu-Takt vs RAM-Bandbreite.

Die 80% sind daher nicht statisch. Mit den 1.17 reichen schon 85,5% Effizienz, um die 1TFlop/s DP zu knacken. Das ist nicht soooo viel Unterschied. Wie gesagt, ich trau mir nicht zu, zu beurteilen, ob die das schaffen oder nicht.

Die werden es ja, wie gesagt wohl zur Not mit der Brechstange versuchen. Gerade die von dir angenommene "Sahne" für Oak Ridge usw. könnte dafür durchaus herhalten müssen.

PS: Und ja, ich nehms dir nicht übel :tongue:

Ailuros

2012-10-16, 12:31:13

Mit weniger SMX steigt die Effizienz an, wenn der L2 unbeschnitten bleibt ;)

Genau so mit weniger GPu-Takt vs RAM-Bandbreite.

Die 80% sind daher nicht statisch. Mit den 1.17 reichen schon 85,5% Effizienz, um die 1TFlop/s DP zu knacken. Das ist nicht soooo viel Unterschied. Wie gesagt, ich trau mir nicht zu, zu beurteilen, ob die das schaffen oder nicht.

Jetzt hab ich's geschnallt; klingt auch durchaus logisch.

gorg_graggel

2012-10-16, 13:59:29

http://www.heise.de/newsticker/meldung/Finale-Spezifikationen-von-Nvidias-Tesla-K20-mit-GK110-GPU-enthuellt-1730408.html

HPVD

2012-10-16, 14:09:37

http://www.heise.de/newsticker/meldung/Finale-Spezifikationen-von-Nvidias-Tesla-K20-mit-GK110-GPU-enthuellt-1730408.html

dann lesen die heise-jungs wohl hier mit :-)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9503289&postcount=1269

AnarchX

2012-10-16, 14:12:29

Bis heute Vormittag hatte sich das auch auf andere Seiten verteilt.

200GB/s, also wohl 5Gbps GDDR5. Nur magere 12% mehr als bei der M2090.

Ailuros

2012-10-16, 14:16:07

dann lesen die heise-jungs wohl hier mit :-)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9503289&postcount=1269

Ja aber ordentlich weitergeforscht haben sie schon:

Diese laufen mit 705 MHz und erreichen somit eine theoretische Rechenleistung von 3,52 Billionen Gleitkommaoperationen pro Sekunde (TFlops) bei einfacher und 1,17 TFlops bei doppelter Genauigkeit. CADnetworks' Geschäftsführer Enrico Reil erklärte uns außerdem telefonisch, dass die Transferrate bei 200 GByte/s liege. Damit fällt sie geringer aus als erwartet. Als maximale Leistungsaufnahme gibt Nvidia laut Reil 225 Watt an. Reil unterstrich im Gespräch, dass alle Daten direkt von Nvidia kommen und auch schriftlich vorliegen.

200GB/s? Hey Skysnake, schreib die 1TFLOP DGEMM sicherheitshalber erstmal ab.

HPVD

2012-10-16, 14:18:17

Bis heute Vormittag hatte sich das auch auf andere Seiten verteilt.

200GB/s, also wohl 5Gbps GDDR5. Nur magere 12% mehr als bei der M2090.

eigentlich kann das aber wirklich nicht die größte Version sein.
Schon allein wegen den nur 5GB muss! es weiter Versionen geben...

HPVD

2012-10-16, 14:27:54

kenn mich mit DGEMM nicht aus.

Ist mit dem Ziel 1TFLOP DGEMM Rpeak oder Rmax gemeint?

zum Vergleich:
die 7970 (normale edition) scheint
Rpeak= 925
Rmax = 623
zu machen.

http://devgurus.amd.com/servlet/JiveServlet/showImage/2-1284414-1177/amd_dgemm_res.png

Die GHz edition bzw Takt fast equivalente Firepro (W9000, 975 MHz, 6GB, 264GB/s) sollte entsprechend schneller sein

Quelle: http://devgurus.amd.com/thread/159457

Ailuros

2012-10-16, 14:28:56

Bis heute Vormittag hatte sich das auch auf andere Seiten verteilt.

200GB/s, also wohl 5Gbps GDDR5. Nur magere 12% mehr als bei der M2090.

Mit 13 SMXs wuerde ich es eher zur 2050 (238W/3GB) vergleichen. Die core-Frequenzen zu vergleichen ist ziemlich nutzlos, aber es sind ~37% mehr (515 vs. 705MHz) und fuer den Speicher ~60% mehr Speichertakt (782 vs. 1250MHz); 5GB framebuffer bei 225W TDP.

HPVD

2012-10-16, 14:44:08

Mit 13 SMXs wuerde ich es eher zur 2050 (238W/3GB) vergleichen. Die core-Frequenzen zu vergleichen ist ziemlich nutzlos, aber es sind ~37% mehr (515 vs. 705MHz) und fuer den Speicher ~60% mehr Speichertakt (782 vs. 1250MHz); 5GB framebuffer bei 225W TDP.

so macht macht das dann schon eher Sinn und passt besser zu den Erwartungen.
Die Frage ist dann aber auch: wie lange muss man dann noch auf das "große /vollständige/höher getaktete Gerät" warten? Bis Mai 2013?
Oder werden die großen Geräte bereits ab jetzt in bereits in der Aufrüstung befindenden SuperComputer eingebaut, und auf dem freien Markt gibts dann die kleinen Geräte?

Ailuros

2012-10-16, 14:52:45

so macht macht das dann schon eher Sinn und passt besser zu den Erwartungen.
Die Frage ist dann aber auch: wie lange muss man dann noch auf das "große /vollständige/höher getaktete Gerät" warten? Bis Mai 2013?
Oder werden die großen Geräte bereits ab jetzt in bereits in der Aufrüstung befindenden SuperComputer eingebaut, und auf dem freien Markt gibts dann die kleinen Geräte?

Machen wir unser Leben einfach und sagen einfach dass sie diesmal zumindest den Stromverbrauch richtig hinbekommen haben :D

***edit: Antworten hab ich zu Deinen Fragen wohl leider noch nicht. Wenn nichts am Design selber krumm ist (wobei mir die 13SMX bzw. 320bit bus schon Angst machen) duerfte es in etwa so sein wie in Deinem letzten Satz.

Gipsel

2012-10-16, 15:04:22

kenn mich mit DGEMM nicht aus.

Ist mit dem Ziel 1TFLOP DGEMM Rpeak oder Rmax gemeint?Na R_max natürlich (R_peak ist die theoretische Peakleistung).
zum Vergleich:
die 7970 (normale edition) scheint
Rpeak= 925
Rmax = 623
zu machen.Nette Fallstudie, aber suboptimaler Code für die Radeons. Die 6x6 Submatrizen pro Thread sind schlicht zu klein, da können die den Vorteil der deutlich größeren Registerfiles nicht ausspielen (man nimmt schon auf 64Bit x86er-CPUs größere :rolleyes:). Es gibt definitiv schnellere Codes für Radeons als das da.

Edit:
Auf das hier verlinken die sogar selber (http://gpgpu.org/2012/07/11/code-generator-for-fast-matrix-multiplication-in-opencl). Da erreichen ein paar Japaner auf einer HD7970 immerhin 848 GFlop/s (90% vom Peakwert). Und das ist sogar automatisch mit einem Codegenerator erzeugter Code, noch nicht mal mit Handtuning (wie man am SP-Resultat von "nur" 70% sieht, da hat mal jemand [prunedtree] im B3D-Forum schon zu HD4870er-Zeiten 90% geschafft, davon träumt man bisher auf nV-Karten).

Ailuros

2012-10-16, 16:17:48

Godmode

2012-10-16, 16:39:41

OT aber dank an imacmatician bei B3D weil ich auch oefters blind bin:

http://www.nvidia.com/content/PDF/kepler/Tesla_K10_BD-06280-001_v05.pdf

225W TDP fuer die Tesla K10 und ich sehe keinen turbo clock.

Interessant das K10 4GB pro GPU hat, GTX690 hingegen nur 2. Gerade für die GTX690 wären 4GB nett gewesen.

mczak

2012-10-16, 17:07:42

Ich finde vor allem das 320bit Speicherinterface sehr enttäuschend. Gegenüber der Konkurrenz liegt man bei der Speicherbandbreite meilenweit zurück.
Auch die theoretische Rechenleistung ist sehr vergleichbar (etwas mehr DP, etwas weniger SP), für so einen Riesenchip eher bescheiden. Aber ich denke Nvidia war nicht bereit über 225W TDP zu gehen (wenn ich mich nicht irre haben sämtliche Teslas bisher 225W TDP), da ist dann wohl die Energieeffizienz besser (die FirePro W9000 hat ja deutlich höhere TDP).

Skysnake

2012-10-16, 17:13:29

Also das 320Bit SI kann ich nicht wirklich glauben... Das macht nicht wirklich viel Sinn, und der Chip wäre wohl wirklich ziemlich misserabel, wenn man nicht mal das ganze SI zum laufen bekommt...

Coda

2012-10-16, 17:35:43

Ich finde vor allem das 320bit Speicherinterface sehr enttäuschend. Gegenüber der Konkurrenz liegt man bei der Speicherbandbreite meilenweit zurück.
Was heißt hier "meilenweit"? Da kommt es doch zumindest noch auf den Takt an. Und selbst bei gleichem Takt sind das nur 17% weniger.

Gipsel

2012-10-16, 17:36:34

Welche Konkurrenz?
Xeon Phi mit 512 Bit GDDR5 Interface (der zudem noch 31MB L2 Cache hat statt nur 1,5MB wie GK110).

Coda

2012-10-16, 17:37:00

Wusst ich gar nicht, dass das Ding so breit ist beim SI.

Skysnake

2012-10-16, 17:50:24

OH doch, das SI ist richtig fett :D

Gipsel

2012-10-16, 17:51:14

Intel klotzt halt genau wie nV, oder gar noch mehr. Mit dem Die gehen sie an die Grenzen (dürften an die 600mm² sein, was Genaues weiß man offiziell nicht) und das in 22nm. Das wäre ja beinahe armselig, wenn Intel trotz der vermutlich geringeren Energieeffizienz in der Metrik (single precision) Flops/W nicht irgendwo auftrumpfen könnten. Mit DP, hohen Bandbreitenanforderungen oder eher ungewöhnlichen Programmabläufen bzw. Datenflüssen wird das Ding schon ab und zu was reißen können im Vergleich zu GK110. NV wird da vermutlich auch mit ihrem CUDA 5/dynamic parallelism/HyperQ erstmal hinten dran sein. Ist nur die Frage ob Intel genügend Leute überzeugen kann. Aber die Tools und Compiler werden vermutlich recht gut werden, insofern habe ich da nicht wirklich Zweifel.

Ailuros

2012-10-16, 19:01:03

Hab ich das falsch in Erinnerung oder hat Phi nicht immer noch einen ringbus?

Hübie

2012-10-16, 19:08:00

Afaik intern für caches aber net wie damals R600 für (V)RAM. So langsam bin ich auch verunsichert wie das Märchen hier ausgeht.
Kann mal bitte jemand herunterrechnen wie groß/klein ein P54C-Core in 22nm wäre? Am smartphone (trotz 4,3" tft) ists mir zu fummelig. Packdichte kann man ja recherchieren ;D Wäre nett...

mczak

2012-10-16, 19:14:44

Was heißt hier "meilenweit"? Da kommt es doch zumindest noch auf den Takt an. Und selbst bei gleichem Takt sind das nur 17% weniger.
Das ist richtig aber die FirePro W9000 hat auch noch höheren Speichertakt. Die W9000 hat da also 31% mehr Speicherbandbreite (bzw. die K20 25% weniger), das ist schon relativ viel Unterschied. Ganz abgesehen vom Xeon Phi der dann wohl so 60-80% mehr Speicherbandbreite hat.

Hübie

2012-10-16, 19:26:56

Gipsel

2012-10-16, 19:30:06

Bandbreite allein machts aber nicht. Wenn du optimale data-movements hast kannst du gern ma etwas beim SI sparen. Das gilt für HPC natürlich nur bedingt, da du hier ein sehr hetherogenes Anwendungsfeld hast.Aber da hat der Xeon Phi vermutlich eben auch einen massiven Vorteil mit 31 MB L2-Cache (nutzbar, verbaut sind 32 MB) gegen 1,5 MB bei GK110 (bzw. nur 1,25 MB bei der Version mit 320 Bit-Interface).

Edit:
Afaik intern für caches aber net wie damals R600 für (V)RAM. So langsam bin ich auch verunsichert wie das Märchen hier ausgeht.
Kann mal bitte jemand herunterrechnen wie groß/klein ein P54C-Core in 22nm wäre? Am smartphone (trotz 4,3" tft) ists mir zu fummelig. Packdichte kann man ja recherchieren ;D Wäre nett...
Na die RAM-Controller hängen ja erst hinter dem Cache. Der riesige Ringbus von KnightsCorner (2x1024Bit, der ist auch noch in 4 Teilabschnitte segmentiert, es werden also jeweils Tiles von 16 Kernen und zwei 64Bit Speichercontrollern durch ein Doppelringbus-Segment verbunden, das verringert die Anzahl der Kollisionen auf dem Ring), der die L2-Segmente verbindet, übernimmt schlicht zum Teil die Aufgabe der Crossbar, die bei AMD und nV zwischen den CUs/SMs und den ROPs/L2/Speichercontroller-Segmenten sitzt (bei Tahiti gibt es sogar 2 Crossbars, eine zwischen den CUs und den L2/ROP-Partitionen und dann noch einen [nicht voll verschaltet!] zwischen ROP-Partitionen und Speichercontrollern). Der Rest ist dann nur noch Routing zwischen den 4 Segmenten des Ringbusses.

Und zur Größe des P54C:
Dir ist schon klar, daß vielleicht der reine x86-Befehlssatz recht ähnlich ist und so ein paar Grundfeatures übereinstimmen (in-order dual issue), aber die eigentliche Implementation schon vollkommen anders aussieht? Das dürfte nur schwer zu vergleichen sein (die KnightsCorner-Kerne benötigen wohl auch ohne die Vektor-Einheit deutlich mehr Transistoren). Vermutlich ist das Ding irgendwas zwischen dem alten P54C und einem Atom-Kern + X.

Hübie

2012-10-16, 19:38:28

Das in jedem Fall ;D 31 MB sind vor allem nicht billig. Ob da auch Fehler korrigiert werden (können)? Fühl mich echt nackig ohne meinen PC ;D

Ailuros

2012-10-16, 19:47:55

NV hat mit dem perf/W fett geworben fuer Kepler, ergo steht erstmal ein zu hoher Stromverbrauch ausser Frage. Gegen Xeon Phi ist es zumindest ein sehr wichtiger Vorteil.

Afaik intern für caches aber net wie damals R600 für (V)RAM. So langsam bin ich auch verunsichert wie das Märchen hier ausgeht.
Kann mal bitte jemand herunterrechnen wie groß/klein ein P54C-Core in 22nm wäre? Am smartphone (trotz 4,3" tft) ists mir zu fummelig. Packdichte kann man ja recherchieren ;D Wäre nett...

Es sind 64 cores auf Knights Corner, davon 56 aktiv:

http://semiaccurate.com/2012/09/14/hard-numbers-for-knights-corner-leak-out/

Haswell hat wohl nichts mit LRB zu tun und es ist auch besser so :D

Gipsel

2012-10-16, 19:48:52

Das in jedem Fall ;D 31 MB sind vor allem nicht billig. Ob da auch Fehler korrigiert werden (können)? Fühl mich echt nackig ohne meinen PC ;DDaß der Xeon Phi überall ECC kann (also anders als der GK104 bzw. Tesla K10 auch in den Caches) darfst Du als sicher ansehen. Aber das trifft auf GK110 und auch Tahiti ebenfalls zu.
Oder wenn Du auf Redundanz raus willst. Die dürfte auch dabei sein. Dafür ein paar mehr cachelines zu verbauen ist recht billig. Und wenn intel etwas kann, dann sind das Caches (die ersten funktionellen Testchips [also die wirklich zu etwas Nutze sind] auf einem neuen Prozeß sind bei intel üblicherweise riesige SRAM-Chips). ;)

Gipsel

2012-10-16, 19:57:47

Es sind 64 cores auf Knights Corner, davon 56 aktivJe nachdem welches Modell Du erwischst, kann das variieren (genau wie die Busbreite und die Speichermenge, es gibt auch Modelle mit 384Bit-Interface und 3/6 GB RAM). Maximal sind 62 Kerne aktiv.

Ailuros

2012-10-16, 20:03:37

Je nachdem welches Modell Du erwischst, kann das variieren (genau wie die Busbreite und die Speichermenge, es gibt auch Modelle mit 384Bit-Interface und 3/6 GB RAM). Maximal sind 62 Kerne aktiv.

Hat jetzt Charlie Daten von gleichen oder verschiedenen chips bekommen fuer seinen Artikel oben? Im ersten Fall sind die 58W Unterschied im idle status schon ziemlich gross.

Hübie

2012-10-16, 20:10:12

Ach so. Dann hab ich da was falsch abgespeichert. Mein Hirn vermeldete P54C-Kerne. Die wurden dann wohl nur genannt um sich des Umfangs bewusst zu werden.
Coda meinte mal dass ein oder mehrere Kerne dispater, thread-scheduling und PCU-Aufgaben übernehmen. Also selbst wenn 62 aktiv sind kannst du nicht alle zum Rechnen nehmen.
@Gipsel: Bedeutet das auch dass der Cache aufgeteilt wird?

So kein Bock mehr am smartphone zu tippen :mad:

Gipsel

2012-10-16, 20:33:23

Hat jetzt Charlie Daten von gleichen oder verschiedenen chips bekommen fuer seinen Artikel oben? Im ersten Fall sind die 58W Unterschied im idle status schon ziemlich gross.
Wenn das noch Vorserien-Modelle/Engineering-Samples sind, ist absolut unklar, wie das Binning erfolgt ist. Das muß nicht das Erscheinungsbild sein, was die Verkaufsmodelle am Ende zeigen. Eventuell laufen die beiden Karten mit deutlich anderer Spannung/Frequenz im idle, who knows?
Coda meinte mal dass ein oder mehrere Kerne dispater, thread-scheduling und PCU-Aufgaben übernehmen. Also selbst wenn 62 aktiv sind kannst du nicht alle zum Rechnen nehmen.Da weiß ich noch nicht so recht, ob ich Codas Meinung teilen sollte (er meinte mal, es sind alle 64 aktiv [im Maximalfall natürlich] und 2 übernehmen die OS-Aufgaben, so daß 62 zum Rechnen übrig bleiben). Habe keine Zeit und Lust, in der Intel-Doku und den Software-Packages rumzuwühlen, um das genau rauszukriegen.
Fakt ist, daß physikalisch 64 Kerne verbaut sind und CPUID (maximal) 62 Kerne meldet.
@Gipsel: Bedeutet das auch dass der Cache aufgeteilt wird?Der L2 besteht (wie auch bei anderen GPUs und auch CPUs) aus mehreren Partitionen bzw. Tiles. Bei GPUs gibt es jeweils eine L2-Tile pro ROP-Partition (GF100/110, Cayman, Barts, Pitcairn, Tahiti und vermutlich noch ein paar mehr 128 kB pro Partition, CapeVerde hat lustigerweise 256kB pro Partition, genau wie GK110). Bei KnightsCorner ist das etwas anders organisiert (eher so wie bei CPUs der gemeinsame L3-Cache) und es gibt 512kB pro Kern. Über den Ringbus kann aber ein Kern auch auf die anderen Tiles zugreifen, die Latenz ist eben nur ein wenig höher.

Edit:
Ich sehe gerade, daß dies hier der GK110-Thread ist, nicht der von Knights Corner. :rolleyes:

Ailuros

2012-10-16, 21:13:14

Bis etwas relevantes zu GK110 aufteicht ist Tesla K20 und dessen direkte Konkurrenten auch nicht unbedingt irrelevant. Nichtdestominder hilft es die Staerken und Schwaechen von K20 im Vergleich zur Konkurrenz zu verstehen.

Hübie

2012-10-16, 21:15:38

Edit:
Ich sehe gerade, daß dies hier der GK110-Thread ist, nicht der von Knights Corner. :rolleyes:

Haha. Reingelegt ;D
Danke für die Ausführungen. Ich muss mittlerweile jedes mal irgend ein blödes Dokument öffnen um noch mal nachzusehen wer wie was macht/benennt/designed.
Da ich momentan nackig (ohne PC, nicht kleidungslos) bin ist es besonders umständlich mitzureden. CapeVerde war HD7700 oder? Da muss wohl Bandbreite kompensiert werden, daher 256kb?

Gipsel

2012-10-16, 21:19:41

CapeVerde war HD7700 oder? Da muss wohl Bandbreite kompensiert werden, daher 256kb?Ja, das wird es sein.

HarryHirsch

2012-10-16, 22:25:07

so wie ich die sache sehe muss nur einer bandreite kompensieren.
die bei nvidia sind sogar so behindert und lassen den ganzen rechner abschmieren anstatt den vram (teilweise) zu leeren.
die kantenglättung ist btw auch der hammer! :freak:

Hübie

2012-10-17, 08:44:46

Du sprichst in Rätseln.

Mal drüber geschlafen. Was macht ein Hersteller wenn er jeden Mist loswerden will? Er stuft die Produktpalette feiner ab. Da ich neulich noch las, dass nVidia die Zusatzbezeichnung Ultra wieder aufleben lassen will könnte man sich auch eine GTX 780 Ultra mit selektierten Chips @14/15 SMX denken. Die mit 13 wandern ins HPC-Segment. Dann GK112 aka GTX 780 und dann halt GK114 aka GTX 770. Das wär ebenso ein Szenario welches ich mir denken könnte. Vermutlich mindert man so ja die Verluste, oder etwa nicht? Wieso zahlt man eigtl. pro Wafer?? Dann hegt TSMC doch ein geringeres Interesse an der Optimierung oder nicht? Oder zahlt man prozentual/gestaffelt nach Anz. funktionierender Chips pro Wafer??

Das war mein morgentlicher Hirnschmalz zum Thema :D

Dural

2012-10-17, 09:24:56

habe ich generell eh nie genau verstanden wie so die GPU hersteller nicht mehr abstufungen auf den markt hauen.

die CPU hersteller machen es ja vor mit 10-20 verschidenen versionen des selben Die. eventuell ist die selektierung bei einer GPU zu aufwändig und die stückzahlen zu gering so das mehrere abstufungen nicht rentabel sind?

gnahr

2012-10-17, 09:32:28

gpus sind viel kurzlebiger durch den standardisierten sockel.
gpus werden refreshed meißt nach nicht mal nem jahr. die konkurrenz wirft nebelkerzen und relaunched ihre serien mit anderer taktung... es lohnt sich einfach nicht. und wenn es doch mal jemand macht kommen die maulwüfe aus ihren löchern und lästern los "gtx466? 460ti? 460 ultra? blickt doch kein schwein durch" oder "die 250 ist ne relabelte 8800 und 9800!!! das ist betruuuuuuuhg!!!" obwohl beide sachen völlig schwachsinnige nörgelei war.
immerhin werden aus einem chip immer 3-5 modelle geschnitten. das muss reichen.

wichtigen topic-bezug vergessen: das aus nem gk110 nur eine karte wird ist ja auch nicht der fall, aber mehr als 2-3 modele lohnen sich nicht, dafür gibts die aibs die eben übertaktungen auflegen und so weiter. das hast du bei den cpus ja nicht.

Gipsel

2012-10-17, 10:08:57

das aus nem gk110 nur eine karte wird ist ja auch nicht der fall, aber mehr als 2-3 modele lohnen sich nicht, dafür gibts die aibs die eben übertaktungen auflegen und so weiter. das hast du bei den cpus ja nicht.GK110 wird man wohl in 3 Tesla-Varianten, vermutlich mindestens ebenso vielen Quadros (bei GF100/110 wurde die halbe Produktlinie damit bestritten bis hinunter zu nur noch 8 SMs) und dann noch wahrscheinlich 2 Desktop-Varianten finden können. Reicht das nicht?

Hübie

2012-10-17, 10:09:29

Na doch. ARM-CPUs ;D Okay Haarspalterei.
Den AIBs werden da aber auch klare Richtlinien vorgegeben. Na ja dennoch halte ich meine Theorie für nicht sehr abwegig. GK112 könnte auch eine stellvertretende Bezeichnung für einen miesen GK110 sein...also nicht zwangsläufig ein "eigener" Chip.

Gipsel

2012-10-17, 10:10:44

Habe ich was verpaßt? Wo kommt denn das GK112-Gerücht her?

Dural

2012-10-17, 10:13:41

Godmode

2012-10-17, 10:20:09

aber die Tesla karte mit den daten macht schon etwas angst... zum glück hab ich ne GTX690 gekauft :freak:

Genau das denke ich mir auch. Habe echt kurz überlegt zu warten, aber dann hats doch zu sehr gejuckt.

Hübie

2012-10-17, 10:26:48

Habe ich was verpaßt? Wo kommt denn das GK112-Gerücht her?

Hab ich doch gesagt: ist ein von mir erdachtest Szenario. Basiernd auf eine Bild bei SA (ja ich weiß :D) wo ein unkenntlich gemachter GK11x Chip zu sehen war welcher angeeeeeblich keine 0 am Ende hat.
Ich habe gerade viel Zeit, denke nach und will euch an den Gedanken beteiligen um zu spekulieren. Sonst wirds schnell öde ;D
Nicht mehr und nicht weniger steckt dahinter.

Skysnake

2012-10-17, 10:28:25

naja denke nicht das GK110 "mies" ist, viel mehr dürfte mal wieder die fertigung die meisten probleme verursachen.

aber die Tesla karte mit den daten macht schon etwas angst... zum glück hab ich ne GTX690 gekauft :freak:
Wenn man die Fertigung aber auch bis zum Anschlag ausreizt, muss man sich auch nicht wundern, wenn es probleme gibt...

Sorry, wer solche Monsterchips plant, der muss sich dessen auch bewusst sein und mit den Folgen leben, oder es lieber sein lassen...

AnarchX

2012-10-17, 10:31:34

Die aktuelle Tesla K20 ist wohl aber näher am Ziel, als es die GF100 Tesla war.

Wie weit könnte eigentlich ein GK114 davon profitieren, wenn man seine Registergröße und den L2-Cache auf GK110-Maßstab erhöht?

Gipsel

2012-10-17, 10:38:20

Wie weit könnte eigentlich ein GK114 davon profitieren, wenn man seine Registergröße und den L2-Cache auf GK110-Maßstab erhöht?Ohne jetzt noch mal nachgeschaut zu haben, aber wird die Registergröße (pro SMx) überhaupt angehoben? Ich dachte, nV ändert nur die ISA so, daß ein Thread/warp mehr Register nutzen kann (die Breite der instruction encoding Felder für die Register geht von 6 bit auf 8 bit hoch, also statt 63 können jetzt 255 Register genutzt werden), auf Kosten der Anzahl gleichzeitig laufender Threads. Das ist die relativ billige Kompromißlösung. Das einzige was hochgeht ist der Cache pro ROP-Partition. Wobei 256 kB (insgesamt 1,5 MB) auch nicht soo üppig ist.

Edit:
Nach nachschauen: ja, genau so ist es.

http://www.abload.de/img/kepler_computei9uow.png

Hübie

2012-10-17, 10:44:59

Afaik nicht. Die ratio bleibt gleich. Insgesamt natürlich mehr cores+mehr cache.
@skysnake: Wie es aussieht hat nVidia allgemein mehr Probs mit der Fertigung bzw. den yields. Oder täuscht das Bild??

Skysnake

2012-10-17, 11:04:44

Das kann man so nicht sagen. AMD und nVidia haben halt unterschiedliche Designs. Was aber halt zutreffend ist, ist das nVidia allgemein die Grenzen eher auslotet als AMD. Zudem scheinen bei AMD auch einige Jungs zu sitzen, die ein echt gutes Gespür dafür zu haben scheinen, was geht, und was nicht. Ob nVidia jetzt die Grenzen zu oft auslotet, Sie überschreitet, oder Designprobleme hat, das können die nur die Leute bei nVidia sagen.

Ich würde daher sagen, Sie haben allgemein eigentlich nicht mehr Probleme als andere, nur Sie "über"treiben es halt immer, und haben daher immer mehr Probleme als die anderen. Das sind dann aber halt Designentscheidungen.

@Gipsel:
Ja, die SMX verändern sich bzgl. der Registerfiles/Caches nicht. Das ist ja auch mit einer der Kritikpunkte an Kepler. Man hat effektiv weniger Register/Caches pro ALU pro SM(X). Dafür wird halt der L2 massiv aufgebohrt...

Der Anstieg bei den Registern ist wohl auch eher vernachlässigbar. Gibt wohl relativ gesehen wenig Code, der daraus einen Profit zieht.

Was auch sehr lustig ist, ist, das man jetzt die 32kB Configuration wählen kann beim L1/SharedMemory. Das ging wohl schon mit GF1x0, wurde aber wieder deaktiviert ;D

War sehr lustig, als ich mal mit jemand über GF100 geredet habe, und ansprach dass das mit dem konfigurierbaren SharedMemory ja ganz nett ist. Da fiel der aus allen Wolken, dass die 32/32er Configuration nicht mehr geht ;D

Gipsel

2012-10-17, 11:11:46

Ja, die SMX verändern sich bzgl. der Registerfiles/Caches nicht. Das ist ja auch mit einer der Kritikpunkte an Kepler. Man hat effektiv weniger Register/Caches pro ALU pro SM(X). Dafür wird halt der L2 massiv aufgebohrt...Die reine Verdopplung von mickrigen 768 kB auf immer noch nicht berauschende 1,5 MB ergibt aber allerhöchstens mit der Bandbreitenverdopplung ein "massives Aufbohren". Das wird aber meiner Meinung auch wegen dem grob doppelt so breiten Chip erfordert.
Der Anstieg bei den Registern ist wohl auch eher vernachlässigbar. Gibt wohl relativ gesehen wenig Code, der daraus einen Profit zieht.*hust*DGEMM*hust* ;)

Coda

2012-10-17, 11:21:28

War sehr lustig, als ich mal mit jemand über GF100 geredet habe, und ansprach dass das mit dem konfigurierbaren SharedMemory ja ganz nett ist. Da fiel der aus allen Wolken, dass die 32/32er Configuration nicht mehr geht ;D
Was nicht mehr geht? Vor Fermi gab's 16KiB shared memory und keinen L1-Cache.

Gipsel

2012-10-17, 11:32:03

Was nicht mehr geht? Vor Fermi gab's 16KiB shared memory und keinen L1-Cache.
Und bei Fermi hast Du einen 16/48 oder 48/16 Split zwischen shared memory und L1, 32/32 geht nur mit Kepler. Skysnake meinte, das ging anfangs auch bei Fermi (komischerweise glaube ich mich daran zu erinnern, daß schon im GF100 compute whitepaper nur die 16/48 und 48/16 Splits standen).

Hübie

2012-10-17, 11:51:12

Ist das denn in der Tat so wichtig?

Skysnake

2012-10-17, 12:14:03

In DGEMM sollte dir das rein gar nichts nützen, da man ja erstmal genug Threads haben muss, um die Latenzen zu überbrücken. Da sind nicht die Register/Thread das Problem, sondern die Register/SM(X). Zumindest hatte ich damit nie ein Problem.

EDIT:
Jaein. Es ist halt manchmal ganz nützlich, da es eben besser zum eigenen Problem passt. Im allgemeinen aber eher uninteressant. Ist halt ne Stellschraube mehr, die einem helfen kann den Code zu optimieren.

@Gipsel: War wohl bei den ES möglich. :ka: Bin darauf aber nicht näher eingegangen. Derjenige meinte aber, er hätte auch 32/32 gesehen/genutzt.

Gipsel

2012-10-17, 14:27:41

In DGEMM sollte dir das rein gar nichts nützen, da man ja erstmal genug Threads haben muss, um die Latenzen zu überbrücken. Da sind nicht die Register/Thread das Problem, sondern die Register/SM(X).Es verringert auch absolut die Anzahl der L1- bzw. allgemein der Speicherzugriffe, selbst bei gleicher Anzahl der Register/SMx, weil eine häufigere Wiederbenutzung der Werte in den Registern stattfinden kann.

Und nur mal so als Beispiel, die Variante von prunedtree (die ziemlich genau 1 TFlop/s in SP auf einer HD4870 schafft, SP ist übrigens fordernder für die Hardware, da 4x bis 5x soviel gerechnet wird, die Werte aber die Hälfte der Größe haben, sprich die Bandbreitenanforderung ist bei gleicher Effizienz mindestens doppelt so hoch) belegt 31 vec4 Register (124 skalare, geht mit nV-Karten vor GK110 schlicht nicht), die double precision Variante (88% Effizienz auf HD4870, 92% Effizienz auf Cypress) gar 41 vec4 register (entspricht also 164 skalaren). Bei der SP-Variante laufen genau 8 Wavefronts pro SIMD, bei der DP-Variante nur noch 6 Wavefronts. Die SP-Variante benötigt mehr Wavefronts, da es viel häufiger Fetches gibt und sonst die Latenzen des L1 durch die Rechnungen nicht versteckt werden können. Bei DP dauern die Rechnungen dagegen deutlich länger (niedrigerer Durchsatz, es steht mehr Bandbreite/Flop zur Verfügung!), so daß sich das Optimum zu weniger Wavefronts/SIMD verschiebt.

Nun ist GK110 natürlich nicht vergleichbar, aber nur mal angenommen man läßt einen Code mit der gleichen Zahl von genutzten Registern auf GK110 los (ist auf anderen nV GPUs wie gesagt gar nicht möglich, da maximal 63 Register genutzt werden können), ergibt das (die DP-Variante) für einen SMx genau 12 parallel laufende Warps. Dabei werden in der inneren Schleife jeweils 128 Byte (was 16 DP-Werten entspricht) geladen, 64 FMAs ausgeführt und noch 4 Instruktionen für das Adresshandling/Schleife aufgewendet (auch sehr schön gruppiert, nix durcheinander). GK110 hat pro SMx 32 L/S-Einheiten und kann 64 DP-FMAs pro Takt ausführen. Interessanterweise entspricht das exakt dem Mix aus prunedtrees Code (16 DP-Werte = 32x 4Byte). Man ist also nicht fetch-limitiert (übrigens können ab GK110 die L/S-Einheiten sogar 64Bit fetches mit vollem Durchsatz, da hat man also jetzt sogar Reserve), sondern lastet ALUs und Fetch gleichermaßen aus. Bremsen kann jetzt nur noch die Latenz des L1- bzw. Speicherzugriffs. Wieviele Zyklen kann man sich da erlauben? 12 Warps heißen nur 3 pro Scheduler (also insgesamt 96 work items in OpenCL Terminologie). An jedem Scheduler stehen aber auch nur 16 DP-FMAs pro Takt Ausführungskapazitäten zur Verfügung, 3*32*64/16 sind also maximal 384 Takte Toleranz (realistischerweise sind es eher nur 256). Sollte eigentlich reichen (HD4870 hat ~180 Takte Textur-L1 Latenz, ab Cypress angeblich etwas schneller, der GP-L1 von Fermi/Kepler sollte wie auch shared memory niedriger liegen, da der Zugriff einfacher ist als bei Textur-Caches, sollte irgendwas um bzw. unter 30 Takten sein, allerdings werden auch normale Buffer [nicht nur Texturen] ab Kepler über den Textur-read-only Cache geladen, wenn sie als read-only deklariert sind, erhöht die zur Verfügung stehende Bandbreite [insbesondere bei irregulären Zugriffsmustern] auf Kosten der Latenz).

Hübie

2012-10-17, 14:52:33

Ist ein fetch nicht nur ein Lesezugriff, also nur eine Richtung? Vllt. dumme Frage aber mit DGEMM etc. kenn ich mich nicht aus ;D

Übrigens fällt mir mal wieder dieser Begriff-wirr-warr auf. Wavefront und warps müssen doch auch eine offizielle technische Bezeichnung haben oder? Intel hatte dafür auch einen eigenen Namen, der mir gerade entfallen ist ;)

Coda

2012-10-17, 15:03:07

CUDA: Warp
AMD Stream: Wavefront
OpenCL: Work Group
DirectCompute: Thread Group

Alles das selbe.

Gipsel

2012-10-17, 15:09:13

Ist ein fetch nicht nur ein Lesezugriff, also nur eine Richtung? Vllt. dumme Frage aber mit DGEMM etc. kenn ich mich nicht aus ;DUnd genau das brauchst Du dort auch am meisten. Schreibzugriffe gibt es im Vergleich recht wenige.
Übrigens fällt mir mal wieder dieser Begriff-wirr-warr auf. Wavefront und warps müssen doch auch eine offizielle technische Bezeichnung haben oder? Intel hatte dafür auch einen eigenen Namen, der mir gerade entfallen ist ;)Ja, Warps/Wavefronts sind die Threads der Hardware, die auf einer multithreaded Vektor- bzw. SIMD-Architektur ausgeführt werden, wenn man es in der allgemeinen und eigentlich jahrzehntelang akzeptierten Terminologie ausdrückt. Die Begriffe kommen von einer bildlichen Metapher, wie die Dinger auf den ersten Shaderarchitekturen ausgeführt wurden.
Dummerweise kollidiert das mit den Begriffen, die sich nV für ihren GPGPU-Ansatz ausgedacht hat. Dort wird als Thread etwas Anderes bezeichnet. Momentan wird ein "CUDA-Thread" schlicht durch eine feste Zuordnung zu einer Vektor-Lane der Ausführungseinheiten gebildet, es beschreibt, was mit einem Datenelement in dieser Lane passiert. OpenCL hat diese Kollision vermieden und nennt es schlicht "work item". Allerdings abstrahiert OpenCL die Hardware-Threads ziemlich weg, am nähesten kommen dort die "work groups" (die allerdings allgemeiner sind, nämlich praktisch eine Gruppe von Hardware-Threads mit einer Minimalzahl von einem Mitglied).

Gipsel

2012-10-17, 15:15:50

CUDA: Warp
AMD Stream: Wavefront
OpenCL: Work Group
DirectCompute: Thread Group

Alles das selbe.
Intel hatte mit Larrabee anfangs (als es noch eine GPU werden sollte) auch eine eigene Terminologie. Da gab es "strands" (OpenCL work item, CUDA thread), "threads" (das waren die wirklichen Hardware-Threads, also äquivalent zu Warp/Wavefront) und noch "fibers" (OpenCL work group, DirectCompute thread group, also eine Gruppe von Threads). Und das Ganze konnte dann "braided parallelism" :freak:. Offensichtlich braucht jede GPU eine eigene Terminologie. :rolleyes:

Skysnake

2012-10-17, 17:37:01

Es verringert auch absolut die Anzahl der L1- bzw. allgemein der Speicherzugriffe, selbst bei gleicher Anzahl der Register/SMx, weil eine häufigere Wiederbenutzung der Werte in den Registern stattfinden kann.

Ich weiß grad nicht was du genau meinst, aber mehr Register reduzieren natürlich die Anzahl an Zugriffen, soweit man Sie denn ausnutzen kann. Man bekommt aber nicht durch mehr Thread unbedingt eine höheren Datenreuse. Aber das ist kompliziert :ugly: Ich hoffe wir kommen gleich auf einen grünen Zweig.

Und nur mal so als Beispiel, die Variante von prunedtree (die ziemlich genau 1 TFlop/s in SP auf einer HD4870 schafft, SP ist übrigens fordernder für die Hardware, da 4x bis 5x soviel gerechnet wird, die Werte aber die Hälfte der Größe haben, sprich die Bandbreitenanforderung ist bei gleicher Effizienz mindestens doppelt so hoch)

na, das stimmt so allgemein nicht wirklich.

Du hast immer bei einer AxB=C mit C:= nxn Matrix n²*(2n-1) Rechenoperationen auszuführen (ohne FMA/MAD usw)

Dafür braucht man, sofern man keine slizes verwendet, und auch kein Caching verwendet insgesamt n²*(4n-1) Reads und Writes n²*(2n-1) writes. Also alles, wenn man kein Caching und kein FMA/MAD macht. :ugly: (puh wat ein brainfuck :freak:)

Jetzt wirds dann lustig. Mit MAD spart man sich halt direkt mal n²*(n-1) Writes ,da man ja A*B + C = D macht. A*B sind klarerweise die Multiplikationen, und C die alte Teilsumme, und D die neue Teilsumme.

Sodele, und jetzt wirds lustig. Man kann ja tiles/slizes verwendet. Man macht also ein preload einer mxm Teilmatrix, auf der man partiell das Ergebnis ausrechnet. Wichtig hierbei ist, dass die Teilmatrix mxm für A und B jeweils ist. Man tauscht dann im Optimalfall nur B durch, da man pro Zeile nur jeweils eine Work Groupe hat! Ansonsten kann man A nicht stehen lassen.

Damit erhöht sich der Datenreuse und zwar in Abhängigkeit von m. Also jeder Eintrag in der Teilmatrix von B wird m mal reused, bevor man ihn austauschen muss. Gleichzeitig wird aber jeder Eintrag in der Teilmatrix von A n mal reused, wenn ich es richtig im Kopf habe. Man kommt also auf einen Datenreuse von (n+m)*m*m/(m*n), wenn ich mich gerade nicht verhaspele.

Das ist jetzt nur mit MAD und Shared Memory/L1. Man muss nämlich die Teilmatrizen A und B in den shared packen, wenn ich mich recht erinnere, damit man wahlfreien zugriff hat, kann aber auch sein, das man eine Teilmatrix in den L1 packen kann. B z.B. Die Ergebnismatrix packt man als Teilmatrix mxm natürlich in die Register. (Ich glaub das habe ich nie gemacht, sondern im shared memory ne Ergebnismatrix angelegt.... Ist eigentlich nicht sooo toll glaube ich.)

Dann kann man die ganze Sache nochmal auf Slizes/tiles in L2 größe hoch ziehen, wenn einem danach ist. Hier ist man ja schon ca von 10 Zeilen Code hoch auf >100 Zeilen Code :ugly:

Auf jeden Fall sollte man bereits mit GF100 nicht zu viele Register/Thread brauchen, als das einem die Neuerung mit den 255 Registern etwas helfen würde... Eher im Gegenteil. Man wird jetzt schlechter Weg kommen, weil man weniger Shared/L1 hat für mehr Thread, also die Teilmatrizen nicht größer wählen kann. Kurz um, es bringt einem nicht wirklich was, es sei denn man fängt mit den übelsten Verrenkungen an, aber das wird wirklich nicht mehr lustig...

belegt 31 vec4 Register (124 skalare, geht mit nV-Karten vor GK110 schlicht nicht), die double precision Variante (88% Effizienz auf HD4870, 92% Effizienz auf Cypress) gar 41 vec4 register (entspricht also 164 skalaren). Bei der SP-Variante laufen genau 8 Wavefronts pro SIMD, bei der DP-Variante nur noch 6 Wavefronts. Die SP-Variante benötigt mehr Wavefronts, da es viel häufiger Fetches gibt und sonst die Latenzen des L1 durch die Rechnungen nicht versteckt werden können. Bei DP dauern die Rechnungen dagegen deutlich länger (niedrigerer Durchsatz, es steht mehr Bandbreite/Flop zur Verfügung!), so daß sich das Optimum zu weniger Wavefronts/SIMD verschiebt.

Das liegt aber einzig und allein der DP:SP Ratio, und hat mit der DGEMM<-> SGEMM erst mal nicht viel zu tun. Wie oben schon gesagt, man hat immer n²*(2n-1) Rechenoperationen und <n²*(4n-1) Reads + n²*(2n-1) Writes auf dem RAM!, wobei diese eben durch Caching usw reduziert werden können. Und da kommen wir zum springenden Punkt. Alle aktuellen GPUs waren durch das SI limietiert bei DGEMM, da man schlicht nicht genug Datenreuse (grob n*m) hinbekommen hat, um das SI nicht zu überlasen. Mit SGEMM hat man halt weniger das problem, da der DAtenreuse ansteigt. Dafür steigt eben auch die Rechenleistung an, da man kein SP:DP von 1:1 hat. Die Effizienz steigt daher wenn ich mich recht erinnere zwar an, aber nicht über alle maßen, und das SI limitiert allgemein noch immer.

Und genau das ist doch der Knackpunkt. Auf dem Chip hat man genug Bandbreite, wenn man die Daten oft genug wiederverwenden kann (wozu man große Caches braucht/behilflich sind). Schafft man das nicht, nippelt man am SI. nVidia hat aber die Rechenleistung gesteigert, ohne die Caches L1/SharedMemory zu steigern, daher verpufft einiges. Auf der anderen Seite haben Sie den L2 verdoppelt, der ja ALLE! Zugriffe auf den RAM abfängt, und nicht nur die des jeweiligen SM(X). Sofern ich den also nutze, ist der Datenreuse durch den größeren L2 also ein vielfaches als durch den L1/shared, weil man ja die Teilmatrizen der einzelnen SM(X) nciht aus dem RAM holt, sondern aus dem L2.
Das Problem an der Sache ist leider, das es schon anstrengend/aufwendig ist, den SharedMemory zu verwenden. Der L2 ist einfach nur noch die HÖLLE! :crazy: Das will man nicht wirklich machen, zumal einem der Code explodiert, da es eigentlich nur Sinn macht den L2 zu nutzen, wenn man den shared Memory nutzt -.-

Nun ist GK110 natürlich nicht vergleichbar, aber nur mal angenommen man läßt einen Code mit der gleichen Zahl von genutzten Registern auf GK110 los (ist auf anderen nV GPUs wie gesagt gar nicht möglich, da maximal 63 Register genutzt werden können),
Das ist doch aber der springende Punkt. Du hast im Normalfall gar keine limitierung dadurch, dass du "nur" 63 Register/Thread nutzen kannst, da du alternativ auch mehr Thread generieren kannst. Gerade bei DGEMM ist es, wenn ich mich nicht GANZ vertue absolut scheis egal, weil man pro Thread eh nur ein paar Register effektiv nutzt.

ergibt das (die DP-Variante) für einen SMx genau 12 parallel laufende Warps. Dabei werden in der inneren Schleife jeweils 128 Byte (was 16 DP-Werten entspricht) geladen, 64 FMAs ausgeführt und noch 4 Instruktionen für das Adresshandling/Schleife aufgewendet (auch sehr schön gruppiert, nix durcheinander). GK110 hat pro SMx 32 L/S-Einheiten und kann 64 DP-FMAs pro Takt ausführen. Interessanterweise entspricht das exakt dem Mix aus prunedtrees Code (16 DP-Werte = 32x 4Byte). Man ist also nicht fetch-limitiert (übrigens können ab GK110 die L/S-Einheiten sogar 64Bit fetches mit vollem Durchsatz, da hat man also jetzt sogar Reserve), sondern lastet ALUs und Fetch gleichermaßen aus. Bremsen kann jetzt nur noch die Latenz des L1- bzw. Speicherzugriffs. Wieviele Zyklen kann man sich da erlauben? 12 Warps heißen nur 3 pro Scheduler (also insgesamt 96 work items in OpenCL Terminologie).

Und genau das läuft eben dem entgegen, was du machen willst. Man muss die Latenzen ja noch verstecken, und eben genau dieses führt eben dazu, das man meist so viele Threads hat, das man eben gar nicht erst über 63 Register/Thread braucht, weil einem vorher irgend was anderes limitiert.

An jedem Scheduler stehen aber auch nur 16 DP-FMAs pro Takt Ausführungskapazitäten zur Verfügung, 3*32*64/16 sind also maximal 384 Takte Toleranz (realistischerweise sind es eher nur 256). Sollte eigentlich reichen (HD4870 hat ~180 Takte Textur-L1 Latenz, ab Cypress angeblich etwas schneller, der GP-L1 von Fermi/Kepler sollte wie auch shared memory niedriger liegen, da der Zugriff einfacher ist als bei Textur-Caches, sollte irgendwas um bzw. unter 30 Takten sein, allerdings werden auch normale Buffer [nicht nur Texturen] ab Kepler über den Textur-read-only Cache geladen, wenn sie als read-only deklariert sind, erhöht die zur Verfügung stehende Bandbreite [insbesondere bei irregulären Zugriffsmustern] auf Kosten der Latenz).
blub

Intel hatte mit Larrabee anfangs (als es noch eine GPU werden sollte) auch eine eigene Terminologie. Da gab es "strands" (OpenCL work item, CUDA thread), "threads" (das waren die wirklichen Hardware-Threads, also äquivalent zu Warp/Wavefront) und noch "fibers" (OpenCL work group, DirectCompute thread group, also eine Gruppe von Threads). Und das Ganze konnte dann "braided parallelism" :freak:. Offensichtlich braucht jede GPU eine eigene Terminologie. :rolleyes:
Fibres gibts noch immer ;D

Ailuros

2012-10-17, 18:16:25

Die Englaender sagen elevator anstatt lift womoeglich nur um Amis zu nerven :D

Skysnake

2012-10-17, 18:36:20

Ja, aber es nervt schon VERDAMMT.... Ich komm da auch nur noch durcheinander...

Bei Warps usw gehts ja noch. RICHTIG Kacke ist halt der "local" mem in CUDA<->OpenCL...

OpenCL "local" ist das Gleiche wie CUDA "sharedMemory"
CUDA "local" ist aber so was wie OpenCL global
:facepalm:

Echt toll sag ich dir, wenn du mit jemandem redest, der OpenCL und CUDA-Sprech miteinander vermischt -.-

Ailuros

2012-10-17, 18:55:29

Ich darf wohl copy/paste fuer meinen Brei aus einem anderem forum benutzten:

Another comparison would be GFLOPs/W:

GF100/2050/3GB = 515 GFLOPs DP@238W = 2.16 GFLOPs DP/W

K20/5GB = 1.17 GFLOPs DP@225W = 5.2 GFLOPs DP/W

5.2 / 2.16 = 2.4x times increase for GFLOPs/W

If you'd now do a hypothetical DGEMM achievable rates comparison:

2050 = 206 GFLOPs DGEMM @238W = 0.86 GFLOPs DP/W
2090 = 266 GFLOPs DGEMM @225W = 1.18 GFLOPs DP/W
K20 = 936 GFLOPs DGEMM @225W = 4.16 GFLOPs DP/W
----------------------------------------------------------------------

4.16 / 0.86 = 4.83x times
4.16 / 1.18 = 3.52x times

(note that for the DGEMM calculations I used NV's own claim that 20x0 have a 40% efficiency with DGEMM while K20 80%)

Das dumme ist eben dass wenn die 13SMX specs stimmen sollten, NV's ultra kreatives marketing nie gelogen hat als sie in der Vergangenheit behaupteten dass Kepler ueber 3x Mal so viel sustainable GFLOPs/W liefert.

Vorraussetzung naturlich dass die 936 GFLOPs DGEMM auch wirklich stimmen bzw. erreichbar sind wenn der K20 auch wirklich 13SMX/320bit sein wird. Muss ja auch nicht so viel sein; um marketingtechnisch korrekt zu sein reicht ein Faktor 3.01x Unterschied :wink:

Gipsel

2012-10-17, 20:38:23

Ich weiß grad nicht was du genau meinst, aber mehr Register reduzieren natürlich die Anzahl an Zugriffen, soweit man Sie denn ausnutzen kann. Man bekommt aber nicht durch mehr Thread unbedingt eine höheren Datenreuse.
[..]
Jetzt wirds dann lustig. Mit MAD spart man sich halt direkt mal n²*(n-1) Writes ,da man ja A*B + C = D macht. A*B sind klarerweise die Multiplikationen, und C die alte Teilsumme, und D die neue Teilsumme.

Na die Read/Writes in Register zähle ich nicht, die sind hoffentlich schnell genug. Wenn Du die Registerwrites beachten mußt, ist die ganze Architektur Schrott. Da sind wir aber gar nicht. Mir geht es erstmal nur um Zugriffe auf den L1. Und die Anzahl sinkt schlicht, wenn man größere Teilmatrizen in den Registern hält. Man kann einfach ausrechnen, wie viel Bandbreite man bei einem bestimmten Tiling benötigt, um eine gewisse Flop-Zahl zu erreichen. Und diese Zahl sinkt, je größer die in den Registern gehaltenen Teilmatrizen sind.
Sodele, und jetzt wirds lustig. Man kann ja tiles/slizes verwendet. Man macht also ein preload einer mxm Teilmatrix, auf der man partiell das Ergebnis ausrechnet.Rechteckig geht auch, prunedtrees Code benutzt z.B. ein 8x10 Slicing in single precision (in DP 8x8).

Man benötigt genau m+n loads für m*n FMAs.

Bei einem 8x4 Tiling (benötigt in SP minimal 48 skalare Register, das kann Fermi und GK104 also noch) hat man 12 loads und 32 FMAs, ins SP sind das also 48 Bytes für 32 FMAs. Die 32 FMAs sind allerdings in SP so schnell durch (sind alle unabhängig), daß man die 12 Fetches in der Zeit noch nicht fertig hat (Beispiel: Radeons können pro SIMD und Takt 64 FMAs [und ältere sogar 80 MADDs] aber nur 16 Fetches).
Mit 8x8 Tiling belegt man minimal 84 Skalarregister und hat ein Verhältnis von 16 Fetches pro 64 FMAs/MADDs. Die L1-Bandbreite limitiert also in SP mit 8x8 Tiling einen Cypress auf 64/80 der Peakperformance (bei 8x4 Tiling ist es gar nur 16/12*32/80 = 53%, also ~600 GFlop/s bei einer HD4870, das ist das, was das simple_matmult Beispiel im Stream-SDK macht bzw. gemacht hat ;)). Erst 8x10 Tiling hebt das auf ~89% an (wovon sich praktisch ~80% messen lassen).

Für DP sieht es so aus, daß maximal 4x5 Tiling in nVs Registerfiles passen würde (der Zugriff ist bei ungeraden Anzahlen [Zugriffe kleiner als 16 Bytes am Stück, deswegen ist in SP 8x4 auch schneller als 6x6] allerdings supoptimal, 4x4 ist vermutlich schneller). Bei 4x4 wären es 8 Loads und 16 FMAs. Acht 8 Byte-Loads und 16 DP-FMAs ist nun genau das, was Fermi (GF100/110) pro Takt können soll. Perfect Match, könnte man denken. Aber irgendwo klemmt es dann offensichtlich halt doch (ich vermute mal ganz stark, weil während ein DP-FMA abgesetzt wird, der zweite Scheduler komplett blockiert wird, also die Loads und die DP-Arithmetik nicht parallel durchs Issue laufen können, so sagt es zumindest das GF100 whitepaper). Das limitiert den Durchsatz dann auf 16 FMAs/ (8+16 Takte) = 2/3 der Peak-Leistung, genau das, was man sieht :D (nV benutzt allerdings bei CuBLAS noch einen etwas komplizierteren Ansatz als das hier dargestellte Tiling, im Peak kommen die damit wohl auf 68% oder so).
Wichtig hierbei ist, dass die Teilmatrix mxm für A und B jeweils ist. Man tauscht dann im Optimalfall nur B durch, da man pro Zeile nur jeweils eine Work Groupe hat! Ansonsten kann man A nicht stehen lassen.??? Wie hat eine workgroup nur eine Zeile?
Damit erhöht sich der Datenreuse und zwar in Abhängigkeit von m. Also jeder Eintrag in der Teilmatrix von B wird m mal reused, bevor man ihn austauschen muss. Gleichzeitig wird aber jeder Eintrag in der Teilmatrix von A n mal reused, wenn ich es richtig im Kopf habe. Man kommt also auf einen Datenreuse von (n+m)*m*m/(m*n), wenn ich mich gerade nicht verhaspele.Ich kapiere gerade nicht ganz, wie Du Tilen willst. Aber das Tiling funktioniert optimalerweise minimal anders, als man das zuerst annimmt. Zumindest ging es mir so.
Man lädt nicht die nxm und mxn Teilmatrizen aus A und B, berechnet dann daraus das mxm Produkt und schreibt das wieder in den Speicher (beschränken wir uns der Anschaulichkeit halber ab sofort auf quadratische m x m Tiles).
Ein einzelnes work item prozessiert jeweils die komplette Matrixgröße für Tiles aus mxm Werten (bei prunedtrees code also 8x8). Pro Schleifendurchlauf werden jeweils m Werte aus A gelesen und m Werte aus B und dann m² FMAs ausgeführt (alle Kombinationen der gerade gelesenen Werte aus A und B, für jeden Zwischenwert des mxm Tiles eins). Die Schleife iteriert über die komplette Matrixgröße. Man gleitet also über A und B-Matrizen. Damit benötigt man also für 2*m² Flops genau 2m Speicherzugriffe (+ das Schreiben der Werte ganz am Ende, aber der Aufwand geht relativ gesehen mit steigender Matrixgröße gegen Null). Die absolute Anzahl der Speicherzugriffe und die erforderliche Bandbreite geht also mit der Tilegröße runter (proportional zu 1/m). Benachbarte work items berechnen vorzugsweise benachbarte Tiles, so daß die im L1-Cache befindlichen Werte zeitnah von mehreren work-items geladen werden. Durch diese zweite Stufe des Data-Reuse wird die Bandbreite des L2 bereits unkritisch (selbst bei den mickrigen 8kB L1 bei Radeons vor Southern Islands!) und durch die hierarchische Anordnung der Tiles wird die letztendlich erforderliche und genutzte Speicherbandbreite schließlich locker beherrschbar. Die Caches wirken als "bandwidth amplifier", wenn man die Lokalität ausnutzt.
Das ist jetzt nur mit MAD und Shared Memory/L1. Man muss nämlich die Teilmatrizen A und B in den shared packen, wenn ich mich recht erinnere, damit man wahlfreien zugriff hat, kann aber auch sein, das man eine Teilmatrix in den L1 packen kann. B z.B. Die Ergebnismatrix packt man als Teilmatrix mxm natürlich in die Register. (Ich glaub das habe ich nie gemacht, sondern im shared memory ne Ergebnismatrix angelegt.... Ist eigentlich nicht sooo toll glaube ich.) Siehe oben. Man lädt gar keine vollständigen mxm Teilmatrizen von A und B sondern nur m Elemente von jedem pro Schleifendurchlauf. Das spart gegenüber dem "normalen" Tiling schlicht Platz, so daß man größere Tiles bei gleichem Registerverbrauch benutzen kann. ;)
Auf jeden Fall sollte man bereits mit GF100 nicht zu viele Register/Thread brauchen, als das einem die Neuerung mit den 255 Registern etwas helfen würde... Eher im Gegenteil. Man wird jetzt schlechter Weg kommen, weil man weniger Shared/L1 hat für mehr Thread, also die Teilmatrizen nicht größer wählen kann. Kurz um, es bringt einem nicht wirklich was, es sei denn man fängt mit den übelsten Verrenkungen an, aber das wird wirklich nicht mehr lustig...Ich stehe zu meiner Einschätzung oben, daß 12 Warps pro SM für so ein arithmetisch dichtes Problem ausreichend zum Verstecken der Latenzen ist. Und die Leute, die DGEMM kernel für irgendwelche Bibliotheken schreiben, gehen sicherlich nicht davon aus, das in 10 Zeilen hinzubekommen. ;)

Für die Rechnung C = A*B+D benötigt man mit dem beschriebenen 8x8 Tiling für nxn Matrizen exakt:
2 * n³ Fließkommaoperationen
n³/4 + n² Loads (die n² sind für die Addition von D)
n² Writes
Das macht ziemlich genau 1 Byte/Flop Bandbreite aus dem L1 für DP. Schau mal nach, wie viel man hat. ;)

Oder allgemein für mxm Tiling:
2 * n³ Fließkommaoperationen
2 * n³/m + n² Loads
n² Writes

Fermi (sowie GK104 und kleiner) war bisher auf recht kleine Tiles beschränkt (durch limitierten Registerspace), wodurch die Bandbreite des L1 (bzw. diese Issue-Beschränkung) der Flaschenhals war, nicht die Speicherbandbreite an sich. Größere Tiles, wie auf Radeons schon lange möglich, reduzieren die Bandbreitenanforderungen. Die Anzahl der gleichzeitig laufenden Warps/Wavefronts ist erst in zweiter Linie wichtig, insbesondere bei DP.
Das liegt aber einzig und allein der DP:SP Ratio, und hat mit der DGEMM<-> SGEMM erst mal nicht viel zu tun. Wie oben schon gesagt, man hat immer n²*(2n-1) Rechenoperationen und <n²*(4n-1) Reads + n²*(2n-1) Writes auf dem RAM!, wobei diese eben durch Caching usw reduziert werden können. Und da kommen wir zum springenden Punkt. Alle aktuellen GPUs waren durch das SI limietiert bei DGEMM, da man schlicht nicht genug Datenreuse (grob n*m) hinbekommen hat, um das SI nicht zu überlasen.Tiles in Registern verringern eben doch die Anzahl der Speicherzugriffe. Und solange die SP-Peak-Flops höher sind als das Doppelte der DP-Peak-Flops (also allen GPUs außer Fermi-Teslas), ist SP fordernder für die Hardware, da schlicht eine höhere Bandbreite erforderlich ist (und das kann man mit größeren Tiles nicht adäquat ausgleichen).
Mit SGEMM hat man halt weniger das problem, da der DAtenreuse ansteigt. Dafür steigt eben auch die Rechenleistung an, da man kein SP:DP von 1:1 hat. Die Effizienz steigt daher wenn ich mich recht erinnere zwar an, aber nicht über alle maßen, und das SI limitiert allgemein noch immer.Es limitiert sogar mehr (eher wieder die L1-Bandbreite). Die SGEMM-Effizienz ist bei GPUs üblicherweise niedriger als die DGEMM-Effizienz (z.B. bei Radeons ~80% versus ~90%, bei SP ist die L1-Bandbreite ein hartes Limit unter den Peak-Flops, in DP nicht, das ist vollkommen ALU-limitiert).
Und genau das ist doch der Knackpunkt. Auf dem Chip hat man genug Bandbreite, wenn man die Daten oft genug wiederverwenden kann (wozu man große Caches braucht/behilflich sind). Schafft man das nicht, nippelt man am SI. nVidia hat aber die Rechenleistung gesteigert, ohne die Caches L1/SharedMemory zu steigern, daher verpufft einiges. Auf der anderen Seite haben Sie den L2 verdoppelt, der ja ALLE! Zugriffe auf den RAM abfängt, und nicht nur die des jeweiligen SM(X). Sofern ich den also nutze, ist der Datenreuse durch den größeren L2 also ein vielfaches als durch den L1/shared, weil man ja die Teilmatrizen der einzelnen SM(X) nciht aus dem RAM holt, sondern aus dem L2.
Das Problem an der Sache ist leider, das es schon anstrengend/aufwendig ist, den SharedMemory zu verwenden. Der L2 ist einfach nur noch die HÖLLE! :crazy: Das will man nicht wirklich machen, zumal einem der Code explodiert, da es eigentlich nur Sinn macht den L2 zu nutzen, wenn man den shared Memory nutzt -.-Die Nutzung von shared memory ist eigentlich nur eine Krücke, um den fehlenden Registerplatz bei nV etwas auszugleichen. Für DGEMM benötigt man den im Prinzip überhaupt nicht, wenn man auf ein paar mehr Register zugreifen kann. Die Nutzung als L1 ist einfacher zu coden (man spart ja die expliziten Zugriffe) und funktioniert praktisch genau so gut wenn nicht besser, weil man im Zweifelsfall noch ein paar ALU-Cycles sparen kann.
Das ist doch aber der springende Punkt. Du hast im Normalfall gar keine limitierung dadurch, dass du "nur" 63 Register/Thread nutzen kannst, da du alternativ auch mehr Thread generieren kannst. Gerade bei DGEMM ist es, wenn ich mich nicht GANZ vertue absolut scheis egal, weil man pro Thread eh nur ein paar Register effektiv nutzt.

Und genau das läuft eben dem entgegen, was du machen willst. Man muss die Latenzen ja noch verstecken, und eben genau dieses führt eben dazu, das man meist so viele Threads hat, das man eben gar nicht erst über 63 Register/Thread braucht, weil einem vorher irgend was anderes limitiert.
Das stimmt eben nicht. Bei 8x8 Tiling im prunedtree style belegst Du 164 skalare Register (128 gehen ja schon für die 64 Zwischenwerte des 8x8 Tiles drauf + 32 für die 16 geladenen Werte aus A und B, bleiben nur noch 4 Register für den ganzen Overhead). Aber dafür benötigst Du verglichen mit einer naiven Implementation ohne Tiling auch nur noch ein Achtel der Speicherzugriffe/Bandbreite aus dem L1.
Tiles in den shared memory zu legen bringt übrigens nicht so viel bis gar nichts, weil die Bandbreite daraus auch nicht höher ist als aus dem L1 (ist bei nV doch das gleiche SRAM-Array), das muß zwingend in die Register, um von der deutlich höheren und ausreichenden Bandbreite dort zu profitieren. Mehr Threads helfen nur gegen Latenzen, aber nicht dagegen, daß man längst im Bandbreitenlimit des L1 hängt.

Die Devise ist also: weniger L1-Zugriffe => mehr Register genutzt => weniger Threads => höhere Performance

Und wie oben vorgerechnet reichen selbst 12 Warps pro SMx noch, um über 200 bis 300 Takte Latenz zu verstecken, wenn da immer massive Blöcke von 64 DP-FMAs vorkommen (wie das bei 8x8 Tiling nunmal ist). That's the way to go. ;)

Edit:
Falls Du prunedtrees code nicht kennst, hier das Wesentliche in Cypress-ISA:

05 LOOP_DX10 i0 FAIL_JUMP_ADDR(12)
06 ALU_BREAK: ADDR(234) CNT(4) KCACHE0(CB0:0-15)
37 x: ADD R16.x, KC0[0].y, R16.x
y: ADD R16.y, KC0[0].y, R16.y
z: ADD R16.z, R16.z, 1.0f
38 x: PREDGT ____, KC0[0].x, R16.z UPDATE_EXEC_MASK UPDATE_PRED
07 TEX: ADDR(596) CNT(8)
39 SAMPLE R0, R16.xz0x, t0, s0 UNNORM(XYZW)
40 SAMPLE R1, R16.xz0x, t1, s1 UNNORM(XYZW)
41 SAMPLE R2, R16.xz0x, t2, s2 UNNORM(XYZW)
42 SAMPLE R6, R16.xz0x, t3, s3 UNNORM(XYZW)
43 SAMPLE R3, R16.yz0y, t4, s4 UNNORM(XYZW)
44 SAMPLE R4, R16.yz0y, t5, s5 UNNORM(XYZW)
45 SAMPLE R5, R16.yz0y, t6, s6 UNNORM(XYZW)
46 SAMPLE R7, R16.yz0y, t7, s7 UNNORM(XYZW)
08 ALU: ADDR(238) CNT(124)
47 x: FMA_64 R18.x, R0.y, R3.y, R18.y
y: FMA_64 R18.y, R0.y, R3.y, R18.y
z: FMA_64 R123.z, R0.y, R3.y, R18.y
w: FMA_64 R123.w, R0.x, R3.x, R18.x
48 x: FMA_64 R123.x, R0.y, R3.w, R18.w
y: FMA_64 R123.y, R0.y, R3.w, R18.w
z: FMA_64 R18.z, R0.y, R3.w, R18.w
w: FMA_64 R18.w, R0.x, R3.z, R18.z
49 x: FMA_64 R20.x, R0.y, R4.y, R20.y
y: FMA_64 R20.y, R0.y, R4.y, R20.y
z: FMA_64 R123.z, R0.y, R4.y, R20.y
w: FMA_64 R123.w, R0.x, R4.x, R20.x
50 x: FMA_64 R123.x, R0.y, R4.w, R20.w
y: FMA_64 R123.y, R0.y, R4.w, R20.w
z: FMA_64 R20.z, R0.y, R4.w, R20.w
w: FMA_64 R20.w, R0.x, R4.z, R20.z
51 x: FMA_64 R22.x, R0.y, R5.y, R22.y
y: FMA_64 R22.y, R0.y, R5.y, R22.y
z: FMA_64 R123.z, R0.y, R5.y, R22.y
w: FMA_64 R123.w, R0.x, R5.x, R22.x
52 x: FMA_64 R123.x, R0.y, R5.w, R22.w
y: FMA_64 R123.y, R0.y, R5.w, R22.w
z: FMA_64 R22.z, R0.y, R5.w, R22.w
w: FMA_64 R22.w, R0.x, R5.z, R22.z
53 x: FMA_64 R24.x, R0.y, R7.y, R24.y
y: FMA_64 R24.y, R0.y, R7.y, R24.y
z: FMA_64 R123.z, R0.y, R7.y, R24.y
w: FMA_64 R123.w, R0.x, R7.x, R24.x
54 x: FMA_64 R123.x, R0.y, R7.w, R24.w
y: FMA_64 R123.y, R0.y, R7.w, R24.w
z: FMA_64 R24.z, R0.y, R7.w, R24.w
w: FMA_64 R24.w, R0.x, R7.z, R24.z
55 x: FMA_64 R38.x, R0.w, R3.y, R38.y
y: FMA_64 R38.y, R0.w, R3.y, R38.y
z: FMA_64 R123.z, R0.w, R3.y, R38.y
w: FMA_64 R123.w, R0.z, R3.x, R38.x
56 x: FMA_64 R123.x, R0.w, R3.w, R38.w
y: FMA_64 R123.y, R0.w, R3.w, R38.w
z: FMA_64 R38.z, R0.w, R3.w, R38.w
w: FMA_64 R38.w, R0.z, R3.z, R38.z
57 x: FMA_64 R40.x, R0.w, R4.y, R40.y
y: FMA_64 R40.y, R0.w, R4.y, R40.y
z: FMA_64 R123.z, R0.w, R4.y, R40.y
w: FMA_64 R123.w, R0.z, R4.x, R40.x
58 x: FMA_64 R123.x, R0.w, R4.w, R40.w
y: FMA_64 R123.y, R0.w, R4.w, R40.w
z: FMA_64 R40.z, R0.w, R4.w, R40.w
w: FMA_64 R40.w, R0.z, R4.z, R40.z
59 x: FMA_64 R9.x, R0.w, R5.y, R9.y
y: FMA_64 R9.y, R0.w, R5.y, R9.y
z: FMA_64 R123.z, R0.w, R5.y, R9.y
w: FMA_64 R123.w, R0.z, R5.x, R9.x
60 x: FMA_64 R123.x, R0.w, R5.w, R9.w
y: FMA_64 R123.y, R0.w, R5.w, R9.w
z: FMA_64 R9.z, R0.w, R5.w, R9.w
w: FMA_64 R9.w, R0.z, R5.z, R9.z
61 x: FMA_64 R11.x, R0.w, R7.y, R11.y
y: FMA_64 R11.y, R0.w, R7.y, R11.y
z: FMA_64 R123.z, R0.w, R7.y, R11.y
w: FMA_64 R123.w, R0.z, R7.x, R11.x
62 x: FMA_64 R123.x, R0.w, R7.w, R11.w
y: FMA_64 R123.y, R0.w, R7.w, R11.w
z: FMA_64 R11.z, R0.w, R7.w, R11.w
w: FMA_64 R11.w, R0.z, R7.z, R11.z
63 x: FMA_64 R26.x, R1.y, R3.y, R26.y
y: FMA_64 R26.y, R1.y, R3.y, R26.y
z: FMA_64 R123.z, R1.y, R3.y, R26.y
w: FMA_64 R123.w, R1.x, R3.x, R26.x
64 x: FMA_64 R123.x, R1.y, R3.w, R26.w
y: FMA_64 R123.y, R1.y, R3.w, R26.w
z: FMA_64 R26.z, R1.y, R3.w, R26.w
w: FMA_64 R26.w, R1.x, R3.z, R26.z
65 x: FMA_64 R28.x, R1.y, R4.y, R28.y
y: FMA_64 R28.y, R1.y, R4.y, R28.y
z: FMA_64 R123.z, R1.y, R4.y, R28.y
w: FMA_64 R123.w, R1.x, R4.x, R28.x
66 x: FMA_64 R123.x, R1.y, R4.w, R28.w
y: FMA_64 R123.y, R1.y, R4.w, R28.w
z: FMA_64 R28.z, R1.y, R4.w, R28.w
w: FMA_64 R28.w, R1.x, R4.z, R28.z
67 x: FMA_64 R30.x, R1.y, R5.y, R30.y
y: FMA_64 R30.y, R1.y, R5.y, R30.y
z: FMA_64 R123.z, R1.y, R5.y, R30.y
w: FMA_64 R123.w, R1.x, R5.x, R30.x
68 x: FMA_64 R123.x, R1.y, R5.w, R30.w
y: FMA_64 R123.y, R1.y, R5.w, R30.w
z: FMA_64 R30.z, R1.y, R5.w, R30.w
w: FMA_64 R30.w, R1.x, R5.z, R30.z
69 x: FMA_64 R32.x, R1.y, R7.y, R32.y
y: FMA_64 R32.y, R1.y, R7.y, R32.y
z: FMA_64 R123.z, R1.y, R7.y, R32.y
w: FMA_64 R123.w, R1.x, R7.x, R32.x
70 x: FMA_64 R123.x, R1.y, R7.w, R32.w
y: FMA_64 R123.y, R1.y, R7.w, R32.w
z: FMA_64 R32.z, R1.y, R7.w, R32.w
w: FMA_64 R32.w, R1.x, R7.z, R32.z
71 x: FMA_64 R13.x, R1.w, R3.y, R13.y
y: FMA_64 R13.y, R1.w, R3.y, R13.y
z: FMA_64 R123.z, R1.w, R3.y, R13.y
w: FMA_64 R123.w, R1.z, R3.x, R13.x
72 x: FMA_64 R123.x, R1.w, R3.w, R13.w
y: FMA_64 R123.y, R1.w, R3.w, R13.w
z: FMA_64 R13.z, R1.w, R3.w, R13.w
w: FMA_64 R13.w, R1.z, R3.z, R13.z
73 x: FMA_64 R15.x, R1.w, R4.y, R15.y
y: FMA_64 R15.y, R1.w, R4.y, R15.y
z: FMA_64 R123.z, R1.w, R4.y, R15.y
w: FMA_64 R123.w, R1.z, R4.x, R15.x
74 x: FMA_64 R123.x, R1.w, R4.w, R15.w
y: FMA_64 R123.y, R1.w, R4.w, R15.w
z: FMA_64 R15.z, R1.w, R4.w, R15.w
w: FMA_64 R15.w, R1.z, R4.z, R15.z
75 x: FMA_64 R17.x, R1.w, R5.y, R17.y
y: FMA_64 R17.y, R1.w, R5.y, R17.y
z: FMA_64 R123.z, R1.w, R5.y, R17.y
w: FMA_64 R123.w, R1.z, R5.x, R17.x
76 x: FMA_64 R123.x, R1.w, R5.w, R17.w
y: FMA_64 R123.y, R1.w, R5.w, R17.w
z: FMA_64 R17.z, R1.w, R5.w, R17.w
w: FMA_64 R17.w, R1.z, R5.z, R17.z
77 x: FMA_64 R19.x, R1.w, R7.y, R19.y
y: FMA_64 R19.y, R1.w, R7.y, R19.y
z: FMA_64 R123.z, R1.w, R7.y, R19.y
w: FMA_64 R123.w, R1.z, R7.x, R19.x
09 ALU: ADDR(362) CNT(124)
78 x: FMA_64 R123.x, R1.w, R7.w, R19.w
y: FMA_64 R123.y, R1.w, R7.w, R19.w
z: FMA_64 R19.z, R1.w, R7.w, R19.w
w: FMA_64 R19.w, R1.z, R7.z, R19.z
79 x: FMA_64 R34.x, R2.y, R3.y, R34.y
y: FMA_64 R34.y, R2.y, R3.y, R34.y
z: FMA_64 R123.z, R2.y, R3.y, R34.y
w: FMA_64 R123.w, R2.x, R3.x, R34.x
80 x: FMA_64 R123.x, R2.y, R3.w, R34.w
y: FMA_64 R123.y, R2.y, R3.w, R34.w
z: FMA_64 R34.z, R2.y, R3.w, R34.w
w: FMA_64 R34.w, R2.x, R3.z, R34.z
81 x: FMA_64 R36.x, R2.y, R4.y, R36.y
y: FMA_64 R36.y, R2.y, R4.y, R36.y
z: FMA_64 R123.z, R2.y, R4.y, R36.y
w: FMA_64 R123.w, R2.x, R4.x, R36.x
82 x: FMA_64 R123.x, R2.y, R4.w, R36.w
y: FMA_64 R123.y, R2.y, R4.w, R36.w
z: FMA_64 R36.z, R2.y, R4.w, R36.w
w: FMA_64 R36.w, R2.x, R4.z, R36.z
83 x: FMA_64 R37.x, R2.y, R5.y, R37.y
y: FMA_64 R37.y, R2.y, R5.y, R37.y
z: FMA_64 R123.z, R2.y, R5.y, R37.y
w: FMA_64 R123.w, R2.x, R5.x, R37.x
84 x: FMA_64 R123.x, R2.y, R5.w, R37.w
y: FMA_64 R123.y, R2.y, R5.w, R37.w
z: FMA_64 R37.z, R2.y, R5.w, R37.w
w: FMA_64 R37.w, R2.x, R5.z, R37.z
85 x: FMA_64 R39.x, R2.y, R7.y, R39.y
y: FMA_64 R39.y, R2.y, R7.y, R39.y
z: FMA_64 R123.z, R2.y, R7.y, R39.y
w: FMA_64 R123.w, R2.x, R7.x, R39.x
86 x: FMA_64 R123.x, R2.y, R7.w, R39.w
y: FMA_64 R123.y, R2.y, R7.w, R39.w
z: FMA_64 R39.z, R2.y, R7.w, R39.w
w: FMA_64 R39.w, R2.x, R7.z, R39.z
87 x: FMA_64 R21.x, R2.w, R3.y, R21.y
y: FMA_64 R21.y, R2.w, R3.y, R21.y
z: FMA_64 R123.z, R2.w, R3.y, R21.y
w: FMA_64 R123.w, R2.z, R3.x, R21.x
88 x: FMA_64 R123.x, R2.w, R3.w, R21.w
y: FMA_64 R123.y, R2.w, R3.w, R21.w
z: FMA_64 R21.z, R2.w, R3.w, R21.w
w: FMA_64 R21.w, R2.z, R3.z, R21.z
89 x: FMA_64 R23.x, R2.w, R4.y, R23.y
y: FMA_64 R23.y, R2.w, R4.y, R23.y
z: FMA_64 R123.z, R2.w, R4.y, R23.y
w: FMA_64 R123.w, R2.z, R4.x, R23.x
90 x: FMA_64 R123.x, R2.w, R4.w, R23.w
y: FMA_64 R123.y, R2.w, R4.w, R23.w
z: FMA_64 R23.z, R2.w, R4.w, R23.w
w: FMA_64 R23.w, R2.z, R4.z, R23.z
91 x: FMA_64 R25.x, R2.w, R5.y, R25.y
y: FMA_64 R25.y, R2.w, R5.y, R25.y
z: FMA_64 R123.z, R2.w, R5.y, R25.y
w: FMA_64 R123.w, R2.z, R5.x, R25.x
92 x: FMA_64 R123.x, R2.w, R5.w, R25.w
y: FMA_64 R123.y, R2.w, R5.w, R25.w
z: FMA_64 R25.z, R2.w, R5.w, R25.w
w: FMA_64 R25.w, R2.z, R5.z, R25.z
93 x: FMA_64 R27.x, R2.w, R7.y, R27.y
y: FMA_64 R27.y, R2.w, R7.y, R27.y
z: FMA_64 R123.z, R2.w, R7.y, R27.y
w: FMA_64 R123.w, R2.z, R7.x, R27.x
94 x: FMA_64 R123.x, R2.w, R7.w, R27.w
y: FMA_64 R123.y, R2.w, R7.w, R27.w
z: FMA_64 R27.z, R2.w, R7.w, R27.w
w: FMA_64 R27.w, R2.z, R7.z, R27.z
95 x: FMA_64 R8.x, R6.y, R3.y, R8.y
y: FMA_64 R8.y, R6.y, R3.y, R8.y
z: FMA_64 R123.z, R6.y, R3.y, R8.y
w: FMA_64 R123.w, R6.x, R3.x, R8.x
96 x: FMA_64 R123.x, R6.y, R3.w, R8.w
y: FMA_64 R123.y, R6.y, R3.w, R8.w
z: FMA_64 R8.z, R6.y, R3.w, R8.w
w: FMA_64 R8.w, R6.x, R3.z, R8.z
97 x: FMA_64 R10.x, R6.y, R4.y, R10.y
y: FMA_64 R10.y, R6.y, R4.y, R10.y
z: FMA_64 R123.z, R6.y, R4.y, R10.y
w: FMA_64 R123.w, R6.x, R4.x, R10.x
98 x: FMA_64 R123.x, R6.y, R4.w, R10.w
y: FMA_64 R123.y, R6.y, R4.w, R10.w
z: FMA_64 R10.z, R6.y, R4.w, R10.w
w: FMA_64 R10.w, R6.x, R4.z, R10.z
99 x: FMA_64 R12.x, R6.y, R5.y, R12.y
y: FMA_64 R12.y, R6.y, R5.y, R12.y
z: FMA_64 R123.z, R6.y, R5.y, R12.y
w: FMA_64 R123.w, R6.x, R5.x, R12.x
100 x: FMA_64 R123.x, R6.y, R5.w, R12.w
y: FMA_64 R123.y, R6.y, R5.w, R12.w
z: FMA_64 R12.z, R6.y, R5.w, R12.w
w: FMA_64 R12.w, R6.x, R5.z, R12.z
101 x: FMA_64 R14.x, R6.y, R7.y, R14.y
y: FMA_64 R14.y, R6.y, R7.y, R14.y
z: FMA_64 R123.z, R6.y, R7.y, R14.y
w: FMA_64 R123.w, R6.x, R7.x, R14.x
102 x: FMA_64 R123.x, R6.y, R7.w, R14.w
y: FMA_64 R123.y, R6.y, R7.w, R14.w
z: FMA_64 R14.z, R6.y, R7.w, R14.w
w: FMA_64 R14.w, R6.x, R7.z, R14.z
103 x: FMA_64 R29.x, R6.w, R3.y, R29.y
y: FMA_64 R29.y, R6.w, R3.y, R29.y
z: FMA_64 R123.z, R6.w, R3.y, R29.y
w: FMA_64 R123.w, R6.z, R3.x, R29.x
104 x: FMA_64 R123.x, R6.w, R3.w, R29.w
y: FMA_64 R123.y, R6.w, R3.w, R29.w
z: FMA_64 R29.z, R6.w, R3.w, R29.w
w: FMA_64 R29.w, R6.z, R3.z, R29.z
105 x: FMA_64 R31.x, R6.w, R4.y, R31.y
y: FMA_64 R31.y, R6.w, R4.y, R31.y
z: FMA_64 R123.z, R6.w, R4.y, R31.y
w: FMA_64 R123.w, R6.z, R4.x, R31.x
106 x: FMA_64 R123.x, R6.w, R4.w, R31.w
y: FMA_64 R123.y, R6.w, R4.w, R31.w
z: FMA_64 R31.z, R6.w, R4.w, R31.w
w: FMA_64 R31.w, R6.z, R4.z, R31.z
107 x: FMA_64 R33.x, R6.w, R5.y, R33.y
y: FMA_64 R33.y, R6.w, R5.y, R33.y
z: FMA_64 R123.z, R6.w, R5.y, R33.y
w: FMA_64 R123.w, R6.z, R5.x, R33.x
108 x: FMA_64 R123.x, R6.w, R5.w, R33.w
y: FMA_64 R123.y, R6.w, R5.w, R33.w
z: FMA_64 R33.z, R6.w, R5.w, R33.w
w: FMA_64 R33.w, R6.z, R5.z, R33.z
10 ALU: ADDR(486) CNT(8)
109 x: FMA_64 R35.x, R6.w, R7.y, R35.y
y: FMA_64 R35.y, R6.w, R7.y, R35.y
z: FMA_64 R123.z, R6.w, R7.y, R35.y
w: FMA_64 R123.w, R6.z, R7.x, R35.x
110 x: FMA_64 R123.x, R6.w, R7.w, R35.w
y: FMA_64 R123.y, R6.w, R7.w, R35.w
z: FMA_64 R35.z, R6.w, R7.w, R35.w
w: FMA_64 R35.w, R6.z, R7.z, R35.z
11 ENDLOOP i0 PASS_JUMP_ADDR(6)
Das ist "computationally dense". Da limitiert nix außer den ALUs. Und man benötigt auch nicht viele Wavefronts/Warps, um die Zugriffslatenzen zu verstecken.

HPVD

2012-10-17, 21:02:19

...
K20 = 936 GFLOPs DGEMM @225W
...
Das dumme ist eben dass wenn die 13SMX specs stimmen sollten, NV's ultra kreatives marketing nie gelogen hat als sie in der Vergangenheit behaupteten dass Kepler ueber 3x Mal so viel sustainable GFLOPs/W liefert.

Vorraussetzung naturlich dass die 936 GFLOPs DGEMM auch wirklich stimmen bzw. erreichbar sind wenn der K20 auch wirklich 13SMX/320bit sein wird. Muss ja auch nicht so viel sein; um marketingtechnisch korrekt zu sein reicht ein Faktor 3.01x Unterschied :wink:

so wird es kommen...

die Frage die sich mir dann aber als Laie (nur Nutzer der Rechenpower) stellt:
wieso muss AMD dann mit der 7970/W9000 sowohl
- von der Chipfläche her (4,3 zu 7,1Milliarden Transistoren) als auch
- von den Funktionen (Dynamic Parallelism, Hyper-Q)
weniger Aufwand betreiben um 623 bzw sogar 848GFlop/s @ DGEMM
(vgl http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9504573&postcount=1300)
zu erreichen?

Oder anders gefragt: was kann GK110 "großes" (Aufwandfressendes) was die AMD-Architektur architekturbedingt nicht kann?

Skysnake

2012-10-17, 21:46:37

Gipsel

2012-10-17, 22:07:40

Gipsel, kann es sein, dass du apriori davon aus gehst, das jeder Thread auf jedes Register zugreifen kann?

Wenn ja, geb ich dir recht, da musste dann aber, soweit ich das weis halt GPU-Assembler schreiben. Das ist halt allgemein nicht drin für die Softwareentwicklung.

Ansonsten bringen dir die Daten im Register halt nichts, weil nur der eine Thread drauf zugreifen kann, und im Shared/L1 können eben alle Threads einer WorkGroupe darauf zugreifen.

Mit normalem CUDA/OpenCL haste ja auch keine andere Chance, weil du eben nicht über die Register direkt Daten austauschen kannst.
Jedes work item greift natürlich nur auf seinen privaten Speicherbereich zu (der in den Registern liegt). Wie gesagt nutzt prunedtrees Code ja überhaupt kein shared memory.
Wo bei Dir offensichtlich der Lichtschalter klemmt, ist daß jedes work item an einer anderen 8x8 Submatrix rumrechnet (die komplett in den Registern dieses einen work items liegt, genau wie die 16 pro Schleifeniteration geladenen Werte), nicht die ganze work group an einem Tile mit data reuse über shared memory (was wie gesagt nichts bringt, da die Bandbreite aus dem shared memory auch nicht höher ist als aus dem L1). Data reuse findet erstmal nur innerhalb eines jeden work items statt, nicht zwischen work items.
Eine work group (nehmen wir mal eine Größe von 64 work items = 1 Wavefront an) arbeitet an insgesamt 64 8x8 Tiles (also einem 64x64 Tile), wodurch dort dann über den L1-Cache implizit noch mehr geteilt und wiederbenutzt wird (was die Anforderungen an die L2- bzw. Speicherbandbreite noch weiter senkt). Jetzt kapiert?

Bei Radeons paßt das so rein (sind 656 Bytes pro work item, die VLIW-ISA gibt maximal 2 kB her, GCN nur noch 1 kB ;)), bei nV bisher nicht (wird es aber mit GK110).

Edit:
Für GCN ist das 8x8 Layout mit prunedtrees Ansatz übrigens nicht optimal, 4x8 oder 6x8 (paßt theoretisch von der Registerzahl optimal, nur keine Ahnung, ob der Compiler clever genug wäre) sollte besser gehen. Außerdem ist auf GCN auch das "traditionelle" Tiling mit shared memory Nutzung recht performant (weil der LDS effektiv die doppelte Bandbreite wie der L1 bietet und auch parallel nutzbar ist, außerdem sind Broadcasts aus dem LDS sehr effizient).

Skysnake

2012-10-18, 08:35:22

Gipsel

2012-10-18, 12:08:51

Ok, jetzt hab ichs verstanden, wie der Algo funktionieren soll.

Den Datenreuse bekommt man also nur innerhalb eines Workitems hin. Soweit check.
Die Daten für die Register/workitems holt man sich einfach über den RAM, und hofft, das durch Datenlokalität dann die Daten im L1 sind richtig? (Die Annahme muss aber nicht zutreffend sein. Keine Ahnung wie da die Hardware die Sachen hin und her switched)Man weiß ja, wie man die Daten anfordert und wie viele Wavefronts auf jeder CU laufen. Das kann man also im passenden Layout starten. Die einzelnen Wavefronts laufen ja durch die geblockten Speicherzugriffe und Arithmetik quasi in lockstep. Das ist sehr gut vorhersagbar. Auf jeder CU (vor SI) laufen wie gesagt genau 6 Wavefronts, die zusammen an einem 128x192 Tile rechnen (oder eben 192x128). Innerhalb diesem hat man perfekten data reuse, jeder benötigte Wert muß nur genau einmal aus dem L2 geladen werden. Das wird nur noch eine Handvoll GB/s, das ist überhaupt kein Problem mehr.
8x8 sind jetzt aber keine großen tiles. Ich hatte >16x16 Tiles verwendet mit shared Memory.D.h. also 16x16 für eine ganze work group? Bei prunedtree's Code macht jede Wavefront 64x64 Tiles. Und zwar komplett in den Registern, die bekanntlich deutlich schneller als shared memory sind. ;)
Und wenn ich wie gesagt mich nicht falsch erinnere, ist der Datenreuse nicht lineare von der Tile-größe Abhängig. Wie gesagt, bin mir da aber nicht mehr sicher, meine mich aber zu erinnern, das es quadratisch war.Habe ich oben doch schon geschrieben. Bei mxk Subtiles benötigst Du m+k loads für m*k FMAs. Der "Bandbreiten-Multiplikationsfaktor" ist also m*k/(m+k) und für m=k ist es schlicht m. Bei 8x8 Tiles reduzierst Du also die Anzahl der Speicherzugriffe auf ein Achtel.
Lädst Du dagegen die Tiles zuerst in den shared memory (gehen wir mal wieder von quadratischen mxm Tiles aus), hast Du immer noch 2m Ladevorgänge aus den Buffern mit den Matrizen für m² FMAs (2*m² für die komplette Matrix mit dann m³ FMAs). Allerdings mußt Du in dem Fall ja noch zusätzlich die Operanden aus dem shared memory holen, und die Bandbreite ist eben auch deutlich niedriger als die Registerbandbreite bzw. sogar identisch zur L1 Bandbreite. Schneller wird es so also auf gar keinen Fall. Die effektive Bandbreitenreduktion wird also in erster Linie nur von dem bbeinflußt, was Du innerhalb eines Workitems machst. Bei 16x16 Tiles im shared memory und 64er work groups wären das also maximal 2x2 Tiles pro workitem und damit nur eine Reduktion der erforderlichen Bandbreite (auSpeicher ausßerhalb der Register) auf die Hälfte (statt auf ein Achtel). Mit dem richtigen Tile-Layout geht dann die Bandbreitenanforderung an den L2 auf 128+192)/(128*192) = 1,3% des naiven Ansatzes (8 Byte pro Flop in DP) runter. Das sind dann nur noch 0,1 Byte pro DP-Flop geforderte Bandbreite vom L2, für 1 TFlops in DP also gerade mal noch 100 GB/s nötige L2-Bandbreite.
Bzgl Bandbreite vom L1/Shared:
Das ist mir eigentlich ziemlich neu, dass da die Bandbreite nicht ausreichen würde, um die Einheiten zu versorgen. Mir war eigentlich nur das Problem der Latenz bewusst. Kannst du dazu mal genau Zahlen geben?Ganz einfach, die älteren GPUs können alle 64 Byte pro Takt, genau so viel, wie man mit 4 TMUs aus dem Tex-L1 laden kann (Cypress und Cayman können theoretisch 128 Byte pro Takt, aber das ist eher theoretisch und kostet ALU-Zyklen, bringst also wenig, wenn man was rechnen will).
SI kann wirklich 2x64 Byte pro Takt in einer CU (es sind offenbar 2 getrennte Datenbusse, 64 Byte/Takt zu SIMD0/1 und weitere 64 Byte/Takt zu SIMD2/3).
Bei Kepler hat man wegen der deutlich größeren SMx das auch anheben müssen. Es sind jetzt ja 32 L/S-Einheiten statt nur 16 (jede kann einen 4 Byte Zugriff pro Takt bewältigen, also bei Fermi 16x4=64 Byte, jetzt 32x4 Byte). Die L/S-Einheiten sind ja für beides zuständig, sowohl Speicherzugriffe über den L1 als auch shared memory Zugriffe (ist ja auch das gleiche SRAM-Array). Und als zusätzliches Goodie bekommt GK110 (ist mir nicht ganz klar, ob GK104 das auch schon kann) noch spendiert, daß die L/S-Einheiten 8 Byte pro Takt liefern können, wären also maximal 256 Byte/Takt für die 192 ALUs (SI steht bei 128 Byte für 64 ALUs).
Das ganze natürlich nur bei perfektem Zugriffsmuster, sprich, wenn es keine Bankkonflikte gibt.
Zum Vergleich, die nutzbare Registerbandbreite liegt typischerweise bei 16 Byte pro ALU, also 3072 Byte pro Takt bei Kepler (implizit nutzbar gar noch höher, da L/S-Einheiten usw. auch im Hintergrund in die Register schreiben können, die Registerfiles eines Kepler-SMx werden vermutlich 4kB/Takt Bandbreite aufweisen). Für AMD-GPUs gilt das analog.
Soweit ich mich erinnern kann, kann der Shared/L1 aber auch nen Multicast von Daten oder nicht? Das sollte ja auch viele Zugriffe auf diesen entschärfen. Ich meine mich zu erinnern, dass der das kann, ähnlich wie beim RAM-Controller, der auch umsortiert usw.Das macht der Tex-L1 aber z.B. auch. Das bringt also gar nichts an Mehrperformance. Entscheidend ist, daß Du aus dem shared memory nicht mehr Ladeoperationen durchführen kannst, als aus dem L1. Damit war's das. So einfach ist das.
Gipsel hast du eventuell die SGEMM FLop/s für den von dir genannten Algorithmus auf ner GTX460 parat? Dann kann ich das mit meinen Werten, die ich damals erreicht habe vergleichen. Wird sicherlich viel besser sein, weil wir auf so ne Idee nicht gekommen sind, aber mich würde es einfach mal interessieren.Der läuft ja auf nV gar nicht so wie auf ATI, weil er zu viele Register belegt. Das war doch der Ausgangpunkt für die ganze Diskussion. Aber in SP ist es ganz interessant.
Kocht man es auf für nV verträgliche Registerzahlen runter, ist die Bandbreitenersparnis zwar kleiner, aber man sollte immer noch was damit reißen können (einfach weil die Peakleistung von GF1xx nicht übermäßig hoch ist). Das Maximum für nV in SP ist 8x4 Tiling mit 12 loads für 32 FMAs. GF104 kann 16 loads und 48 fmas, ergibt zwar theoretisch eine maximale Effizienz von 88% oder so (also praktisch ~80%, wenn man die Radeons als Maßstab nimmt), aber vermutlich klemmt da etwas Anderes. Aber keine Ahnung was. Müßte vielleicht mal wer ausprobieren.

Skysnake

2012-10-18, 12:35:06

Wie gesagt, der/die Code/Idee ist jetzt nicht gerade strait forward. Da muss man erst mal darauf kommen, das so zu machen. Ergibt aber durchaus Sinn. Man unterschätzt halt doch schnell mal die Registerfiles.

Hübie

2012-10-20, 09:21:36

Na habt ihr euch ausgetobt? ;D So tief dringt kaum jmd. in die Architektur ein. Ist einfach zu spezifisch was ihr hier diskutiert und übersteigt wohl die Kompetenzen der meisten anderen hier (inkl. meiner einer).

Gibts was neues? Bin nur noch mit 64kbit/s unterwegs :( Da macht News lesen kein Bock!

Skysnake

2012-10-20, 12:38:31

Ne nicht wirklich.

Man sieht nur überall die "News" über "offizielle" K20 Specs aus den Boden sprießen, die sich eben alle nur auf diesen Verkäufer beziehen....

Ergo nein, es gibt nichts neues.

Hübie

2012-10-20, 13:03:14

Alles klar. Vielen Dank :smile:

dildo4u

2012-10-29, 11:57:01

Cray's Jaguar (or XK7) supercomputer at Oak Ridge National Laboratory has been loaded up with the first shipping NVIDIA Telsa K20 GPUs and renamed Titan. Loaded with 18,688 of the Kepler-based K20s, Titan's peak performance is more than 20 petaflops. Sure, the machine has an equal number of 16-core AMD Opteron 6274 processors as it does GPUs, but the Tesla hardware packs 90 percent of the entire processing punch. Titan is roughly ten times faster and five times more energy efficient than it was before the name change, yet it fits into the same 200 cabinets as its predecessor

http://www.engadget.com/2012/10/29/cray-titan-supercomputer-nvidia-tesla-gpu-k20/#continued

In Kombination mit AMD CPU's mehr Kerne für Geld war wohl wichtiger als IPC,Hyper Q sein dank.

Godmode

2012-10-29, 12:18:21

http://www.engadget.com/2012/10/29/cray-titan-supercomputer-nvidia-tesla-gpu-k20/#continued

In Kombination mit AMD CPU's mehr Kerne für Geld war wohl wichtiger als IPC,Hyper Q sein dank.

Ist er jetzt schon voll bestückt, oder dauert das noch? Gibt es eigentlich irgendwelche Neuigkeiten über den Desktop GK110?

Ailuros

2012-10-29, 12:26:42

Ist er jetzt schon voll bestückt, oder dauert das noch? Gibt es eigentlich irgendwelche Neuigkeiten über den Desktop GK110?

Duerfte komplett sein. Sonst nein nichts Neues fuer desktop.

boxleitnerb

2012-10-29, 12:35:59

Schon? Ich dachte, das zieht sich bis nächstes Jahr hin, weil die Yields nicht so toll sind. Hört man ja von den üblichen Verdächtigen...

Gaestle

2012-10-29, 13:09:49

19K Chips können ja auch bei mageren Yields erreicht werden, wenn die schon ca.2-3 Monate produzieren.

Wenn man von 7-10K Chips pro Monat ausgeht, und nach der Schätzung Chips pro Wafer hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9480580&postcount=1102) wären das bei ca. 35-50 Chips pro Wafer ca. 200 Wafer pro Monat.

Hübie

2012-10-29, 13:48:58

Ist er jetzt schon voll bestückt, oder dauert das noch? Gibt es eigentlich irgendwelche Neuigkeiten über den Desktop GK110?

Oak Ridge wurde in der ersten September-Woche mit K20 beliefert. Ich glaube ehrlich gesagt nicht dass der Umbau schon abgeschlossen ist. Afaik sind drei Stufen geplant. Siehe hier: http://ht4u.net/news/26144_erstes_lebenszeichen_von_nvidias_gk110/

Ailuros

2012-10-29, 13:53:13

Gipsel

2012-10-29, 14:05:58

Oak Ridge wurde in der ersten September-Woche mit K20 beliefert. Ich glaube ehrlich gesagt nicht dass der Umbau schon abgeschlossen ist. Afaik sind drei Stufen geplant. Siehe hier: http://ht4u.net/news/26144_erstes_lebenszeichen_von_nvidias_gk110/
Das waren wesentlich mehr Stufen. Angefangen hat es ja bereits mit der schrittweisen Umrüstung auf die XK6-Knoten mit BD (wo Die Teslas dann eine drop in-Erweiterung sein sollten). Offenbar werden jetzt sogar die XK6-Knoten nochmal ausgetauscht oder zumindest modifiziert, denn es wird jetzt offiziell auf XK7 umgestellt (das steht zwar nicht in der Timeline, aber in der Pressemeldung vom ORNL)?!? Die Umrüstung dauert angeblich so 2-3 Monate (http://www.olcf.ornl.gov/support/user-guides/titan-user-guide/#7804). Die Pressemeldung kam nur zum Shutdown der letzten Jaguar-Knoten ohne GPUs (das war eigentlich genau am 9. Oktober). Das Ding geht also frühestens gegen Weihnachten wieder an den Start (ein offizielles Datum existiert noch nicht (http://www.olcf.ornl.gov/titan/system-configuration-timeline/)), eventuell sogar erst nächstes Jahr. Commisioning und Test muß ja auch noch gemacht werden.

Aber mal was Anderes:
ORNL behauptet eine theoretische Peakleistung von 27 PFLOP/s. Da wir die Anzahl der Flops von den CPUs halbwegs genau kennen (zwischen 2,63 und 2,99 PFLOP/s je nach Takt, die Opterons laufen zwischen 2,2 und 2,5GHz auf allen Kernen), bleiben mit so etwa 2% Rundungsfehler rund 24 PFlop/s übrig. Macht dann ziemlich genau 1,28 TFlop/s pro Tesla-Karte. Nehmen wir mal wieder 13 SMx an, kommt man auf ~770 MHz Takt, bei 14 SMx wären es 715MHz. Wie gesagt mit einigen Prozent möglichem Fehler, je nachdem wie die beim ORNL gerundet haben, könnten es maximal 30 MHz mehr sein. Ein wenig mehr als bei den geleakten Specs der Tesla wird es wohl sein, weil das ORNL auch eine Version mit vollem 384Bit Speicherinterface verbaut (sprich mit 6 GB Speicher, nicht nur mit 5 GB), das wird also schon eher das Topmodell sein.

Edit:
Ich sehe gerade, daß der ORNL-Mensch laut HT4U gesagt hat, daß sie nur 14592 GPUs anschaffen, nicht 18688, wie das in der Pressemeldung steht. Muß man das verstehen?

Skysnake

2012-10-29, 17:40:38

http://www.engadget.com/2012/10/29/cray-titan-supercomputer-nvidia-tesla-gpu-k20/#continued

In Kombination mit AMD CPU's mehr Kerne für Geld war wohl wichtiger als IPC,Hyper Q sein dank.
....

Gemini sagt dir was?

Das ist konkurrenzlos nur mal so am Rande....

Edit:
Ich sehe gerade, daß der ORNL-Mensch laut HT4U gesagt hat, daß sie nur 14592 GPUs anschaffen, nicht 18688, wie das in der Pressemeldung steht. Muß man das verstehen?
Werden wohl nicht mehr Karten bekommen haben, oder die Perf/W erreicht mal wieder nicht die Vorgaben, womit man erst mal nur das aufrüstet, was man unbedingt braucht, und dann den Refresh abwartet, bis die Perf/W passt.

Andere Gründe seh ich nicht.

Godmode

2012-10-29, 17:48:19

....

Gemini sagt dir was?

Das ist konkurrenzlos nur mal so am Rande....

Werden wohl nicht mehr Karten bekommen haben, oder die Perf/W erreicht mal wieder nicht die Vorgaben, womit man erst mal nur das aufrüstet, was man unbedingt braucht, und dann den Refresh abwartet, bis die Perf/W passt.

Andere Gründe seh ich nicht.

Oder sie erreichen die angepeilte Leistung schon mit weniger Karten? :confused:

Gipsel

2012-10-29, 17:48:45

Werden wohl nicht mehr Karten bekommen haben, oder die Perf/W erreicht mal wieder nicht die Vorgaben, womit man erst mal nur das aufrüstet, was man unbedingt braucht, und dann den Refresh abwartet, bis die Perf/W passt.

Andere Gründe seh ich nicht.
Oder nV schenkt denen die fehlenden 4096 Karten als Ausgleich für Verspätung. :freak: :weg:

Edit:
Oder sie erreichen die angepeilte Leistung schon mit weniger Karten? :confused:
Vielleicht erreichen sie 20 PFlop/s theoretischer Peakleistung, aber nicht im Benchmark. Und die 27PFlop/s aus der Pressemeldung würden sie so ziemlich sicher nicht erreichen (würde >850MHz mit allen 15 SMx erfordern, oder >920 MHz/990 MHz mit 14/13 SMx [und das in 225W]).

Ailuros

2012-10-29, 18:03:02

Edit:
Ich sehe gerade, daß der ORNL-Mensch laut HT4U gesagt hat, daß sie nur 14592 GPUs anschaffen, nicht 18688, wie das in der Pressemeldung steht. Muß man das verstehen?

>14,5k waren es auch afaik aber ich kann ja nicht wissen was jeder weiss oder behauptet noch kann ich es so leicht bezweifeln. Wie gesagt man erzaehlte mir von 14 SMX bei "high 700s" um genau zu sein fuer Oak Ridge; muss aber keineswegs stimmen.

Godmode

2012-10-29, 18:03:47

:freak:
http://techreport.com/news/23808/nvidia-kepler-powers-oak-ridge-supercomputing-titan
Incidentally, the Opteron processors used in the system are dual-chip CPUs based on the Bulldozer microarchitecture. We asked Sumit Gupta, General Manager for Tesla Accelerated Computing at Nvidia, why those CPU were chosen for this project, given the Xeon's current dominance in the HPC space. Gupta offered an interesting insight into the decision. He told us the contracts for Titan were signed between two and three years ago, and "back then, Bulldozer looked pretty darn good."

Ailuros

2012-10-29, 18:29:09

Gipsel,

http://nvidianews.nvidia.com/Releases/NVIDIA-Powers-Titan-World-s-Fastest-Supercomputer-For-Open-Scientific-Research-8a0.aspx

Titan, the world's fastest open-science supercomputer,(1) was completed this month....

Titan's peak performance is more than 20 petaflops -- or 20 million billion floating-point operations per second -- about 90 percent of which comes from 18,688 NVIDIA® Tesla® K20 GPU accelerators.

~18 Petaflops von 18688 K20 = ~960GFLOPs/K20 oder verpasse ich etwas?

Skysnake

2012-10-29, 18:47:59

Ja, ist wohl alt, und die wissen entweder selbst nicht, was Sie machen, oder OakRidge hat ne "Ente" raus gelassen, um in ein paar Tagen bei der Veröffentlichung der neuen Top500 zu überraschen.

Wenns aber wirklich nur ~960GFLop/s werden, dann kanns durchaus sein, das man wieder das Perf/W Ziele gerissen hat und OakRidge einfach nicht mehr will. Ich kanns mir zwar kaum Vorstellen, dass die Kühlung Probleme macht, der Vorgänger war ja größer, aber man weiß ja auch nie, wie das alles geplant ist.

Gipsel

2012-10-29, 18:49:11

Die können sich einfach nicht einigen, wieviele Tesla-Karten da nun wirklich drinstecken. NV sagt 18688, nennt aber die Leistung, als wenn es nur die 14592 wären. Das ORNL nennt einmal im Interview die Zahl 14592 und 20 PFlop/s, an anderer Stelle (http://www.olcf.ornl.gov/titan) spricht man aber ebenfalls von 18688 und dann 27 PFLOP/s theoretischer Peakleistung. Keine Ahnung, wie man das auflöst.
Wie schon vor einem Jahr bekannt, war die Finanzierung der Tesla-Karten lange Zeit noch unklar (also wie viele man dann letztendlich kauft), weswegen die Leistungsangaben damals schon von mindestens 10 PFLOP/s über 20 PFLOP/s bis zu maximal knapp 30 PFLOP/s bei Vollbestückung variierten. Die auf der ORNL-Seite angegebenen 27PFlop/s beziehen sich eindeutig auf die theoretische Peakleistung bei Vollbestückung. Die Karten müssen also theoretisch so knapp 1,3 TFLOP/s schaffen. Wieviel davon im Benchmark rüberkommt, wird man abwarten müssen (wenn die Kiste voll bestückt ist, sollte man die 20 PFLOP/s im Benchmark knacken oder da liegt irgendwas im Argen). Vielleicht schaffen sie es ja noch bis zur nächsten Top500 Liste (Mitte November) einen ersten Benchmark zu fahren (nutzbar wird Titan wie gesagt erst Anfang nächsten Jahres sein).

Edit:
Eine der heute veröffentlichen Stories (http://www.knoxnews.com/news/2012/oct/29/titans-ready-to-roll-ornl-supercomputer-may-no-1/) bezieht sich auch noch mal auf diese momentan noch etwas undurchsichtige Situation:
ORNL is the U.S. Department of Energy's largest science lab and hosts the agency's Leadership Computing Facility. If, however, the laboratory regains the top spot in the world computer rankings, it will owe a bit of the credit to the National Oceanic and Atmospheric Administration. Oak Ridge has hosted NOAA's top supercomputer — Gaia, a Cray machine dedicated exclusively to climate research — for a couple of years as part of a memorandum of understanding to share research and operations. When planning the construction of Titan, ORNL did not have a sufficient amount of money from DOE to fully populate the new supercomputer with NVIDIA GPUs. In order to get the entire complement of 18,688 graphics processing units, NOAA agreed to supplement the lab's funding in exchange for a certain amount of research time on the new super-duper Titan. Nichols confirmed the deal, but he declined to say how much NOAA contributed, how many GPUs were acquired with that money or how much time was allocated to NOAA on Titan.
Vielleicht sind das ja die fehlenden 4096 GPUs und die Quelle der Verwirrung.

Edit2:
HPCWire spricht übrigens von 732 MHz (http://www.hpcwire.com/hpcwire/2012-10-29/titan_sets_high-water_mark_for_gpu_supercomputing.html?featured=top). Und wenn die das nicht wissen, weiß es Keiner außerhalb von nV und dem ORNL.
Spricht also meiner Meinung nach für 14SMx und 1312 GFLOP/s Peak jeder Tesla-Karte. Damit kommt das auch mit den 27 PFLOP/s theoretischem Peak für Titan hin (2,63 PFLOP/s CPU-Leistung + 18688*1,312TFLOP/s = 27,14 PFLOP/s Peak). Liegt mittendrin in meiner obigen Schätzung von 715 MHz bis maximal 745 MHz für die 14 SMx-Variante.

Und man erfährt auch den Grund für den XK6=>XK7-Wechsel. Die XK6-Infrastruktur unterstützt ja nur maximal 10,8 MW für die 200 Racks (es gab ja eine ausführliche Diskussion über die Kühllösung vor etwa einem Jahr, XK6 ist für 54 kW pro Rack spezifiziert). Jetzt wurde das offenbar nochmal auf 12,7 MW aufgebohrt. Scheint wohl doch ziemlich viel Strom zu ziehen das Teil. :rolleyes:
Edit3: Aber keine Ahnung, wie HPCWire auf die 12,7 MW kommt. XK7 ist genau wie XK6 mit 54,1 kW/Rack spezifiziert, was dann für die 200 Racks keinen Unterschied ergeben sollte. Na vielleicht rechnen die bei den 12,7 MW noch das Storage-System dazu, keine Ahnung.

Ailuros

2012-10-29, 18:56:35

Womoeglich Schnappsidee, aber wie moeglich ist es dass z.B. Echtzeit DGEMM Werte angegeben werden? 960GFLOPs DGEMM wuerde in etwa den Specs entsprechen die der Haendler vor kurzem veroeffentlichte und auch wieder zurueckgezogen hat. Im Gegenfall: you may excuse the blond moment ;)

20PFLOPs * 90% = ~18PFLOPs / 18688 = ~960 GFLOPs/GPU

13SMX * 0.705GHz = 3519 / 3 = 1173 GFLOPs DP * 80% = 938 GFLOPs

Gipsel

2012-10-29, 19:20:52

Womoeglich Schnappsidee, aber wie moeglich ist es dass z.B. Echtzeit DGEMM Werte angegeben werden?Das können im Moment höchstens Schätzungen sein. Die starten im Moment vielleicht die Benchmarks (wenn sie schnell waren) und normalerweise muß man da noch ein wenig tunen, damit man den entscheidenden Benchmark-Run startet. Wie gesagt wird die momentane Ausbauphase inklusive Tests laut ORNL noch 2 Monate dauern und die Übergabe erst Anfang nächsten Jahres erfolgen.

boxleitnerb

2012-10-29, 21:08:35

BSN sagt 13 SMX (46,645,248 SPs und 18,688 GPUs). Ich glaube nicht, dass wir auf absehbare Zeit erfahren, wieviele SMX da jetzt wirklich drin sind pro GPU. Vielleicht hat er auch nur die vermuteten K20 Specs von dieser Shop Webseite hochgerechnet.

Ich glaube, den Startpost kann man übrigens anpassen. 2 TF DP kommen wohl erst mit Maxwell.
Nicht, dass ich Ailuros alles unbesehen sofort glaube, aber die Prognose von ca. 1 TF DP für GK104 und 2+ TF DP für GK110 lagen dann beide ziiiiiemlich weit daneben :D

Ailuros

2012-10-29, 22:48:40

Ich hatte auch nie erwartet das 104 so klein ausfaellt und Anhand der vorigen Generation auf 3:1 bzw. 2:1 (je nach Fall) zu wetten war nicht so absurd. Und ich hab auch nie behauptet dass ich nie und nirgends falsch liege. Um ganz genau zu sein erwaehnte ich mehr als nur einmal dass ich oefter falsch als korrekt liege, es aber nicht unbedingt jeder bemerkt.

Was jetzt BSN betrifft, die Specliste ist zu ausfuehrlich dass er sie nur so einfach hochgerechnet hat. Mit den SPs traue ich es Theo noch zu mit dem Rest eher nicht ;)

boxleitnerb

2012-10-29, 23:23:50

Ailuros

2012-10-30, 06:23:14

Nix gegen dich natürlich, ich weiß, dass man jede Aussage immer mit einer Ladung Salz nehmen muss. Mit vielem lagst du ja richtig, da hat es mich halt gewundert, dass du nur 6 Tage vor dem Launch von GK104 da so geirrt hast.

Es sind stets nur eine Reihe von wagen hints sehr selten etwas konkretes. Ich muss dann eben meistens die Luecken selber fuellen. GK104 war insgesamt ja noch relativ gut wenn ich bedenke wie miserabel daneben ich mit der GK110 Konstellation lag.

Ich kann trotz allem Nachts gut schlafen wenn ich bedenke dass es auch Theos dort draussen gibt :eek::freak:;D

boxleitnerb

2012-10-31, 08:21:29

Wenn Anandtech vor Ort war, Fotos machen durfte und 14 SMX sagt, wird es wohl stimmen:

NVIDIA's K20 is the server/HPC version of GK110, a part that never had a need to go to battle in the consumer space. The K20 features 2688 CUDA cores, totaling 7.1 billion transistors per GPU built using TSMC's 28nm process.

http://www.anandtech.com/show/6421/inside-the-titan-supercomputer-299k-amd-x86-cores-and-186k-nvidia-gpu-cores

Skysnake

2012-10-31, 08:56:10

Auf welche Taktrate kommen wir damit?

Gipsel

2012-10-31, 09:02:32

Auf welche Taktrate kommen wir damit?
HPCWire spricht übrigens von 732 MHz (http://www.hpcwire.com/hpcwire/2012-10-29/titan_sets_high-water_mark_for_gpu_supercomputing.html?featured=top). Und wenn die das nicht wissen, weiß es Keiner außerhalb von nV und dem ORNL.
Spricht also meiner Meinung nach für 14SMx und 1312 GFLOP/s Peak jeder Tesla-Karte. Damit kommt das auch mit den 27 PFLOP/s theoretischem Peak für Titan hin (2,63 PFLOP/s CPU-Leistung + 18688*1,312TFLOP/s = 27,14 PFLOP/s Peak). Liegt mittendrin in meiner obigen Schätzung von 715 MHz bis maximal 745 MHz für die 14 SMx-Variante.
;)

boxleitnerb

2012-10-31, 09:52:23

Dann lag Ailuros mit 14 SMX und 750 MHz ja fast goldrichtig.

Damit liegen 15 SMX mit 800+ MHz problemlos in Reichweite für 250W. Da man weniger Speicher verbaut, vielleicht gar 850 MHz.

AnarchX

2012-10-31, 09:54:10

Für GPC/ROP-lastige Workloads kann man sicherlich auch auf deutlich über 900MHz boosten.

fondness

2012-10-31, 09:59:34

Dann lag Ailuros mit 14 SMX und 750 MHz ja fast goldrichtig.

Damit liegen 15 SMX mit 800+ MHz problemlos in Reichweite für 250W. Da man weniger Speicher verbaut, vielleicht gar 850 MHz.

Hm, bei 15SMX bräuchte man für 50% mehr Rechenleistung als bei GK104 ca. 850Mhz Boost. Könnte hinkommen.
Zusammen mit 50% mehr Bandbreite müsste man so auch 50% mehr Leistung ggü. GK104 erreichen falls sonst nichts limitiert.

boxleitnerb

2012-10-31, 10:22:59

Für GPC/ROP-lastige Workloads kann man sicherlich auch auf deutlich über 900MHz boosten.

Welche z.B.? Ich dachte wir sind heute komplett von der Rechenleistung limitiert (außer dem Chip geht die Bandbreite aus).

Bekommt man die TDP irgendwie raus oder kann man zu 99% sicher annehmen, dass es nur 225W sind?

fondness

2012-10-31, 10:28:18

oder kann man zu 99% sicher annehmen, dass es nur 225W sind?

Ja.

boxleitnerb

2012-10-31, 10:39:42

Dann könnten in der aktuellen Form GK110 und GK104 ähnliche Energieeffizienz besitzen. Das hätte ich so nicht erwartet.

fondness

2012-10-31, 10:48:57

Dann könnten in der aktuellen Form GK110 und GK104 ähnliche Energieeffizienz besitzen. Das hätte ich so nicht erwartet.

Niedriger Takt mit mehr Einheiten ist eben deutlich Energieeffizienter als weniger Einheiten hoch zu takten, da man die Spannung (die ja quadratisch in die Leistungsaufnahme mit einfließt) niedriger ansetzen kann. Der Rest geht dann für den HPC-Ballast und den Mehrspreicher drauf.

Skysnake

2012-10-31, 13:07:23

Welche z.B.? Ich dachte wir sind heute komplett von der Rechenleistung limitiert (außer dem Chip geht die Bandbreite aus).

Bekommt man die TDP irgendwie raus oder kann man zu 99% sicher annehmen, dass es nur 225W sind?

Dann lag Ailuros mit 14 SMX und 750 MHz ja fast goldrichtig.

Damit liegen 15 SMX mit 800+ MHz problemlos in Reichweite für 250W. Da man weniger Speicher verbaut, vielleicht gar 850 MHz.

Du vergisst aber die Last auf den Rasterizer usw, der unter Spielelast dazu kommt. Und 1 SMX mehr sind 7% ALUs mehr. Da wirste kaum 100 MHz, was hier ja gut 13% mehr Takt. Wie willst du das bei vielleicht 25W mehr Verbrauch unter bekommen?

Zumal man erst mal keine 15 SMX Versionen haben wird, und wenn werden die nicht sonderlich taktfreudig sein.

Also bei 15SMX und 850W wird man wohl eher in die Richtung 300W gehen, wenn nicht mehr.

Botcruscher

2012-10-31, 13:12:11

Niedriger Takt mit mehr Einheiten ist eben deutlich Energieeffizienter als weniger Einheiten hoch zu takten, da man die Spannung (die ja quadratisch in die Leistungsaufnahme mit einfließt) niedriger ansetzen kann.

Dafür hat man deutlich mehr Leckströme und die Herstellungsschwankungen hauen auch deutlich mehr rein. Da 28nm Karten immer noch teurer sind, wäre ich da nicht zu optimistisch.

Godmode

2012-10-31, 13:18:22

boxleitnerb

2012-10-31, 13:20:29

Du vergisst aber die Last auf den Rasterizer usw, der unter Spielelast dazu kommt. Und 1 SMX mehr sind 7% ALUs mehr. Da wirste kaum 100 MHz, was hier ja gut 13% mehr Takt. Wie willst du das bei vielleicht 25W mehr Verbrauch unter bekommen?

Zumal man erst mal keine 15 SMX Versionen haben wird, und wenn werden die nicht sonderlich taktfreudig sein.

Also bei 15SMX und 850W wird man wohl eher in die Richtung 300W gehen, wenn nicht mehr.

Erstens ist TDP nicht gleich Verbrauch. K20 in der Form kann real ja auch 200W statt 225 verbrauchen, wer weiß das schon? Zweitens hat laut Ailuros die Anzahl der SMX im Verhältnis zum Takt (durch Spannungserhöhung) wenig Auswirkungen auf die Leistungsaufnahme. Für 3GB GDDR5 darfst sicher nochmal 15W abziehen, evtl. gar mehr.

Beispiel GTX570 und GTX580. Unterschied im Spielebetrieb nur 32W, wobei eben die 580 mehr Speicher hat und nicht halb soviel wie es bei der GTX780 vs. K20 der Fall sein wird. Auch ist K20 beim Speicherinterface und bei den ROPs nicht teildeaktiviert im Gegensatz zur 570. Da finde ich deine Spekulation doch etwas daneben mit den 300W und mehr ;)

http://www.3dcenter.org/artikel/eine-neubetrachtung-des-grafikkarten-stromverbrauchs/eine-neubetrachtung-des-grafikkarten-st

Wo ist deine Quelle dafür, dass es keinen 15 SMX Part geben wird? Natürlich werden das nur wenige funktionsfähige Dies sein, aber die wird Nvidia kaum wegwerfen.

Skysnake

2012-10-31, 13:40:42

Wenn was daneben ist, dann deine Unterstellung...

Ich hab gesagt "eher in die Richtung 300W" wo liest du da bitte 300W und mehr???

280W sind auch "eher in die Richtung 300W" als 250W.... Nur mal so...

Ich hab mit keinem Wort gesagt, das es 300W oder mehr sind.

"eher in die Richtung 300W" sind ~275 bis 325W Nicht mehr und nicht weniger....

Und zudem solltest du auch bitte die Sachen verstehen, die du liest.

Mehr Einheiten sind tendenziell effizienter, weil du den Takt NIEDRIGER ansetzen kannst...

Hier will man aber MEHR Einheiten und MEHR Takt... Mehr Einheiten bei gleichem Takt benötigen tendenziell auch mehr Spannung. Das muss nicht sein, aber ist öfters so. Vor allem, wenn man eh schon Probleme mit der Fertigung hat. Du musst ja immer für die schlechtesten Transistoren die Spannng wählen, und je mehr Einheiten du hast, desto größer ist die Wahrscheinlichkeit, dass du eben auch welche dabei hast, die mehr Spannung brauchen.

Ganz zu schweigen davon, dass du mit mehr aktiven Einheiten auch mehr Belastung auf der On-Core Spannungsversorgung. Das kann insbesondere beim Idle->Volllast Lastwechsel dazu führen, dass die Spannung weiter absinkt, als bei weniger Einheiten, was dann wiederum zur Folge hat, dass du mehr Spannung anlegen musst.

usw usw usw usw.

Es gibt da so UNGLAUBLICH viele Faktoren, die dafür sorgen können, dass die Leistungsaufnahme explodert. Bei ner 1A funktionierenden Fertigung, wo du keine Probleme mit den Yealds hast, sind die Probleme kleiner, wenn du aber eh schon Probleme hast, musst du oft die VCore halt noch etwas höher setzen, um genug Binning-Yeald zu erhalten...

Du erkenst das Problem?

Schau mal in die Vergangenheit, wie viele Chips es gibt, die schon bei kleinen Taktsteigerungen extrem viel mehr VCore brauchen, oder auch so "einfach" bei der Leistungsaufnahme regelrecht explodieren.

Und wie gesagt, ~7% mehr ALUs und ~13% mehr Takt sind kein Pappenstiel...

Und bzgl. TDP<->Verbrauch. Ja das Verbrauch != TPD ist, ist mir klar, wer hätte das gedacht... :freak:

Gerade bei den HPC-Kisten von nVidia hat man zuletzt auch die "TDP" voll ausgereizt.

boxleitnerb

2012-10-31, 13:51:53

wohl eher in die Richtung 300W gehen, wenn nicht mehr

Hust :)
Sei doch nicht so gereizt, du hast das schließlich selbst gesagt, da muss ich nix unterstellen.

Mehr Takt -> Mehr Verbrauch ist klar, du musst mich nicht belehren. Auf meine Ausführungen bzgl. Teildeaktivierungen und VRAM-Menge bist du ja auch überhaupt nicht eingegangen.

So oder so wird man den Sweetspot finden, wo man in etwa soviel verbraucht wie dies bei einer 580 der Fall ist.

P.S. Es heißt "Yields", nicht "Yealds"

Skysnake

2012-10-31, 14:03:21

Der VRAM wird bei der Desktop-Version wahrscheinlich auch wieder etwas höher getaktet sein. Das frisst auch wieder etwas mehr Strom.

Wie groß der Speicherausbau wird muss sich halt auch erst zeigen. Aber ja, man spart einige Watt ein, wahrscheinlich sogar >10W. Man sollte aber nicht die große Taktsteigerung + 1 SMX mehr aus den Augen verlieren.

Das ist nen Monster Chip, und nVidia bringt trotz einer schon ein Jahr laufenden Fertigung nur ne 14 SMX Version für den HPC. Und gerade da bringt man das was geht.

Vergleich das mal mit dem 40nm Prozess. Da hatte man am Anfang auch seine Probleme, aber nach nem Jahr war da eigentlich alles in Butter.

nVidia bringt ja nicht zum Spaß ne 14 SMX Version. Wenn würden die lieber ne 15SMX Version mit etwas niedrigerem Takt bringen, um die Effizienz zu steigern. Ich bezweifle leider noch immer, das nVidia ihre Effizienzversprechungen wirklich einhalten kann.

boxleitnerb

2012-10-31, 14:11:10

Bei HPC bringt man nicht "was geht". Man bringt das, was man in Massen liefern kann. Ich glaube nicht, dass Nvidia 20,000 15 SMX-K20 hätte liefern können. Jedenfalls nicht so schnell oder zu dem Preis. Ailuros rechnet doch so gerne die Waferkosten vor, ich hab aufgepasst :D

Wenn nur 10 15 SMX-Parts vom Wafer fallen, aber 30 14 SMX-Parts und du schnell liefern musst, um Intel und AMD zuvorzukommen und Verträge zu erfüllen, nimmst du natürlich 14 SMX. Mischen geht auch nicht, nein.

Übrigens wird der 28nm-Prozess bei GTX780-Launch auch ein Jahr alt sein, sogar eher 15 Monate (ab 7970 Launch gezählt, ich rechne mit Februar/März für die 780). Es bleibt also noch gut Zeit zum Optimieren.

Hübie

2012-10-31, 23:47:22

K20 hat 6+2 Phasen bei 6+8 Spannungsversorgung. Deutet schon stark darauf hin dass wir die Marke vom GF110 nicht weit überschreiten werden. Zumindest nicht wenn man an Spannungsqualität Einbußen hin nimmt. GF110 hat 6+2 @ 8+6 PCIe-Stromversorgung während GK104 4+2 hat.
@Gipsel: Erste Benches wurden schon gefahren.

Ailuros

2012-11-01, 01:42:29

Der VRAM wird bei der Desktop-Version wahrscheinlich auch wieder etwas höher getaktet sein. Das frisst auch wieder etwas mehr Strom.

Sicher.

Wie groß der Speicherausbau wird muss sich halt auch erst zeigen. Aber ja, man spart einige Watt ein, wahrscheinlich sogar >10W.

Wenn die Anzahl der speicherchips zwischen 3 und 6GB Speicher als Beispiel gleich ist spart man wie viel genau?

Man sollte aber nicht die große Taktsteigerung + 1 SMX mehr aus den Augen verlieren.

Takt ja, 1 SMX nicht nennenswert. Das Pech ist eben dass alle salvage parts weniger operative clusters haben als die chips im Vollausbau und gleichzeitig niedrigeren Takt. Den eigentlichen Unterschied macht in solch einem Fall die Frequenz und nicht der 1 cluster.

Das ist nen Monster Chip, und nVidia bringt trotz einer schon ein Jahr laufenden Fertigung nur ne 14 SMX Version für den HPC. Und gerade da bringt man das was geht.

Tape out Anfang Maerz 2012; Produktions-start Anfang September 2012 = right on schedule ohne jegliche Verzoegerung. Nochmal wieso sind auf XeonPHi nicht stets alle 64 cores operativ?

Vergleich das mal mit dem 40nm Prozess. Da hatte man am Anfang auch seine Probleme, aber nach nem Jahr war da eigentlich alles in Butter.

Ich kann den Mist so langsam nicht mehr lesen ueberhaupt wenn dieses schon etliche Male erklaert wurde: GF100= problematische hw.

GF100= 15 SMs@700MHz = 250W
GF110= 16 SMs@770MHz = 244W

GF110 kam eben NICHT ein Jahr spaeter an sondern weniger und waehrend er irgendwo 15% an Leistung zulegte war der Verbrauch um einen Tropfen kleiner. Cayman hingegen war ungefaehr um das gleiche Prozentual schneller als Cypress (ja beide unter 40G) jedoch war der Stromverbrauch auf dem ersten sehenswert hoeher.

nVidia bringt ja nicht zum Spaß ne 14 SMX Version. Wenn würden die lieber ne 15SMX Version mit etwas niedrigerem Takt bringen, um die Effizienz zu steigern. Ich bezweifle leider noch immer, das nVidia ihre Effizienzversprechungen wirklich einhalten kann.

Von Maerz 2012 bis zu Anfang 2013 gibt es genug Zeit nicht fuer einen sondern zwei hypothetische metal spins. Zweifel sind zwar gerechtfertigt aber es gibt immer noch momentan keine beunruhigenden Indizien, wenn Oak Ridge K20 SKUs auch wirklich mit 14 SMX auf 732MHz liegen.

Aber nochmal die schoene alte Vergleichsuebung aus der Vergangenheit:

GF100/Tesla = 14SMs@515MHz/3GB = 238W TDP
GF100/GTX480 = 15SMs@700MHz/3GB = 250W TDP
------------------------------------------------------------------

GF110/Tesla = 16SMs@665MHz/6GB = 225W TDP
GF110/GTX580 = 16SMs@772MHz/3GB = 244W TDP

Taktunterschied bei GF110 = 16%
732MHz + 16% = 849MHz

Sonst noch etwas weniger relevantes:

GTX680 = 1006/1500MHz/2GB = 195W TDP
GTX690 (2*GK104) = 915/1500MHz/4GB = 300W TDP

Tesla K10 (2*GK104) = 745MHz/1250MHz/8GB = 225W TDP

-------------------------------------------------------------------------------------------

boxleiternerb,

Der Kredit geht nicht an mich sondern an jemand anders. Wort fuer wort:

I'm positive on 14SMX and 225W TDP. Frequency should be in the high 700s but I'm not completely sure.

Ich hab auch ein klein bisschen etwas ueber die pro core eingeschaetzten Kosten am Anfang, aber ich behalt es momentan fuer mich. Ganz einfach: fuer desktop waere so etwas Selbstmord gewesen in Q3 2012.

=Floi=

2012-11-01, 02:15:00

wird es bei kepler dann wieder einen refresh geben?
hat nv die "lebensdauer" ihrer chips auf mittlerweile 2 jahre ausgelegt?

Ailuros

2012-11-01, 02:34:40

wird es bei kepler dann wieder einen refresh geben?
hat nv die "lebensdauer" ihrer chips auf mittlerweile 2 jahre ausgelegt?

Einen Refresh fuer alles GK10x wird es wohl schon geben, aber fuer GK110 wohl schwer.

horn 12

2012-11-01, 03:17:35

Nun, GK110 wird sich wohl auch "einige Zähne ausbeißen" beim Tahiti Refresh, sprich HD8000-er Serie!
Derzeit sind wohl GTX 680 und HD7970 gleichauf.

Dies dazu dass AMD nicht vorgelegt hat.
Wird sicher spannend im Februar/ März, Rechne ein Kopf an Kopf Rennen wirds schlussendlich werden. In Tahit steckt noch Ordentlich Potential, hoffe dies kann AMD nun auch uendlich mal umsetzen!

Hugo78

2012-11-01, 05:18:40

Wenn die HD8k wirklich nur 15% schneller sein sollte, könnte NV im Desktop auch nur mit einer 13 SMX Version antretten und ende 2013 nochmal ein 15SMX "Refresh" als Top Dog für Weihnachten nachschieben.
Man hätte ne gute Yield und auch ne schön lange Zeit zum sammeln.
Maxwell wird eh nicht vor 2014 kommen.

boxleitnerb

2012-11-01, 07:56:39

Ich hab auch ein klein bisschen etwas ueber die pro core eingeschaetzten Kosten am Anfang, aber ich behalt es momentan fuer mich. Ganz einfach: fuer desktop waere so etwas Selbstmord gewesen in Q3 2012.

Liegt das eher an den im Vergleich zu 40nm (viel?) teureren Wafern oder an den schlechteren Yields? Selbstmord klingt ja schon ziemlich drastisch - würden die Yields so sehr steigen können von "Selbstmord" zu "launchfähig" (sagen wir 150 Dollar pro core) in nur einem halben Jahr (ich gehe von Launch in Q1 2013 aus)?

Edit:
Weiß jemand (genau) wieviel 3GB GDDR5 auf aktuellen Karten so verbrauchen? Also bei maximaler Belastung, 8xMSAA oder so.

horn 12

2012-11-01, 09:02:28

Mit Optimierung des Chips und weiters des Treibers sind ca. 25-30% locker drinnen, bezogen auf Tahiti X2.

boxleitnerb

2012-11-01, 09:03:07

Mit Optimierung des Chips und weiters des Treibers sind ca. 25-30% locker drinnen, bezogen auf Tahiti X2.

Falscher Thread? Wenn du AMD loben willst, mach das bitte woanders. Der nächste Post dieser Art wird gemeldet.

Skysnake

2012-11-01, 11:31:01

Ailuros,

nochmal, mir sind die Unterschiede GF100<->GK110 voll auf bewusst.;)

Ich bin bei solchen Monsterchips nur SEHR konservativ und vorsichtig geworden. Es kann alles gut gehen, man kann nen Metal-Spin bringen, der eventuell Fehler ausschließt, usw usw.

Es kann aber auch einfach nen Fehler vermutet werden, und dann am Ende doch was anderes gewesen sein, was man nicht sieht, oder einfach Fertigungsschwankungen oder oder oder.

nVidia ist für mich einfach viel zu ruhig, und was man hört ist halt alles suboptimal.

Und bzgl nVidia<->Intel (XeonPhi) habe ich die gleichen schlechten Gefühle, auch wenn zu großem Teil aus unterschiedlichen Gründen. Ein Teil, den beide sich wohl teilen ist, dass es beides echte Monsterchips sind, die nicht sonderlich sparsam daher kommen, und nicht wirklich einfach zu fertigen sind.

Nicht sparsam ist ja nicht sooo sehr das Problem, wenn genug Bumbs dabei rum kommt. Und das seh ich bei nVidia deutlich optimistischer als bei Intel. Aber das ist ein ganz anderer Aspekt.

nVidia und Intel vesprechen bei ihren Produkten viel, aber was dabei am Ende rum kommt muss sich erst noch zeigen. Was bringt mir ne 1A Technik, wenn ich die Chips einfach nicht gefertigt bekomme?

Da muss ja nicht mal nVidia dran schuld sein am Ende. Den Schadenhaben Sie aber auf jeden Fall.

Und bzgl. deiner "Selbstmordaussage":
Ich glaube auch, dass die bei nVidia ziemlich graue Haare (bekommen) haben.

Hop und Flop liegen in dem Bereich nahe beeinander.

Hübie

2012-11-01, 11:39:38

@horn 12: Die kaum verfügbare Gigawatt-Edition ist schneller als GTX 680. Ur-Tahiti und GK104 sind gleich auf, dass stimmt so. Was diese Aussagen hier in dem Kontext zu suchen haben ist mir aber auch gerade nicht ganz klar.

@boxleitnerb: VRAM-Verbrauchsmessungen wurden nie konsequent genug durchgeführt, da du ein Tool schreiben müsstest mit dem du Teile des SI blockierst, so dass keine Daten von GPU zu RAM-Chip wandern. Afaik gibts so etwas nicht. Mal skysnake fragen ob er so etwas hinbekäme (bin mir nicht mal sicher ob so etwas überhaupt ginge...).

@skysnake: Wenn man vom Teufel redet ... ;D

Lass GF100 mal raus. GK110 hat keinerlei Probleme wie Fermi damals. Der vergleich hinkt. Ziehe - wenn - GF110 ran.

Skysnake

2012-11-01, 11:59:53

Das ließe sich schon machen. Das Problem ist da eher das programm auch lang genug laufen zu lassen :ugly:

Ich schau mal ob ich die nächsten Tage da was hin bekomme. Ich würd aber eher mal schauen, was die Chiphersteller angeben.

Da unterschlägt man aber leider die Stromkosten des Speichercontrollers...

Noch was zu GF100<->GK110
Ich sag doch, dass man das nicht 1:1 vergleichen kann. Aber meinste nVidia hat sich das mit GF100 so vorgestellt und genau so geplant? ;)

Sicher nicht, aber das Zeug ist halt nicht wirklich trivial. Und GK110 würde ich jetzt nicht als einfacher betrachten ;)

Die Jungs UND Mädels bei nVidia sind auch nur Menschen! Du kannst so viel wollen wie du willst, aber manchmal gehts halt einfach nicht. Daher sollte man auch nicht ZU optimistisch sein, das man Probleme einfach so löst.

Wie Ailuros sagt, es kann durchaus schon Metal-Spins gegeben haben, das heißt aber nicht, das man die Ursache für die 14 statt 15 SMX beseitigt hat. Ein Fix kann auch an anderer Stelle ein neues Problem bringen. Man sollte sich daher auf das Verlassen, was man hat. Mir geht es halt nur auf die Zeiger, das gleich wieder von was weiß ich wieviel mehr Takt und 15 SMX Versionen geredet wird, und wie das den einen oder anderen zerbersten wird....

Was hat man von GK100 (:rolleyes:) gelesen und wie nVidia damit alles zerfetzen wird...
Was hat man von Larrabee, äh KNF, ach ich meine KNC,... MIC ? wa auch net? Na dann halt XeonPhi alles gehört? Ailuros hat das absolut richtig angesprochen. Intel hat wohl keine voll funktionsfähigen/aktiven Chips am start.... Will jemand behaupten Intel wäre halt nen crape Hersteller?
Bei nVidia und TSMC soll aber alles wunderbar wie geschmiert laufen und alles ohne Probleme genau so umgesetzt werden, we man sich das ausmalt...

Wir haben heute einfach eine andere Situation als früher. Die Tolleranzen sind winzig geworden, und wo man früher auch mal bischen an der Verbrauchsschraube drehen konnte, bricht einem das schnell das Genick, denn Leistung allein interessiert nicht mehr so stark wie früher. Da interessiert die Effizienz, und da kannste halt nur in geringem Maße einen Rückstand durch einen Vorsprung bei der absoluten Leistung noch rechtfertigen.

Mir sind die Hersteller (Intel und nVidia vor allem), viel zu optimistisch. Wie oft musste man sich denn in letzter Zeit korrigieren? Ich versteh da die Marketingfutzis einfach nicht. Ich sag doch am Ende lieber: "Hey schau mal wir sind sogar noch x% besser" Als später zu sagen:"Ja äh.... wir haben ja gesagt, das wir das und das können, aber ähm... Es gab "unerwartete" Probleme, wir schaffen das leider jetzt doch nicht" :ugly:

Klar, man muss schon eine realistische Aussicht machen, und davon ausgehen, das man gewisse Probleme halt einfach gelöst bekommt, bei denen man noch keine Ahnung hat, wie das funktionieren soll, aber zumindest auf mich macht es den Eindruck, als ob die von den Ingenieuren teilweise unmögliches verlangen/erwarten. Als ob man alles ausreizen müsste was geht. Wird schon gut gehen...

Ist der Konkurrenzdruck derart stark geworden?

boxleitnerb

2012-11-01, 12:02:48

Ursache für die 14 statt 15 SMX

Was willst du immer damit? Es ist völlig logisch, dass man IMMER weniger volle Chips von einem Wafer runterbekommt als welche mit Macken, wo man Teile abschalten muss. Und daraus folgt, dass man wenn man viele von einer Sorte braucht (und ja, 20,000 Chips ist 6 Monate nach Tapeout "viele" imo), man eben die nimmt, von denen man am meisten bekommt pro Wafer. Das wurde doch jetzt schon öfter vorgerechnet...

Dural

2012-11-01, 14:02:22

ich denke GK110 läuft für einen noch recht neuen Prozess und der Grösse sogar ziemlich gut. auf jeden fall besser als damals der GF100 ;)

NV hat derzeit einfach keine eile das ding in den Desktop Markt rein zuhauen, wie so auch wenn man mit 2x300mm2 1000.- Dollar verlangen kann... :rolleyes:

OgrEGT

2012-11-01, 14:07:40

Wenn man es mal von der Seite sieht, wieviel GK110@15SMX 800MHz sind bei der bis dato laufenden Produktion angefallen?
ca. 20000 für K20 Tesla.
Könnten vielleicht schon 1000 sein, oder mehr?

Skysnake

2012-11-01, 14:08:25

Was willst du immer damit? Es ist völlig logisch, dass man IMMER weniger volle Chips von einem Wafer runterbekommt als welche mit Macken, wo man Teile abschalten muss. Und daraus folgt, dass man wenn man viele von einer Sorte braucht (und ja, 20,000 Chips ist 6 Monate nach Tapeout "viele" imo), man eben die nimmt, von denen man am meisten bekommt pro Wafer. Das wurde doch jetzt schon öfter vorgerechnet...

Und wann war es das letzte mal, das es deratige Probleme mit Chips gab bei einem Prozess, der im Massenmarkt mit Chips von ~350mm² scheinbar ohne wirkliche Probleme läuft?

Wenn die 14SMX Version im Februar oder Juni gekommen wäre kein Ding, aber jetzt? Und vor allem für so nen werbewirksamen Deal wie wie OakRidge wird man doch alles tun, um möglichst gut da zu stehen.

Wie gesagt, ich bin da immer noch SEHR skeptisch. Ich lasse mich aber gern positiv überraschen ;)

boxleitnerb

2012-11-01, 14:41:33

Und wann war es das letzte mal, das es deratige Probleme mit Chips gab bei einem Prozess, der im Massenmarkt mit Chips von ~350mm² scheinbar ohne wirkliche Probleme läuft?

Wenn die 14SMX Version im Februar oder Juni gekommen wäre kein Ding, aber jetzt? Und vor allem für so nen werbewirksamen Deal wie wie OakRidge wird man doch alles tun, um möglichst gut da zu stehen.

Wie gesagt, ich bin da immer noch SEHR skeptisch. Ich lasse mich aber gern positiv überraschen ;)

Was für Probleme?
Im Februar??? Wann bitte schön kam so ein großer Chip jemals so früh? Bisher vergingen immer mindestens 9 Monate von den allerersten Produkten (8800GT 65nm, HD4770 40nm und jetzt HD7970 28nm), bis der Prozess soweit war, dass man da 500mm2 Chips herstellen konnte. Jetzt rechnen wir mal von Januar ab, die K20-GPUs werden sicherlich nicht erst eine Woche vor Einbau hergestellt worden sein, also passt September doch ganz gut.

Ich weiß ja nicht, was du für verquere Vorstellungen hast, aber das Ziel einer Firma ist immer noch vorrangig, Gewinn zu erwirtschaften. Und das beißt sich, wenn man den Chip zu früh bringt, 80% wegschmeißen kann und die (immer teurer werdenden) Wafer trotzdem zahlen muss.

Alle denken immer, GK110 kommt so spät, dabei stimmt das gar nicht. GK104 kommt früh - das ist was völlig anderes. Der große Chip kommt nicht früher oder später als das bei vorherigen Generationen auch der Fall war, mit einem wichtigen Unterschied:

Die Priorität liegt jetzt dem Profisegment, nicht beim Desktop. Das muss auch so sein, denn

kann Nvidia mit dem kleinen GK104 gut die Stellung halten und mehr Gewinn machen. Für eine GTX780 besteht aktuell kein Bedarf (man müsste außerdem das gesamte Portfolio preislich auch nach unten rücken, was einen Arsch voll Geld kostet. Die 780 für 800 Dollar obendraufsetzen klappt nicht, wer kauft sowas?). Die 680 wird wie üblich ca. ein Jahr lang auf dem Markt sein, bis durch Sea Islands ein Konter nötig wird.
machen es die teureren Wafer noch wichtiger, das Geld nicht zum Fenster rauszuwerfen. Selbst bei gleichen Yields wie bei 40nm machen die hohen Waferkosten den Chip unweigerlich teurer. Wenn die Karte nur 500 Dollar kosten darf, tut das ziemlich weh. Wenn die Karte aber für 2000+ Dollar vertickt wird, ist der Preis erträglicher, zumal hier auch wirklich Konkurrenzdruck seitens AMD und Intel besteht.

Ailuros

2012-11-01, 17:01:07

Liegt das eher an den im Vergleich zu 40nm (viel?) teureren Wafern oder an den schlechteren Yields? Selbstmord klingt ja schon ziemlich drastisch - würden die Yields so sehr steigen können von "Selbstmord" zu "launchfähig" (sagen wir 150 Dollar pro core) in nur einem halben Jahr (ich gehe von Launch in Q1 2013 aus)?

Edit:
Weiß jemand (genau) wieviel 3GB GDDR5 auf aktuellen Karten so verbrauchen? Also bei maximaler Belastung, 8xMSAA oder so.

Beides. Haette NV in Q3 09' GF100 hergestellt haette es weniger gekostet als GK110 im September 12'.

Noch was zu GF100<->GK110
Ich sag doch, dass man das nicht 1:1 vergleichen kann. Aber meinste nVidia hat sich das mit GF100 so vorgestellt und genau so geplant? ;)

Das interdie connect Problem wurde erst beim start der Massenproduktion des GF100 entdeckt.

Sicher nicht, aber das Zeug ist halt nicht wirklich trivial. Und GK110 würde ich jetzt nicht als einfacher betrachten ;)

Es gibt tonneweise mehr Probleme die eher mit dem Prozess/Foundry/Herstellungskosten verbunden sind als alles andere. Genau aus dem Grund sind sie auch mit Kepler so vorgegangen und haben den top dog fast als letzten zum tape out getrieben. Bis zu GF110 war der design so ausgelegt dass sie auf den top dog tape out warten mussten um nach diesem die kleineren cores fertig zu backen. Bei Kepler eben nicht der Fall.

Die Jungs UND Mädels bei nVidia sind auch nur Menschen! Du kannst so viel wollen wie du willst, aber manchmal gehts halt einfach nicht. Daher sollte man auch nicht ZU optimistisch sein, das man Probleme einfach so löst.

Sicher; nur aendert es sich nichts daran dass die bisherigen Indizien eben nicht miserabel zu sein scheinen. Uebertriebener Pessimismus ist genauso ungerechtfertigt wie uebertriebener Optimismus. Ich bevorzuge eine konservativ logische Masche; nichtdestominder hab ich auch mehrere Male den Optimismus mancher NICHT geteilt dass wenn GK110 desktop erscheint er wohl leicht ueber 900MHz takten wird. Moeglich schon wenn einem yields, Stromverbrauch und Endpreis total egal sind.

Wie Ailuros sagt, es kann durchaus schon Metal-Spins gegeben haben, das heißt aber nicht, das man die Ursache für die 14 statt 15 SMX beseitigt hat. Ein Fix kann auch an anderer Stelle ein neues Problem bringen. Man sollte sich daher auf das Verlassen, was man hat. Mir geht es halt nur auf die Zeiger, das gleich wieder von was weiß ich wieviel mehr Takt und 15 SMX Versionen geredet wird, und wie das den einen oder anderen zerbersten wird....

Nochmal ein so hochkomplizierter chip kann beim allerersten run nicht genug 15 SMX binning yields haben um grosse deals decken zu koennen. Ist auch bei Intel nicht anders denen konstant der Prozess-vorteil zugerechnet wird. Willst Du garantieren dass man mit GK110 eventuell nicht 15 SMX oder von Xeon Phi nicht 64 cores mit dem Lauf der Zeit herstellen kann weil die Designs verpatzt sind?

Unter normalen Umstaenden braucht man keinen "fix" dafuer nur niedrigere Herstellungskosten bzw. hoehere yields.

Was hat man von GK100 (:rolleyes:) gelesen und wie nVidia damit alles zerfetzen wird...

Es hat NIE einen GK100 gegeben :P

Was hat man von Larrabee, äh KNF, ach ich meine KNC,... MIC ? wa auch net? Na dann halt XeonPhi alles gehört? Ailuros hat das absolut richtig angesprochen. Intel hat wohl keine voll funktionsfähigen/aktiven Chips am start.... Will jemand behaupten Intel wäre halt nen crape Hersteller?
Bei nVidia und TSMC soll aber alles wunderbar wie geschmiert laufen und alles ohne Probleme genau so umgesetzt werden, we man sich das ausmalt...

Wenn nichts krummes an Phi liegt (errr wieso auch nach der unendlichen Zeit an dem sie an der Grundarchitektur herumwurschteln?) darfst Du Gift drauf nehmen dass es nicht all zu lange von heute auch 64 core Varianten davon geben wird. Und wenn es schon sein muss der originale LRB wurde aufgegeben weil man nach 11 chip Revisionen immer noch nicht die Hitze bei voller Auslastung kontrollieren konnte. NV hat zwar NV30 Leichen als Beispiel in ihrem Keller aber so verdammt miserabel war es nie.

Klar, man muss schon eine realistische Aussicht machen, und davon ausgehen, das man gewisse Probleme halt einfach gelöst bekommt, bei denen man noch keine Ahnung hat, wie das funktionieren soll, aber zumindest auf mich macht es den Eindruck, als ob die von den Ingenieuren teilweise unmögliches verlangen/erwarten. Als ob man alles ausreizen müsste was geht. Wird schon gut gehen...

Ich sehe keinen Pessimismus momentan beim engineering team.

Ist der Konkurrenzdruck derart stark geworden?

Nein die Resourcen sind verdammt enger geworden eben weil es wirklich keinem heutzutage blendend geht. In dem Fall ist die Herstellungs-Problematik sogar eine Eulogie fuer die IHVs weil man eben nichts dagegen einzuwenden hat. Stell Dir vor wie es brodeln wuerde wenn es kein Problem mit Prozessen geben wuerde und IHVs wuerden so wie heute (stets in relativem Sinn) nur so vor sich hintrotteln.

Geschichtlicher backflash: als NV einsah dass es mit Fermi/40G usw. nicht gut gehen kann, wurden sofort radikale Massnahmen gezogen und es wurden unendliche engineers von anderen Abteilungen angesammelt um GF110 so schnell wie moeglich auf die Beine zu bekommen, um Kepler so umzukrempeln dass der top dog keine Prioritaet mehr haben muss und um zum Wandel fuer 28nm so schmerzlos wie moeglich zu kommen. Wer sich mit der ULP GF in den Tegra SoCs auskennt wird wohl wissen dass die ULP GF GPUs dort zwischen Tegra1 und dem heutigen Tegra3 nur marginale Aenderungen gesehen haben. Wenn man dem GPU Entwicklungsteam dort nur weniger als eine Handvoll an engineers uebrig laesst soll was genau daraus kommen?

Jetzt kommt aber gleich die naechste Problematik, denn man kann eben Abteilungen wie Tegra fuer die man sich irgendwann in der Zukunft 50% des insgesamten Umsatzes hervorsieht eben NICHT weiterhin so vor sich hin trottlen lassen, ergo gingen vor einiger Zeit die zusaetzlichen Resourcen wieder zurueck da wo sie hin gehoerten. Noch weiter wer soll den sonst Projekt Denver von der anderen Seite und auch die server ARM basierenden CPUs von NVIDIA genau fertigstellen. Ueberhaupt Denver ist leider eine unendlich Disaster-Geschichte wo das obrige Management sich einige Male ueber andere Direktionen entschied; und eben nicht einfaches Zeug sondern so radikal dass jegliche bisherige Vorarbeit einfach nutzlos wurde. Schon alleine die Tatsache dass NV die Resourcen zurueckgeleitet hat, sollte Dir sagen dass sie momentan nicht in einer alarmierenden Situation sind was high end GPU designs betrifft.

AMD ist eigentlich das groesste Opfer an der ganzen Geschichte und ich bin mir nicht soooo sicher dass die Aenderungen ihrer Strategie MIT der brutalen Reduzierung von engineering Resourcen wirklich so gut laufen koennte wie sich einige alberne Management-Heinis einfach nur so vorstellen.

Intel muss lediglich zusehen dass sie es endlich schaffen ihre verdammten Herstellungsprozesse so anzupassen dass jegliche darunter hergestellte GPU eben nicht unter brutalem Stromverbrauch bzw. uebermaessig grosser die area leidet. Ab Haswell soll es losgehen, aber es ist etwas dass schon seit einige Jahren faellig ist.

My 2 cents (obwohl die Mehrzahl vom obrigen schon zich Male wiedergekaut wurde).

Schaffe89

2012-11-01, 18:05:30

Es hat NIE einen GK100 gegeben

Woher die Sicherheit?

Ailuros

2012-11-01, 18:19:23

Woher die Sicherheit?

Die einzige Architektur die storniert wurde war ein relativ altes 32nm/TSMC Projekt das nie zum tape out kam. Es war ein Fermi uncore mit Kepler ALUs und hatte eben nicht einen "GKxxx" sondern "GFxxx" codenamen. Nicht das ich dieses auch nicht schon etliche Male wiederholt habe, aber das Zeug in meinem vorigen Post wieso es NUR einen GK110 gibt der von Anfang an fuer spaeter geplant war, ist auch um Nx Mal wiederholt.

Allerster Kepler tapeout war GK107 und dieser war fuer mobilen Scheiss schon vor Weihnachten 2011 in Partner Haenden. GK104 hatte seinen tape out im Oktober 2011 und GK110 im Maerz 2012. Und komm mir nicht wieder mit der albernen "1" in der Mitte vom 110, ich kann die Laier wirklich nicht nochmal erklaeren.

boxleitnerb

2012-11-01, 18:29:08

als NV einsah dass es mit Fermi/40G usw. nicht gut gehen kann, wurden sofort radikale Massnahmen gezogen

Nvidia wäre schön blöd, wenn sie mit 28nm den Scheiß nochmal machen würden. Manche Fehler macht man nur einmal (im Jahrzehnt :D). Erstaunlich, dass einige noch denken, es hätte einen GK100 gegeben. Wenn man damit einmal auf die Fresse fliegt, überlegt man sich gleich, was man nächstes Mal besser machen kann.

Skysnake

2012-11-01, 23:36:14

Alle denken immer, GK110 kommt so spät, dabei stimmt das gar nicht. GK104 kommt früh - das ist was völlig anderes. Der große Chip kommt nicht früher oder später als das bei vorherigen Generationen auch der Fall war, mit einem wichtigen Unterschied:

Wenn man sich das mit dem Launchmuster der sonstigen GPUs anschaut, dann ist das durchaus spät.

nVidia kam nach AMD, was aber kein Ding ist. Wann kommt jetzt aber GK110, und wann kam GK104? Richtig, da liegt ne ganze menge Zeit dazwischen. Nämlich sieben Monate + x.

Was man fairerweise sagen muss ist, dass die Tesla Karten wohl früher kommen als normal. Da kam ja eigentlich immer erst die Consumer-Version und danach die Quadro/Tesla-Version. Normal hat man sich für Validierung und what ever noch alles halt mehr Zeit genommen, oder für einen gemeinsamen Launch waren die Kapazitäten nicht groß genug oder what ever...

Auf jeden Fall fällt der Druck aus dem Desktop-Markt auf jeden Fall mal weg, dafür aber eben relativ zu den Profikarten kein all zu später launch.

Aber reicht es sich da allein auf die HPC-Versionen zu beschränken um das zu beurteilen? Ich finde nicht.

Beides. Haette NV in Q3 09' GF100 hergestellt haette es weniger gekostet als GK110 im September 12'.

Das würde aber bedeuten, dass die Produktion wohl erst sehr kurz läuft, und vor allem, was war die große Veränderung im Oktober?

Oder haben die im September angefangen das auf Teufel komm raus dann durch zu drücken?

Und wenn ja, was wird sich an den Produktionskosten groß verändern in nächster Zeit (<=6Monate)?
Gibt es da wirklich so große Veränderungen, die die Produktionskosten so stark senken werden? Ich hab die Daten zu den Wafer-Preisen nicht im Kopf, es war aber glaub kein Anstieg von >50% im Vergleich zu 40nm Preisen.
Also selbst wenn die Produktionskapazitäten stark ansteigen, was Sie ja sollen, könnten die Wafer-Kosten wohl nicht so stark fallen, als das man das Ausgleichen könnte. GF100 war ja schon ziemlich krass mit den Produktionskosten wegen den schlechten Yields (ich denke du vergleichst jeweils Vollausbau). Also müssen es die Yields sein, die zu schlecht sind.

Da stellt sich natürlich sofort die Frage, wie schlecht die genau sind (nach deine Aussage müssen die abartig schlecht sein), und vor allem auch, warum ist 15SMX so schlecht, und 14 SMX dann plötzlich "vertretbar". Das die Teslas zuerst kommen zeigt wohl auch, dass die Yields noch immer misserabel sind, aber offenbar gut genug, das man die Chips bringt für OakRidge.

Das interdie connect Problem wurde erst beim start der Massenproduktion des GF100 entdeckt.

Ist mir bekannt. Sonst hätten Sie ja was dran geändert ;)

Es gibt tonneweise mehr Probleme die eher mit dem Prozess/Foundry/Herstellungskosten verbunden sind als alles andere.

Sind Sie das nicht meist auf die eine oder andere Weise immer?

Mich wunderts halt nur, das man scheinbar die aktuellen GPUs eigentlich ganz gut im Griff zu haben scheint, und wahrscheinlich ja auch schon Erfahrungen aus deren Fertigung ins Design einfließen hat lassen können. Trotzdem sind die Yields wohl ziemlich misserabel. WARUM?

Klar, es ist ein sehr großer Chip, aber das weiß man ja vorher, und wird nicht alles Spitz auf Knopf nähen, oder gar über die Vorgaben hinaus gehen (oder doch?).

Für mich stellt sich da immer die Frage: "Ist der Prozess jetzt einfach (noch) scheise,haben die Entwickler einfach zu optimistisch designed, oder waren die Constraints einfach für die Tonne"

Nochmal ein so hochkomplizierter chip kann beim allerersten run nicht genug 15 SMX binning yields haben um grosse deals decken zu koennen. Ist auch bei Intel nicht anders denen konstant der Prozess-vorteil zugerechnet wird. Willst Du garantieren dass man mit GK110 eventuell nicht 15 SMX oder von Xeon Phi nicht 64 cores mit dem Lauf der Zeit herstellen kann weil die Designs verpatzt sind?

Nein, das kann und will ich auch gar nicht. Mich wundert es nur, das man eben bei einem NICHT absolut neuen Prozess derartige Probleme hat.

Gerade am Anfang eines neuen Prozesses sollte die Lernkurve ja mit am steilsten sein, und wie schon gesagt, denke ich, dass in GK110 sogar schon echte Erfahrungen aus der 28nm Produktion eingeflossen sein sollten/könnten.

Trotzdem läufts nicht rund mit der Produktion. Hast du ja oben selbst gesagt. Was ändert sich also "kurzfristig" so "dramatisch", dass sich das Bild "komplett" wandelt?

Unter normalen Umstaenden braucht man keinen "fix" dafuer nur niedrigere Herstellungskosten bzw. hoehere yields.

Oft ja. Herstellungskosten fallen von allein durch steigende Kapazitäten oder sinkende Nachfrage.

Bei höheren Yields gibt es halt zwei Möglichkeiten:
1. Mehr Erfahrung in der Produktion
2. Ein "kleiner" Fix/Optimierung

Wenn man sich mal CPUs anschaut, und dass da durchaus öfters mal ein neues Stepping kommt, dann ist Punkt 2 wohl ein Punkt den man nicht als vernachlässigbar betrachten kann.

Es hat NIE einen GK100 gegeben :P

Wei ich doch auch :P

Soll ich jetzt noch [Ironie]-Tags dazu packen?:ugly: Das :rolleyes: hat ja wohl nicht gereicht... Ich hab doch nur den DÜNNPFIFF angesprochen...

Wenn nichts krummes an Phi liegt (errr wieso auch nach der unendlichen Zeit an dem sie an der Grundarchitektur herumwurschteln?) darfst Du Gift drauf nehmen dass es nicht all zu lange von heute auch 64 core Varianten davon geben wird. Und wenn es schon sein muss der originale LRB wurde aufgegeben weil man nach 11 chip Revisionen immer noch nicht die Hitze bei voller Auslastung kontrollieren konnte. NV hat zwar NV30 Leichen als Beispiel in ihrem Keller aber so verdammt miserabel war es nie.

Da fragt sich halt immer, was Ursache und was Wirkung ist.

Wer sagt denn, dass die Yields bei XeonPhi das Problem sind, und nicht die "Hitze"?

Ohne Vergleich/Daten von KNF, KNC "und XeonPhi" ist es halt schwer zu sagen, ob gewisse "Probleme" noch immer bestehen oder nicht.

Ich sehe keinen Pessimismus momentan beim engineering team.

Glaubste die machen sich wegen der aktuellen Situation bzgl Yields keinen Kopf (siehe deine Aussage weiter oben)? Würde mich jetzt wundern.

Falls doch hätte nVidia doch schon längst den "Schwarzen Peter" FETT auf die Stirn von TSMC gepappt..

...

Für mich liest sich das nach: "Ok, sind nur 14 SMX, aber scheis drauf, das reicht, die Konkurrenz kann auch nichts weltbewegendes bringen, also so lassen und sparen. Bringt man halt später nen 15er Refresh wenn alles läuft. Die Mittel werden wo anders gebraucht.

Intel muss lediglich zusehen dass sie es endlich schaffen ihre verdammten Herstellungsprozesse so anzupassen dass jegliche darunter hergestellte GPU eben nicht unter brutalem Stromverbrauch bzw. uebermaessig grosser die area leidet. Ab Haswell soll es losgehen, aber es ist etwas dass schon seit einige Jahren faellig ist.
Und muss man sich dann nicht mal Gedanken über die grundsätzliche Idee machen?

Ich weiß wirklich nicht, ob da der Herstellungsprozess wirklich die alleinige Ursache für diese unendliche Geschichte ist oder ob es da nicht auch grundsätzlichere Ursachen für gibt. Aber auf was die Überlegung hinausläuft wissen wir ja ;)

Ailuros

2012-11-02, 00:27:18

Das würde aber bedeuten, dass die Produktion wohl erst sehr kurz läuft, und vor allem, was war die große Veränderung im Oktober?

Produktionsstart war Anfang September, 6 Monate spaeter nach dem finalen tape out. Welche grosse Veraenderung?

Oder haben die im September angefangen das auf Teufel komm raus dann durch zu drücken?

Wenn man Dir sagt dass das Ding seinen tape out Anfang Maerz hatte, kann es einfach NICHT frueher in die Produktion gehen.

Und wenn ja, was wird sich an den Produktionskosten groß verändern in nächster Zeit (<=6Monate)?

GF100 haette im Herbst 2009 fast $200 gekostet herzustellen bei den damaligen yields und kostete bei der finalen Herstellung in Q1 2010 knapp $120/core. Cypress dass auch wirklich in Q3 2009 produziet wurde ging von ~$120/core auf ~$80/core in Q1 2010. Dabei hatte sich AMD sogar etwas unterschaetzt mit den Herstellungskosten und legt kurz nach dem launch nochmal $20 auf den MSRP vom salvage part drauf. Wie oft muss ich den Brei wiederholen?

Das die binning yields absolut beschissen waren hat nichts mit wafer yields oder der foundry zu tun. Wafer Kosten sind schaetzungsweise bei 28HP gegen 40G um ca. 30% hoeher.

Gibt es da wirklich so große Veränderungen, die die Produktionskosten so stark senken werden? Ich hab die Daten zu den Wafer-Preisen nicht im Kopf, es war aber glaub kein Anstieg von >50% im Vergleich zu 40nm Preisen.

Du solltest mal etwas vorsichtiger lesen und vielleicht etwas mehr Dein Gedaechtnis trainieren. Ehrlich.

Also selbst wenn die Produktionskapazitäten stark ansteigen, was Sie ja sollen, könnten die Wafer-Kosten wohl nicht so stark fallen, als das man das Ausgleichen könnte. GF100 war ja schon ziemlich krass mit den Produktionskosten wegen den schlechten Yields (ich denke du vergleichst jeweils Vollausbau). Also müssen es die Yields sein, die zu schlecht sind.

*seufz* zu viel Schreibfreudigkeit ueber gar nichts; siehe oben.

Da stellt sich natürlich sofort die Frage, wie schlecht die genau sind (nach deine Aussage müssen die abartig schlecht sein), und vor allem auch, warum ist 15SMX so schlecht, und 14 SMX dann plötzlich "vertretbar". Das die Teslas zuerst kommen zeigt wohl auch, dass die Yields noch immer misserabel sind, aber offenbar gut genug, das man die Chips bringt für OakRidge.

Ich schwoere ich hammer es Dir irgendwann in den Schaedel rein dass pro wafer Kosten ueberhaupt NICHTS mit binning yields zu tun haben. Wafer yields bzw. die Anzahl der operativen chips ist was die foundry etwas angeht (weil es dafuer Klausuren in Vertraegen gibt); wie viele Einheiten jetzt pro operativem chip kastriert werden ist der foundry total wurscht. Und dann beschwerst Du Dich dass ich nur so bissig werde :rolleyes:

Sind Sie das nicht meist auf die eine oder andere Weise immer?

Mich wunderts halt nur, das man scheinbar die aktuellen GPUs eigentlich ganz gut im Griff zu haben scheint, und wahrscheinlich ja auch schon Erfahrungen aus deren Fertigung ins Design einfließen hat lassen können. Trotzdem sind die Yields wohl ziemlich misserabel. WARUM?

Welche yields genau?

Klar, es ist ein sehr großer Chip, aber das weiß man ja vorher, und wird nicht alles Spitz auf Knopf nähen, oder gar über die Vorgaben hinaus gehen (oder doch?).

Für mich stellt sich da immer die Frage: "Ist der Prozess jetzt einfach (noch) scheise,haben die Entwickler einfach zu optimistisch designed, oder waren die Constraints einfach für die Tonne"

Er ist besser geworden aber noch nicht in einem Stadium einen 7.1b grossen chip bei anstaendigeren Kosten herzustellen. Das natuerlich wenn man keinen hoeheren als $500-550 MSRP dafuer erwartet naechstes Jahr.

Nein, das kann und will ich auch gar nicht. Mich wundert es nur, das man eben bei einem NICHT absolut neuen Prozess derartige Probleme hat.

Gerade am Anfang eines neuen Prozesses sollte die Lernkurve ja mit am steilsten sein, und wie schon gesagt, denke ich, dass in GK110 sogar schon echte Erfahrungen aus der 28nm Produktion eingeflossen sein sollten/könnten.

Die Produktion ist lediglich Wochen alt fuer GK110.

Trotzdem läufts nicht rund mit der Produktion. Hast du ja oben selbst gesagt. Was ändert sich also "kurzfristig" so "dramatisch", dass sich das Bild "komplett" wandelt?

Siehe oben, noch mehr weiter oben und noch mehr weiter oben.

Oft ja. Herstellungskosten fallen von allein durch steigende Kapazitäten oder sinkende Nachfrage.

Bei höheren Yields gibt es halt zwei Möglichkeiten:
1. Mehr Erfahrung in der Produktion
2. Ein "kleiner" Fix/Optimierung

Wenn man sich mal CPUs anschaut, und dass da durchaus öfters mal ein neues Stepping kommt, dann ist Punkt 2 wohl ein Punkt den man nicht als vernachlässigbar betrachten kann.

Das was Du als fix beschreibst ist ein einfacher metal spin.

Da fragt sich halt immer, was Ursache und was Wirkung ist.

Wer sagt denn, dass die Yields bei XeonPhi das Problem sind, und nicht die "Hitze"?

Ohne Vergleich/Daten von KNF, KNC "und XeonPhi" ist es halt schwer zu sagen, ob gewisse "Probleme" noch immer bestehen oder nicht.

Intel muss ihre Prozess auf GPU manufacturing besser trimmen; wie gesagt ab Haswell soll es losgehen.

Glaubste die machen sich wegen der aktuellen Situation bzgl Yields keinen Kopf (siehe deine Aussage weiter oben)? Würde mich jetzt wundern.

Falls doch hätte nVidia doch schon längst den "Schwarzen Peter" FETT auf die Stirn von TSMC gepappt..

Haben sie doch schon und das kurz nach dem GK104 release. Ich bin jetzt zu faul den link zu finden aber es war ein langwieriger blow gegen TSMC was sie besser machen koennten ueberhaupt im finanziellen Bereich.

Für mich liest sich das nach: "Ok, sind nur 14 SMX, aber scheis drauf, das reicht, die Konkurrenz kann auch nichts weltbewegendes bringen, also so lassen und sparen. Bringt man halt später nen 15er Refresh wenn alles läuft. Die Mittel werden wo anders gebraucht.

Am Tag wo Du binning yields richtig schnallen wirst werd ich mit einem HALLELUJAH Plakat hier herumrennen.

Und muss man sich dann nicht mal Gedanken über die grundsätzliche Idee machen?

Ich weiß wirklich nicht, ob da der Herstellungsprozess wirklich die alleinige Ursache für diese unendliche Geschichte ist oder ob es da nicht auch grundsätzlichere Ursachen für gibt. Aber auf was die Überlegung hinausläuft wissen wir ja ;)

Bei 550-600mm2 grossen hochkomplizierten dies sind solche Fragen eigentlich ueberfluessig. Lass Dir mal einen Anzug so nah wie moeglich auf die Haut naehen wie moeglich und wunder Dich wenn bei einer abrupten Bewegung zumindest eine Nat platzt.

Skysnake

2012-11-02, 13:00:20

Produktionsstart war Anfang September, 6 Monate spaeter nach dem finalen tape out. Welche grosse Veraenderung?

Das heißt also, die haben zu derartigen Bedingungen, wie von dir genannt wirklich die Produktion begonnen?

Mit ner GeForce wäre das definitiv nicht gegangen. Fragt sich, wie viel jeder verkaufte DIE dann am Ende wirklich kostet.

Ich hab deswegen gefragt, "was sich geändert hat" , da ich mir einfach nicht wirklich vorstellen konnte, dass die unter diesen Bedinungen wirklich anfangen zu produzieren. Die Kapazitäten sollten doch noch immer knapp sein oder?.
Warum also unter diesen Bedingungen Wafer rausballern?
Das macht doch nur Sinn, wenn man entweder dazu gezwungen ist, oder man doch genug Kapazität hat.

Wenn es zweiteres ist, dann wäre das echt der Hammer, das nVidia die Preise bei den GTX6x0 hoch hält...

Btw. wann sollte eigentlich nochmal die Produktionskapazität bei 28nm ansteigen? War doch irgendwann auf Ende diesen Jahres angepeilt.

Wenn man Dir sagt dass das Ding seinen tape out Anfang Maerz hatte, kann es einfach NICHT frueher in die Produktion gehen.

Hmm.. ich hatte eigentlich eine etwas kürzere Zeitspanne (>3 Monate) zwischen TapeOut und Produktionsstart im Kopf, aber ok.

Das die binning yields absolut beschissen waren hat nichts mit wafer yields oder der foundry zu tun. Wafer Kosten sind schaetzungsweise bei 28HP gegen 40G um ca. 30% hoeher.

Du solltest mal etwas vorsichtiger lesen und vielleicht etwas mehr Dein Gedaechtnis trainieren. Ehrlich.

Wenn ich von yields allgemein rede, dann mein ich alles zusammen. Also die Yields angefangen beim Wafer bis zu, fertigen Chip auf der Karte. Also auch inkl etwaiger verhunzter Packages usw usw.

Und wo hab ich jetzt was falsches geschrieben? "kein Anstieg von >50%" hab ich gesagt. Die Betonung liegt auf "kein". Also ne Abschätzung nach oben, und die trifft doch absolut zu. Ich hätte aber eventuell <50% schreiben sollen :rolleyes:

Ich schwoere ich hammer es Dir irgendwann in den Schaedel rein dass pro wafer Kosten ueberhaupt NICHTS mit binning yields zu tun haben. Wafer yields bzw. die Anzahl der operativen chips ist was die foundry etwas angeht (weil es dafuer Klausuren in Vertraegen gibt); wie viele Einheiten jetzt pro operativem chip kastriert werden ist der foundry total wurscht. Und dann beschwerst Du Dich dass ich nur so bissig werde :rolleyes:

Ok, dann schlag mal bitte einen Terminus vor, der klar macht, dass die Ausfall/Funktionsrate ausgehend von DIEs auf dem Wafer bis hin zur fertigen GPU, die funktioniert gemeint ist.

Welche yields genau?

Wie oben schon gesagt, die "Yieldrate" bzgl dem was man am Ende dann wirklich an funktionsfähigen Karten in der Hand hat.

Darauf kommts ja an. Für die Binning-Yields kann man ja an der Spannungsschraube usw drehen. Die Wafer-Yields kann man halt durch mehr Redundanz auf dem DIE usw erhöhen (also im Vergleich zwischen mehreren Implementierungen), wenn man zu viel nicht funktionsfähige Einheiten raus bekommt. Ansonsten ist das ja total für die Tonne.

Jetzt klar was ich meine?

Man kann ja durchaus die Wafer und Binning-Yields beeinflussen durch eigene Entscheidungen, wie man einen Chip/Produkt designed/zuschneidet.

Er ist besser geworden aber noch nicht in einem Stadium einen 7.1b grossen chip bei anstaendigeren Kosten herzustellen. Das natuerlich wenn man keinen hoeheren als $500-550 MSRP dafuer erwartet naechstes Jahr.

Wo wir wieder bei der Frage sind, ob das überhaupt realistisch ist, dass der Prozess an und für sich so gut reift, das man dann eben am Ende pro DIE auf der fertigen GPU nicht mehr als, sagen wir mal, 150$ zahlt.

(Mein Hintergedanken dazu: Ist es realistisch, das wir unter den Voraussetzungen mit einer GeForce-Version von GK110 rechnen können bis sagen wir Ende H1 2013.)

Die Produktion ist lediglich Wochen alt fuer GK110.

Und wann gingen ca. die letzten Änderungen am Design in den Chip ein?

Das was Du als fix beschreibst ist ein einfacher metal spin.

Ach und das ist kein fix :ugly:

Intel muss ihre Prozess auf GPU manufacturing besser trimmen; wie gesagt ab Haswell soll es losgehen.

Da lehne ich mich ganz gespannt zurück und warte mal drauf, was da kommt. Intel ist diesbezüglich einfach nicht mehr vertrauenswürdig. Die sollen mal wirklich was zeigen. Dann bekommen Sie auch ihr "Lob" dafür. Ansonsten bin ich diesbezüglich bei denen extrem mistrauisch.

Haben sie doch schon und das kurz nach dem GK104 release. Ich bin jetzt zu faul den link zu finden aber es war ein langwieriger blow gegen TSMC was sie besser machen koennten ueberhaupt im finanziellen Bereich.

Naja...
das war doch eher ein kleines Lüftchen als nen richtiger Shitstorm gegen TSMC. Da ist man von nVidia eigentlich andere Kaliber gewöhnt, wenn es darum geht jemanden die Schuld daran zu geben das etwas nicht so funktioniert wie man es erwartet hat.

Am Tag wo Du binning yields richtig schnallen wirst werd ich mit einem HALLELUJAH Plakat hier herumrennen.

Ich glaube ich hab das durchaus begriffen, aber wir reden teilweise aneinander vorbei, was für Yields für jeweils genau meinen ;)

Bei 550-600mm2 grossen hochkomplizierten dies sind solche Fragen eigentlich ueberfluessig. Lass Dir mal einen Anzug so nah wie moeglich auf die Haut naehen wie moeglich und wunder Dich wenn bei einer abrupten Bewegung zumindest eine Nat platzt.
Schlechter vergleich meiner Meinung nach :ugly:

Besser wäre hier, lass ihn dir so nah dran nähen wies geht UND dabei noch den dünnsten Stoff/Faden verwenden, dens gibt.

Man kann ja durchaus große Chips bauen, die nicht sooo große Probleme haben, einfach indem mal alles sehr konservativ angeht, viel Redundanz einbaut usw. Die Sinnhaftigkeit des Designs darf man natürlich nicht aus den Augen verlieren, aber man kann das nicht allein an der absoluten Größe festmachen, da spielt schon noch das eine oder andere mit rein.

EDIT:
http://semiaccurate.com/2012/11/02/nvidia-tesla-k20-specs-gives-hints-about-28nm-yields/
Was verzapft denn Charlie da wieder? :ugly:

Die News ist von 16.10 :ugly: Bischen spät oder nicht?

Zudem widerspricht das ja auch dem was wir von OakRidge wissen....

Oder gibts doch zwei unterschiedliche K20 Versionen? Also das sowohl die Aussagen von OakRidge stimmen, als auch die von heise.

Ailuros

2012-11-02, 13:58:19

Das heißt also, die haben zu derartigen Bedingungen, wie von dir genannt wirklich die Produktion begonnen?

Mit ner GeForce wäre das definitiv nicht gegangen. Fragt sich, wie viel jeder verkaufte DIE dann am Ende wirklich kostet.

Ich hab deswegen gefragt, "was sich geändert hat" , da ich mir einfach nicht wirklich vorstellen konnte, dass die unter diesen Bedinungen wirklich anfangen zu produzieren. Die Kapazitäten sollten doch noch immer knapp sein oder?.
Warum also unter diesen Bedingungen Wafer rausballern?
Das macht doch nur Sinn, wenn man entweder dazu gezwungen ist, oder man doch genug Kapazität hat.

Entschuldige aber fuer wieviel verkaufen sie nochmal jegliches K20 SKU? Ja es beisst etwas in die Gewinn margen als ob man vielleicht ein paar Monate mehr gewartet haette aber man haette Intel's Phi zu viel freie Bahn gelassen und bei Intel sind die Margen noch miserabler da es sich um einen 600mm2 die handelt und der Verkaufspreis wohl etwas niedriger sein duerfte.

Wenn es zweiteres ist, dann wäre das echt der Hammer, das nVidia die Preise bei den GTX6x0 hoch hält...

Btw. wann sollte eigentlich nochmal die Produktionskapazität bei 28nm ansteigen? War doch irgendwann auf Ende diesen Jahres angepeilt.

Ab Q3 aber da Herstellung auch ihre Zeit braucht wird man aus gutem Grund nichts Neues von beiden IHVs bevor Q1 13' sehen.

Wenn ich von yields allgemein rede, dann mein ich alles zusammen. Also die Yields angefangen beim Wafer bis zu, fertigen Chip auf der Karte. Also auch inkl etwaiger verhunzter Packages usw usw.

Es ist doch verdammt einfach; ich nenne wafer yields die Anzahl der operativen chips und binning yields eine vereinfacht "zweite" Sortierung an yields analog wieviel Einheiten pro core operativ bleiben koennen unter XYZ Bedingungen. Bei einem so kompliziertem chip kann man einfach nicht erwarten dass beim ersten run die Mehrzahl der operativen chips Vollausbau schaffen.

Angenommen sie wuerden heute eine 15SMX/GTX780 SKU veroeffentlichen mit einem MSRP von $599 und einen 14SMX/GTX770 SKU salvage part mit $499, welcher der beiden wird die hoehere Nachfrage haben? IHVs sorgen dafuer dass bei der Preis-definierung sie mit den meistverkauften SKUs eines chips immer noch Gewinn machen.

Ok, dann schlag mal bitte einen Terminus vor, der klar macht, dass die Ausfall/Funktionsrate ausgehend von DIEs auf dem Wafer bis hin zur fertigen GPU, die funktioniert gemeint ist.

Siehe oben und zich Posts relativ zu dem 14/15SMX Schlammasel: wafer yields und binning yields.

NV hat vom GF100 Disaster einiges lernen koennen; u.a. dass bei beschissener hw eben miserable binning yields die zur Kastrierung vom halben chip eben nicht optimal sind. Zwar hat NV die GF100 dies mit nur 8SMs im Quadro Markt verfrachtet, aber 256 von 512SPs ist schon ziemlich Scheisse.

Die Loesung war zweischienig:

1. Massnahmen dass mit 28nm so wenig wie moeglich schief laeuft.
2. 4 anstatt 2 GPCs auf GK104 um diesen auch froehlich fuer Quadros verkaufen zu koennen.

Man kann ja durchaus die Wafer und Binning-Yields beeinflussen durch eigene Entscheidungen, wie man einen Chip/Produkt designed/zuschneidet.

Kein einziger Zweifel; haengt aber wiederum davon ab wie stark man seine design-Ziel genau verpassen will. Sonst haette NV auch gleich alles auf 12SMXs trimmen koennen als Gegenbeispiel mit 600MHz und die binning yields um einiges erhoehen.

Wo wir wieder bei der Frage sind, ob das überhaupt realistisch ist, dass der Prozess an und für sich so gut reift, das man dann eben am Ende pro DIE auf der fertigen GPU nicht mehr als, sagen wir mal, 150$ zahlt.

(Mein Hintergedanken dazu: Ist es realistisch, das wir unter den Voraussetzungen mit einer GeForce-Version von GK110 rechnen können bis sagen wir Ende H1 2013.)

Unter den heutigen Indizien wohl schon und $150 ist auch schon ziemlich viel und passt eben nicht zu einem hypothetischem $499 MSRP.

Und wann gingen ca. die letzten Änderungen am Design in den Chip ein?

Ich hab ausser dem Oak ridge Zeug nichts anderes gehoert und auch um ehrlich zu sein nicht weitergefragt.

Naja...
das war doch eher ein kleines Lüftchen als nen richtiger Shitstorm gegen TSMC. Da ist man von nVidia eigentlich andere Kaliber gewöhnt, wenn es darum geht jemanden die Schuld daran zu geben das etwas nicht so funktioniert wie man es erwartet hat.

Ich kann mich nicht wirklich an einen echten shitstorm erinnern im Vergleich zu dem vorerwaehnten.

Ich glaube ich hab das durchaus begriffen, aber wir reden teilweise aneinander vorbei, was für Yields für jeweils genau meinen ;)

Schlechter vergleich meiner Meinung nach :ugly:

Besser wäre hier, lass ihn dir so nah dran nähen wies geht UND dabei noch den dünnsten Stoff/Faden verwenden, dens gibt.

Man kann ja durchaus große Chips bauen, die nicht sooo große Probleme haben, einfach indem mal alles sehr konservativ angeht, viel Redundanz einbaut usw. Die Sinnhaftigkeit des Designs darf man natürlich nicht aus den Augen verlieren, aber man kann das nicht allein an der absoluten Größe festmachen, da spielt schon noch das eine oder andere mit rein.

Man erreicht aber damit nicht die erwuenschte Leistung. NV haette z.B. einen GK110 so gestalten koennen wie Du ihn vorschlaegst mit so in etwa +30% Leistung in 3D gegen GK104 welches die Existenz eines solchen chips fraglich macht und noch schlimmer unter HPC waere das Ding sowohl Phi als sogar Tahiti unterlegen. Und dann prostetiert jeder dann gerechtfertigt was fuer einen Schlappschwanz NV entwickelt hat.

EDIT:
http://semiaccurate.com/2012/11/02/nvidia-tesla-k20-specs-gives-hints-about-28nm-yields/
Was verzapft denn Charlie da wieder? :ugly:

Die News ist von 16.10 :ugly: Bischen spät oder nicht?

Zudem widerspricht das ja auch dem was wir von OakRidge wissen....

Oder gibts doch zwei unterschiedliche K20 Versionen? Also das sowohl die Aussagen von OakRidge stimmen, als auch die von heise.

Er geht wohl von den angeblichen Specs des Haendlers aus. HPCWire ist normalerweise eine sehr zuverlaessige Quelle.

OgrEGT

2012-11-02, 17:56:27

Um nochmal auf meine Frage zurück zu kommen, wieviele GK110@15SMX werden bei 20000 K20 bisher ungefähr abgefallen sein? Kann man das schätzen?

Skysnake

2012-11-02, 17:58:02

Also wenn ich das von Ailuros in Betracht ziehe, dann schätze ich wirds wohl ~1% sein.

Ailuros

2012-11-02, 18:01:35

Also wenn ich das von Ailuros in Betracht ziehe, dann schätze ich wirds wohl ~1% sein.

<30% von wafer yields. 1% war es bei GF100/16SM welches nicht wirklich relevant ist aus vorerwaehnten Gruenden. Es gibt irgendwo einen Artikel wo jemand einen GF100/16SM in die Finger bekam und der Stromverbrauch brutal hoch war im Vergleich zur GTX480.

OgrEGT

2012-11-02, 18:16:23

Gipsel

2012-11-02, 18:27:57

Das ist doch reines Rätselraten. Und TSMC/nV geben sicherlich keine Daten offiziell heraus. Momentan sind das viel zu viel halbgare Gerüchte (wenn überhaupt) um da eine solide Abschätzung zu der Frage zu treffen.

Ailuros

2012-11-02, 18:48:18

Bei 300m2 Wafer passen so ca 90 GPUs drauf.
Wafer yields (operativ egal wie): 60% ?
15SMX yield davon ca. 20% ?

Wären dann ca. 10 pro Wafer.

Äh wieviele Wafer hat NV für die 20000 K20 gebraucht?

Du erwartest doch nicht ernsthaft dass ich so ausfuehrlich darueber werde selbst wenn ich genug wissen wuerde die Fragen zu benantworten? Das vorige Prozentual war nicht frei erfunden, aber der eigentliche Punkt war zu zeigen dass es sich eben nicht gelohnt haette 15SMX chips fuer Oak Ridge und anderen zu benutzen weil sie mehr wafer gebraucht haetten und es daher mehr gekostet hatte in Herstellungskosten und Zeit.

OgrEGT

2012-11-02, 19:20:33

Du erwartest doch nicht ernsthaft dass ich so ausfuehrlich darueber werde selbst wenn ich genug wissen wuerde die Fragen zu benantworten? Das vorige Prozentual war nicht frei erfunden, aber der eigentliche Punkt war zu zeigen dass es sich eben nicht gelohnt haette 15SMX chips fuer Oak Ridge und anderen zu benutzen weil sie mehr wafer gebraucht haetten und es daher mehr gekostet hatte in Herstellungskosten und Zeit.

Schon klar...:cool:

OgrEGT

2012-11-02, 19:22:55

kruemelmonster

2012-11-02, 19:26:13

Es gibt irgendwo einen Artikel wo jemand einen GF100/16SM in die Finger bekam und der Stromverbrauch brutal hoch war im Vergleich zur GTX480.

Meinst du diesen hier: http://en.expreview.com/2010/08/09/world-exclusive-review-512sp-geforce-gtx-480/9070.html ?

200w Mehrverbrauch für den einen SM. :freak:

Btw wo wir gerade bei Prototypen sind: gibt es vielleicht ein Bild vom ersten Auftritt des GF100 hinter geschlossenen Türen, aka Tentakelfermi?

Ailuros

2012-11-02, 19:41:29

Meinst du diesen hier: http://en.expreview.com/2010/08/09/world-exclusive-review-512sp-geforce-gtx-480/9070.html ?

200w Mehrverbrauch für den einen SM. :freak:

Genau. Danke.

Btw wo wir gerade bei Prototypen sind: gibt es vielleicht ein Bild vom ersten Auftritt des GF100 hinter geschlossenen Türen, aka Tentakelfermi?

Keine Ahnung.

Wie wäre denn eine vorbehaltliche, zurückhaltende Abschätzung?

Weniger wafer als Du Beitraege hast. Sorg jetzt nur dafuer dass Du heftig spammst in der naechsten Stunde bevor es andere lesen koennen :freak:

boxleitnerb

2012-11-02, 20:12:06

Wenn man sich das mit dem Launchmuster der sonstigen GPUs anschaut, dann ist das durchaus spät.

nVidia kam nach AMD, was aber kein Ding ist. Wann kommt jetzt aber GK110, und wann kam GK104? Richtig, da liegt ne ganze menge Zeit dazwischen. Nämlich sieben Monate + x.

Was man fairerweise sagen muss ist, dass die Tesla Karten wohl früher kommen als normal. Da kam ja eigentlich immer erst die Consumer-Version und danach die Quadro/Tesla-Version. Normal hat man sich für Validierung und what ever noch alles halt mehr Zeit genommen, oder für einen gemeinsamen Launch waren die Kapazitäten nicht groß genug oder what ever...

Auf jeden Fall fällt der Druck aus dem Desktop-Markt auf jeden Fall mal weg, dafür aber eben relativ zu den Profikarten kein all zu später launch.

Aber reicht es sich da allein auf die HPC-Versionen zu beschränken um das zu beurteilen? Ich finde nicht.

Du hast den falschen Bezugspunkt. Ich spreche von einem Launch im Bezug auf das Alter des Prozesses, nicht auf den Release vom kleinen Bruder GK104, GF104 oder AMDs GPUs.

GK110 kann genausowenig früher kommen wie GF100 früher als im März 2010 kommen konnte. Der Prozess muss immer reifen, so oder so. Stell es dir so vor wie Fermi, nur dass da GF104 deutlich vorgezogen worden wäre. Den großen Chip hätte dies direkt gar nicht betroffen.

Skysnake

2012-11-02, 21:18:14

dildo4u

2012-11-02, 22:24:03

Inside the Titan Supercomputer: 299K AMD x86 Cores and 18.6K NVIDIA GPUs

http://www.anandtech.com/show/6421/inside-the-titan-supercomputer-299k-amd-x86-cores-and-186k-nvidia-gpu-cores/3

Ziemlich krank für die Berechnung einer Sekunde einer Supernova Explosion brauchen sie 6 Monate.Das Projekt soll auf 30% von Titan laufen.

boxleitnerb

2012-11-02, 22:39:06

Also das ist doch jetzt blödsinn...

GF100 war kaputt. Wir können/dürfen bei GK110 eigentlich davon ausgehen/annehmen, dass das nicht der Fall ist!

Daher macht das schon einen großen Unterschied.

Nein macht es nicht. G80, GT200, GT200b und GF100 kamen alle lange nach den ersten Produkten im jeweiligen Herstellungsprozess. Zuerst wurden immer nur kleine Brötchen gebacken.
Wie soll da GK110 spät sein, wenn es bei ersten Produkten mit diesem Chip (K20) genauso ist? Bei Fermi wurde das kleine Brötchen eben nicht so flott herausgebracht, obwohl das sehr wohl möglich gewesen wäre. Bei Kepler haben sie es gelernt, dass man lieber erst kleine Brötchen backt, statt gar nix zu haben.

Du kannst keine Verspätung attestieren, nur weil Nvidia ihre Strategie geändert hat. Für das Alter von 28nm kommt GK110 sogar recht früh - eben nicht als GTX780, aber das ist ja nicht wirklich relevant. Chip ist Chip.

Skysnake

2012-11-02, 22:44:47

Man darf da aber nicht groß zwischen Tesla/Quadro und GeForce unterscheiden.

Das ist ein Validierungsproblem, kein grundlegendes Fertigungsproblem, dass die Profi-Karten früher so spät kamen.

boxleitnerb

2012-11-02, 22:56:36

Damit sagst du doch genau, was ich sage - es ist egal, als was GK110 kommt, er kommt. In was du ihn zuerst einbaust, ändert am Zeitpunkt nix.

Skysnake

2012-11-02, 23:48:17

GK110 kommt aber (bis auf GF100, der eine auserplanmäßige Verzögerung hatte) gut nen Jahr nach dem Chip von AMD und selbst im eigenen Haus ne gutes 3/4 Jahr später.

Das willst du doch jetzt nicht als normal bezeichnen oder?

Sorry, aber GF100 kann da eben gar nicht herhalten... Meine Meinung.

boxleitnerb

2012-11-03, 00:00:39

Sag mal, willst du mich absichtlich falsch verstehen? K20 mit GK110 wird so wie es aussieht ab ca. September/Oktober in Massen ausgeliefert. Das sind 8-9 Monate nach Tahiti, und nicht "gut nen Jahr". Also völlig im Rahmen, denn in der Vergangenheit war es nicht groß anders.

Und mit eigenem Haus meinst du wohl GK104. Aber was hat das mit GK110 zu tun? Im Desktop haben bei Kepler der große und der kleine Chip einfach die Plätze getauscht, der kleine kommt zuerst. Davon ist K20 aber komplett unabhängig, und in dem werkelt nunmal GK110.

Um es kurz zu machen: Du kannst nicht über GK110 sprechen und gleichzeitig K20 ignorieren.

Hübie

2012-11-03, 01:47:29

Meinst du diesen hier: http://en.expreview.com/2010/08/09/world-exclusive-review-512sp-geforce-gtx-480/9070.html ?

200w Mehrverbrauch für den einen SM. :freak:

Btw wo wir gerade bei Prototypen sind: gibt es vielleicht ein Bild vom ersten Auftritt des GF100 hinter geschlossenen Türen, aka Tentakelfermi?

Taktnormiert kämen da 547 Watt heraus. Also 107 Watt für ein SM (32 CUDA-Cores) mehr. Das zeigt eben mehr als deutlich in welch misslicher Lage sich Fermi anfangs befand.

Meine geschätze Verteilung ist 33% 14-SMX- Dies/Wafer und 45% 13-SMX- Dies/Wafer. Aber wie Gipsel bereits sagte ist es reinstes Rätselraten ohne Auflösung ;)

OgrEGT

2012-11-03, 07:08:26

<30% von wafer yields. 1% war es bei GF100/16SM welches nicht wirklich relevant ist aus vorerwaehnten Gruenden. Es gibt irgendwo einen Artikel wo jemand einen GF100/16SM in die Finger bekam und der Stromverbrauch brutal hoch war im Vergleich zur GTX480.

Bei 300m2 Wafer passen so ca 90 GPUs drauf.
Wafer yields (operativ egal wie): 60% ?
15SMX yield davon ca. 20% ?

Wären dann ca. 10 pro Wafer.

Äh wieviele Wafer hat NV für die 20000 K20 gebraucht?

Du erwartest doch nicht ernsthaft dass ich so ausfuehrlich darueber werde selbst wenn ich genug wissen wuerde die Fragen zu benantworten? Das vorige Prozentual war nicht frei erfunden, aber der eigentliche Punkt war zu zeigen dass es sich eben nicht gelohnt haette 15SMX chips fuer Oak Ridge und anderen zu benutzen weil sie mehr wafer gebraucht haetten und es daher mehr gekostet hatte in Herstellungskosten und Zeit.

Weniger wafer als Du Beitraege hast. Sorg jetzt nur dafuer dass Du heftig spammst in der naechsten Stunde bevor es andere lesen koennen :freak:

Meine geschätze Verteilung ist 33% 14-SMX- Dies/Wafer und 45% 13-SMX- Dies/Wafer. Aber wie Gipsel bereits sagte ist es reinstes Rätselraten ohne Auflösung ;)

Na dann nehmen wir doch als worst case 600 Wafer.
Dann könnte NV bereits auf einigen Tausend GK110@15SMX sitzen, was einen Launch in Q12013 nicht unmöglich erscheinen lässt.
Je nachdem wieviele 15SMX Chips welches Frequenzziel genau erreichen, könnte bei konservativer Zielsetzung sogar ein Paper-Launch noch 2012 hinhauen?

Ailuros

2012-11-03, 07:32:17

GK110 kommt aber (bis auf GF100, der eine auserplanmäßige Verzögerung hatte) gut nen Jahr nach dem Chip von AMD und selbst im eigenen Haus ne gutes 3/4 Jahr später.

GF100 war in 2009 nicht herstellbar; selbst AMD hatte so einige Probleme bis zu Q1 10' mit Cypress.

GK110 in der Form von K20 kam eben nicht ein Jahr nach Tahiti an und auch nicht ein 3/4 Jahr nach GK104. Im letzten Fall eher 6 Monate.

Das willst du doch jetzt nicht als normal bezeichnen oder?

Unter der Logik dass das meiste so geplant war von Anfang an ist es durchaus normal. Was NV NICHT wusste ist dass GK104 so gut gegen Tahiti kontern kann. Man legte die ersten Plaene fuer einen spaeten Februar release auf Eis, pumpte den chip so weit auf dass er voll Nacken an Nacken konkurrieren kann mit Tahiti und entschied sich wohl die Kosten fuer zu grosse und teuere Produktionen fuer GK110 (desktop und HPC) zu sparen und bediente nur HPC. Die originalen launch Bilder des ersten stornierten GK104 zeigten einen relativ kleinen PCB und die Leistung waere wohl nicht auf 680 Nivaeu gelegen sondern eher irgendwo im 660Ti Bereich; TDP war auch um einiges niedriger und deshalb war der anfangs sehr niedrige MSRP gar nicht so absurd wie jeder meinte. Der Haken ist halt dass es so GROSSE Nachfrage generiert haette dass NV sie nie im Leben haette decken koennen. TSMC konnte keine zusaetzliche Kapazitaeten nachweisen, ergo wurde einiges an der Strategie fuer 2012 geaendert.

Von dem Punkt aufwaerts existiert GK110 als chip in der Form von K20 und fuer einen ersten run bei einem so kompliziertem chip und die zusaetzliche Problematik von 28HP mitberechnet sind 14SMX@732MHz/6GB/225W alles andere als schlecht, eher das Gegenteil.

Nochmal historische Trends mitberechnet spricht gar nichts dagegen einen solchen chip auf 850MHz zu takten, OHNE dass der Stromverbrauch auf 300W kommt und im schlimmsten Fall wo es eben 14 vs. 15 SMX am Anfang fuer desktop sind ist es sicher ein Weltuntergang bombastische 5% weniger Endleistung zu haben.

Na dann nehmen wir doch als worst case 600 Wafer.
Dann könnte NV bereits auf einigen Tausend GK110@15SMX sitzen, was einen Launch in Q12013 nicht unmöglich erscheinen lässt.
Je nachdem wieviele 15SMX Chips welches Frequenzziel genau erreichen, könnte bei konservativer Zielsetzung sogar ein Paper-Launch noch 2012 hinhauen?

Paperlaunch fuer was genau? AMD wird afaik dieses Jahr nichts mehr veroeffentlichen. Selbst wenn beide zu einem Paper launch greifen wuerden, waere es der laecherlichste stunt ueberhaupt etliche Monate vor dem eigentlichen launch Papierfranzen zu veroeffentlichen.

Taktnormiert kämen da 547 Watt heraus. Also 107 Watt für ein SM (32 CUDA-Cores) mehr. Das zeigt eben mehr als deutlich in welch misslicher Lage sich Fermi anfangs befand.

Meine geschätze Verteilung ist 33% 14-SMX- Dies/Wafer und 45% 13-SMX- Dies/Wafer. Aber wie Gipsel bereits sagte ist es reinstes Rätselraten ohne Auflösung ;)

Es hat keinen Sinn Watts pro SM in solch einem Fall auszurechnen. Das Problem beim GF100 war afaik dass je mehr SMs eingeschaltet wurden desto brutaler stieg der Stromverbrauch, eben wegem dem die interconnect Problem.

Das sample im review muss ja nichtmal unbedingt ein echter "heiler" 16SM chip gewesen sein, sondern vielleicht sogar ein chip den NV unter normalen Umstaenden nur mit 15 bzw. 14 SMs verkauft haette. Das einzige was man von dem Artikel festhalten kann, ist dass die Problematik auf GF100 eben nicht nur ein Maerchen war.

OgrEGT

2012-11-03, 09:02:59

Paperlaunch fuer was genau? AMD wird afaik dieses Jahr nichts mehr veroeffentlichen. Selbst wenn beide zu einem Paper launch greifen wuerden, waere es der laecherlichste stunt ueberhaupt etliche Monate vor dem eigentlichen launch Papierfranzen zu veroeffentlichen.

Nennen wir es Launch mit homöopathischer Dosierung und rein hypothetisch falls notwendig...:freak:

Ailuros

2012-11-03, 09:44:49

Nennen wir es Launch mit homöopathischer Dosierung und rein hypothetisch falls notwendig...:freak:

Eine solche Notwendigkeit wird es IMO nicht geben. Nebenbei koennte NV endlich ihre Preise reduzieren zur Abwechslung, zumindest vor Weihnachten.

Dunkeltier

2012-11-03, 11:24:12

Warum sollten sie, um sich die Margen absichtlich kaputt zu machen? AMD hechelt immer noch hinterher und ihre derzeitigen Modelle verkaufen sich wie geschnitten Brot.

Skysnake

2012-11-03, 15:20:11

Warum sollten sie, um sich die Margen absichtlich kaputt zu machen? AMD hechelt immer noch hinterher und ihre derzeitigen Modelle verkaufen sich wie geschnitten Brot.
Wo hecheln die bitte hinterher :confused:

GF100 war in 2009 nicht herstellbar; selbst AMD hatte so einige Probleme bis zu Q1 10' mit Cypress.

GK110 in der Form von K20 kam eben nicht ein Jahr nach Tahiti an und auch nicht ein 3/4 Jahr nach GK104. Im letzten Fall eher 6 Monate.

Willst du jetzt etwa den OakRidge Deal als "Launch" verkaufen?

Wenn sollte man entweder richtige Launches mit richtigen Launches vergleichen, oder eben nur die Supercomputer-Deals. Die sind nämlich normal schon noch immer einiges früher dran als die normalen Teslas.

Daher kannste das nicht wirklich miteinander vergleichen.

Und wie gesagt, mir gings um die Ersterscheinung eines Chips, egal ob Tesla, Quadro, GeForce oder HinzundKunz-Force... Und da ist man halt schon spät dran, da keine Desktop-Variante kam. Oder nicht?

Und bzgl 3/4 Jahr bis Jahr:
Wann ist Tahiti gekommen?

Paperlaunch 22. Dezember 2011, und echter Verkaufsstart 9. Januar 2012.

Welches Datum haben wir heute?

Ja richtig 3. November 2012. Und wo kann ich meinen GK110 kaufen???

Richtig, nirgends. Man kann auch nicht abschätzen, wann es den Chip zu kaufen gibt. Aktuell fehlen aber nur 6 Tage, damit man 10 Monate hinten dran ist. Ich denke da ist es wirklich nicht verwerflich von einem Jahr zu reden oder?

Mit dem 3/4 Jahr das Gleiche.

Da war die Vorstellun am 22. März 2012. Das sind aktuell ~7,5 Monate.

Und wie gesagt, eine Verfügbarkeit/Launch ist aktuell nicht absehbar.

Hugo78

2012-11-03, 16:47:55

Wenn sollte man entweder richtige Launches mit richtigen Launches vergleichen, oder eben nur die Supercomputer-Deals. Die sind nämlich normal schon noch immer einiges früher dran als die normalen Teslas.

Seltsam, bisher langen immer so 3-6 Monate zwischen Geforce <-> quadro/tesla.

Und AMDs Thaiti hat sogar über 6 Monate gebraucht, bis er es in Profisegment geschaft hat in Form von FirePro.

Es mag in deiner Welt ganz grausam sein, dass man GK110 aktuell nur kaufen kann, wenn man für die DARPA arbeitet, aber GK110 existiert. *punkt*

boxleitnerb

2012-11-04, 08:59:41

OgrEGT

2012-11-04, 09:36:14

Charlie deutet an, die 14 SMX-Chips für ORNL wären "spezielle" Chips, die man aufgrund der miserablen Yields auf den normalen K20 nicht findet - diese wären mit 13 SMX ausgestattet.

Realistisch oder Geblubber?

Kann ich mir ehrlich gesagt kaum vorstellen dass es an angeblich so miesen yieds liegt. Wenn die Produktion seit September erst läuft, und schon die 14SMX parts mühsam selektiert werden müssten, dann erscheint mir die Zeit einfach zu kurz, als dass man so 20000 Chips zusammen bekommen hätte.

Ich glaube man erhält relativ wenig (aber gerade noch genug) 14-er, in der Mehrheit 13-er und sehr wenig 15-er.

boxleitnerb

2012-11-04, 09:42:25

Man hätte natürlich auch sehr viele zusätzliche Wafer bestellen können, das würde dann halt den Profit ziemlich schmälern.

Skysnake

2012-11-04, 10:01:09

Naja, kommt drauf an.

Wenn mangenug GeForce auf Halde hat, kann man halt mal kurze Zeit kräftig GK110er durchblasen. Die Wafer braucht man ja so oder so.

Und wenn man davon ausgeht, das sich so schnell an der allgemeinen Situation nichts ändert, ist es eh egal, wann ich die Wafer durchblase.

Dann hätte man halt in kürzerer Zeit die Chips zusammen, die man braucht. Möglich ist das wohl in der Zeit schon.

Ich kanns mir aber kaum vorstellen, dass die für OakRidge ne Extrawurst machen... Da wären andere Kunden ziemlich pissed, und allgemein kostet das ja auch wieder extra.

Da müsste nVidia schon ziemlichen Druck bekommen haben, dass Sie sich zu so einer Aktion haben hinreisen lassen.

Hugo78

2012-11-04, 12:01:08

Charlie deutet an, die 14 SMX-Chips für ORNL wären "spezielle" Chips, die man aufgrund der miserablen Yields auf den normalen K20 nicht findet - diese wären mit 13 SMX ausgestattet.

Realistisch oder Geblubber?

Wenn NV schon seit mehr als 6 Monaten GK110 selktieren würde, dann wäre es realistisch.

Aber wenn man in weniger als 2 Monaten Produktion, eventuell sogar nur in etwas mehr als einem Monat,
knapp 20000, 14 SMX GK110 selektieren konnte, dann wird es auch für alle Anderen in Zukunft 14 SMX zu kaufen geben.
Nicht notwendigerweise als "Sofortkauf Option", aber mit etwas Wartezeit sicherlich.

Die 13 SMX Version könnte natürlich erstmal allein im Verkauf stehen.
1-2 Monate, bis man wieder genug 14 SMX Versionen hat, um Bestellungen überhaupt verlässlich annehmen zukönnen.

Skysnake

2012-11-04, 12:14:03

Und könnte es eventuell eine 14SMX HPC Supercomputer Version geben, die auf X Monate ausverkauft ist, da man so viele Deals zu bearbeiten hat, und dann ne "normale" 13er für den "Normalkunde", der halt nicht gleich >>1k Stück abnimmt?

Mancko

2012-11-04, 12:45:45

Charlie deutet an, die 14 SMX-Chips für ORNL wären "spezielle" Chips, die man aufgrund der miserablen Yields auf den normalen K20 nicht findet - diese wären mit 13 SMX ausgestattet.

Realistisch oder Geblubber?

Was erwartest Du? Was soll er nach seinem neuerlichen "Fail" Artikel auch anderes schreiben? Er hat den Artikel rausgebracht nachdem bereits die Daten vom Supercomputer genannt wurden und es klar war, dass es 14SMX sind. Ich finde einer in seinem Forum hat es gut bzgl. CharLie's 13SMX Theorie zusammengefasst.

Lets take this scenario and run with it, where are the hundreds of thousands of GK110s - one, two and three bins down from K20 - that this would undoubtably produce? As there clearly are none in the open market, and I have doubts you could sink those kind of numbers into a couple of backwater supercomputers, will we see an explosion in NVDA's inventory in the Q3/2012 results?

Jedesmal wenn sich der Spinner mit Nvidia's Yields oder Finanzen auseinander setzt blamiert er sich bis auf die Knochen. Nur hören möchte er das nicht gern - vor allem nicht in seinem Forum. Das wäre schlecht für die Moral der Leute dort die seine Bemerkungen für den heiligen Gral halten. Da holt er dann immer die "Ban" Keule raus.

Am liebsten möchte ich mal wieder ein Kommentar dort loslassen. Bin aber leider zu faul wieder einen Account einzurichten. Ich hebe mir das mal für Nvidia's Quartalszahlen auf, denn wahrscheinlich auch in Q3 wird Nvidia wieder deutlich besser als AMD abschneiden. Ist natürlich für die Moral in dem Kindergarten auf seiner Webseite nicht optimal aber es ist immer gut, wenn man dann wieder auf den Boden der Tatsachen zurückgeholt wird . Dann tut man sich im späteren Leben einfach leichter :)

Ailuros

2012-11-05, 07:43:55

Willst du jetzt etwa den OakRidge Deal als "Launch" verkaufen?

Nein. Oak Ridge ist aber nicht der einzige supercomputer deal und wie man es auch verdreht liegen fuer diese GK110 in Produktion und werden zu Kunden ausgeliefert.

Wenn sollte man entweder richtige Launches mit richtigen Launches vergleichen, oder eben nur die Supercomputer-Deals. Die sind nämlich normal schon noch immer einiges früher dran als die normalen Teslas.

Daher kannste das nicht wirklich miteinander vergleichen.

Offiziell schon seit einiger Zeit hat NV den launch fuer Tesla K20 fuer Q4 2012 angelegt. Nie frueher.

Und wie gesagt, mir gings um die Ersterscheinung eines Chips, egal ob Tesla, Quadro, GeForce oder HinzundKunz-Force... Und da ist man halt schon spät dran, da keine Desktop-Variante kam. Oder nicht?

Und bzgl 3/4 Jahr bis Jahr:
Wann ist Tahiti gekommen?

Paperlaunch 22. Dezember 2011, und echter Verkaufsstart 9. Januar 2012.

Welches Datum haben wir heute?

GK110 war erstmal NIE zeitgleich fuer einen launch jeglicher Art mit Tahiti geplant. GK104 dann eben schon. Wie und was Du jetzt als Verspaetung definieren willst ist ein anderes Kapitel. Ich hab schon weiter oben erklaert wieso man sich entschieden hat einiges an den Plaenen zu aendern. Es gibt keine Not momentan fuer GK110 desktop da sich GK104 ziemlich gut mit Tahiti im desktop schlagen kann und verkauft sich auch alles andere als schlecht. Preise sind ekelhaft hoch, Margen wohl genauso ergo besteht kein besonderer Grund so oder so einen um zich Male teureren chip durch die Laengen zu ziehen wenn man mit GK104 desktop, GRID Mist teilweise, Quadros teilweise und Tesla teilweise momentan damit bedienen kann. All das letztere war keine Entscheidung der letzten Minute sonst waeren sie gleich bei 2 GPCs auf GK104 geblieben wie auf GF1x4.

Ja richtig 3. November 2012. Und wo kann ich meinen GK110 kaufen???

Richtig, nirgends. Man kann auch nicht abschätzen, wann es den Chip zu kaufen gibt. Aktuell fehlen aber nur 6 Tage, damit man 10 Monate hinten dran ist. Ich denke da ist es wirklich nicht verwerflich von einem Jahr zu reden oder?

Mit dem 3/4 Jahr das Gleiche.

Da war die Vorstellun am 22. März 2012. Das sind aktuell ~7,5 Monate.

Und wie gesagt, eine Verfügbarkeit/Launch ist aktuell nicht absehbar.

Es aendert trotzdem nichts an der Tatsache dass die chips hergestellt und verkauft werden. Es ist eben nicht so dass NV diese an Organisationen verschenkt sondern ziemlich heftig Kohle daraus macht und sogar Gewinn. Mehr Gewinn als Tahiti bei etlichen Monaten desktop Verkaeufen am Anfang gemacht hat. Solche Haarspaltereien sind eher albern; der eigentlich Punkt war eigentlich nur zu erklaeren warum sich NV fuer die spezifische Strategie in 2012 so entschieden hat.

Fuer mich persoenlich wenn sie nicht so vorgegangen waeren und haetten eine "GTX780" mit einem $900 MSRP als Beispiel veroeffentlicht haetten sich fuer mich das Ding genauso an den Hut stecken koennen wie heute eine GTX680 fuer =/>500 Euro oder fast doppelt so viel fuer eine GTX690. Wieso hat eigentlich AMD nicht offiziell selber eine 7990 vorgestellt und hat es mit Absicht den vendors als eigene Initiative ueberlassen und dieses sogar mit ziemlich grosser "Verspaetung" gegenueber der 690?

NV macht so manchen zusaetzlichen Gewinn mit allem bis zu GK104 momentan und ich sagte weiter oben dass es verdammt Zeit wird dass sich die Preise endlich zumindest bis Weihnachten reduzieren. Jemand antwortete darauf dass es keine Not dafuer gibt und er hat auch teilweise recht, der Haken ist aber dass NV irgendwann alles GK10x loswerden muss und sich so langsam dafuer vorbereiten fuer Q1 2013 fuer einen neuen top to bottom "Familien-launch" HOFFENTLICH mit um einiges logischeren Preisen eben von TOP 2 BOTTOM.

Sonst liegt an Deiner Perspektive zwar nichts falsches per se, aber wenn am Ende des FY AMD und NV ihre finanzielle Einzelheiten freigeben heisst es dann eben nicht dass NV N Umsatz fuer supercomputers aus diesen streichen wird oder dass AMD mit irgendwelchen super-Gewinn raten ankommen wird.

Was erwartest Du? Was soll er nach seinem neuerlichen "Fail" Artikel auch anderes schreiben? Er hat den Artikel rausgebracht nachdem bereits die Daten vom Supercomputer genannt wurden und es klar war, dass es 14SMX sind. Ich finde einer in seinem Forum hat es gut bzgl. CharLie's 13SMX Theorie zusammengefasst.

Jedesmal wenn sich der Spinner mit Nvidia's Yields oder Finanzen auseinander setzt blamiert er sich bis auf die Knochen. Nur hören möchte er das nicht gern - vor allem nicht in seinem Forum. Das wäre schlecht für die Moral der Leute dort die seine Bemerkungen für den heiligen Gral halten. Da holt er dann immer die "Ban" Keule raus.

Am liebsten möchte ich mal wieder ein Kommentar dort loslassen. Bin aber leider zu faul wieder einen Account einzurichten. Ich hebe mir das mal für Nvidia's Quartalszahlen auf, denn wahrscheinlich auch in Q3 wird Nvidia wieder deutlich besser als AMD abschneiden. Ist natürlich für die Moral in dem Kindergarten auf seiner Webseite nicht optimal aber es ist immer gut, wenn man dann wieder auf den Boden der Tatsachen zurückgeholt wird . Dann tut man sich im späteren Leben einfach leichter :)

http://semiaccurate.com/forums/showthread.php?t=6720&page=2

Ihr regt Euch zu stark darueber auf ehrlich. Seit ich mit Charlie etwas privat plaudere ist es etwas einfacher zu verstehen was er genau weiss und nicht und woher das Ganze kommt. Es sollte nicht heissen dass jetzt alles so stimmt wie es praesentiert wird, aber es ist wiederrum auch meistens so zwielichtig und wage formuliert dass man fast bei jedem Fall ein "told you so" spaeter daranhaengen kann.

Die eigentliche Tatsache ist dass Charlie doch tatsaechlich gute Quellen hat und dieses nicht nur auf NV begrenzt. Man liest eben wenn man will die SA Artikel und es liegt einem jedem frei dass zu glauben was man will. Eine "Quelle" wie SA reicht sowieso nie fuer anstaendige "Forschung" ueber ein jegliches Thema. In einigen Faellen hast Du dann eben eine radikal pessimistische Perspektive und womoeglich woanders eine radikal optimistische Perspektive. In solch einem Fall wuerde ich einfach vorschlagen dass die Wahrheit irgendwo in der Mitte liegt, denn die Chancen dass es nicht so sein wird sind eher gering.

Wir sind wohl als Leser denke ich erwachsen genug jeglichen moeglichen bullshit herausfiltern zu koennen oder? Und nein es bringt nichts zu versuchen Charlie im SA forum aggressiv zu konfrontieren. Wuerde ich selber irgendwelche genaue und zu >90% zuverlaessigen Daten haben, wuerde ich sie mit ihm privat besprechen und ich kann Dich versichern dass er darauf selber weiterforschen wuerde. Da es aber generell verdammt still ist und keiner sich anstrengt eine andere Perspektive indirekt und off the record einzulegen heisst fuer mich food for thought ohne momentan jegliche Schlussvolgerungen zu ziehen. Das wiederspricht jetzt nicht mit dem obrigen Geblubber von mir, sondern sollte nur heissen dass ich gerne jegliche von Art von info bearbeite wenn ich weiss woher sie kommt.

Skysnake

2012-11-05, 10:22:31

Ailuros

2012-11-05, 10:46:34

Ailuros, das nVidia innerhalb ihres Zeitplans richtig liegen, bestreite ich doch gar nicht. Mich wunderts halt nur, das man dennoch keine 15 SMX Version direkt auf den Markt wirft, obwohl man eben nicht den Monsterchip direkt als erstes bringt wie früher. Find ich btw ne gute Entscheidung.

Weil ich das Gefuehl nicht los werde dass die Anzahl der 15 SMX Varianten zu begrenzt ist. Charlie behauptet stur in seinem Forum (siehe link oben) dass die 13 SMX Varianten den groessten bin darstellen; und ich gehe jetzt nicht so tief in die Haarspalterei ob es stimmt oder nicht (wenn NV die ersten K20 zum Verkauf freigibt wird sich das Raetsel schon loesen). Der Punkt ist eben dass es 15 SMX bins eben nicht sind; dieses ist ueber schon mehrere Seiten mein Punkt und es besteht kein einziger Grund zich mehr wafer runs zu machen um N benoetigtes Volumen fuer X deals zu erreichen. Ich hab es mit frei erfundenen Zahlen vor Seiten schon mal vorgerechnet und ich hab wirklich keinen Bock es zu wiederholen. Es liegt sehr einfache Logik und Mathematik dahinter und wenn ich es verfolgen kann (wo ich eigentlich stets eine Banause mit Mathe war) kann es fast jeder der mitliest hier.

Sonst werden Charlie's Behauptungen mit Argumenten z.B. bei B3D bestritten, aber ehrlich die Erbsenzaehlerei ist fuer mich das Thema nicht wert, ueberhaupt da NVIDIA eben nicht unter Zeitdruck fuer einen jeglichen release liegt.

http://forum.beyond3d.com/showpost.php?p=1677256&postcount=382

http://forum.beyond3d.com/showpost.php?p=1677502&postcount=390

Bzgl. dem Launchdatum, da gabs früher aber auch die paar HPC-Deals, wo Wochen bis Monate vorher schon angefangen wurde, die Karten rein zu knallen. Da waren nur eben die Consumer-Karten zuerst auf dem Markt, weshalb das nicht so aufgefallen ist.

Nur waren diese deals fuer jeglichen Anfang diametrisch kleiner und man hatte eben keine GK104 "Rettungsplanke" parat um desktop und halbwegs etwas Profi-Zeug mit diesem zu fuellen. Gab es vor GF100 oder GF110 eine GF104 bzw. 114 im desktop, fuer Quadros, fuer Servers und dazu auch noch in einem mGPU config? Nicht dass ich wuesste. Und mit so etwas kommt man nicht in letzter Minute auf die Laufbahn. Solche Plaene sind Jahre alt. Das einzige wo es mir immer noch verdammt schwer faellt zu glauben ist dass der Tesla K10 TDP lediglich bei 225W liegt.

Aber lassen wir einfach die Erbsenzählerei. Bringt doch eh nichts :rolleyes: Schaumer einfach mal, was denn jetzt wirklich wann wo und wie kommt ;)

Lange dauert das Q4 ja nicht mehr.

Ein "told you so" wird von Charlie auf jedem Fall kommen und ich gehe diesbezueglich sogar gerne eine Wette ein :P

Godmode

2012-11-05, 16:43:58

und ich gehe jetzt nicht so tief in die Haarspalterei ob es stimmt oder nicht (wenn NV die ersten K20 zum Verkauf freigibt wird sich das Raetsel schon loesen). Der Punkt ist eben dass es 15 SMX bins eben nicht sind;

Willst du damit sagen das es gar keine mit 15 zu kaufen geben wird?

boxleitnerb

2012-11-05, 16:52:06

Hugo78

2012-11-05, 18:17:35

Ob NV/TSMC die 15 SMX Version in Masse liefern kann, ist mit Blick auf die Geforcereihe und die Wirtschaflichkeit allgemein, eh nicht zielführend.

Hier muss man sich doch nur zwei Fragen stellen:

1. Was kann AMD als nächsten Topdog bringen, wenn die GHz Ed. schon 250W braucht. link (http://www.pcgameshardware.de/Grafikkarten-Hardware-97980/Tests/Test-der-Radeon-HD-7970-GHz-Edition-907095/)
Laut Gerüchteküche, steht ein Plus von 15% bei gleichem Stromverbrauch im Raum, dass klingt auch erstmal realistisch.

2. Und was müsste NV als Minimum liefern um hier wieder knapp vorn zuliegen?
Dabei muss man sich auch vor Augen führen, wie verhältnissmässig stark GK104 allein mit steigender Bandbreite zulegt, ohne sonstiges OC. link (http://www.pcgameshardware.de/Grafikkarten-Hardware-97980/Tests/Overclocking-Test-Geforce-GTX-680-Radeon-HD-7970-875267/)

Also ich kann mir vorstellen, dass ein 13SMX GK110 mehr als ausreicht, einen Tick schneller zusein, bei besserer Perf./W.
Sofern er mit etwas mehr als 900Mhz rennt und nicht auch noch wieder beim SI beschnitten wird...

Denn 2013 ist lang und Maxwell kommt sicher nicht vor 2014, da braucht es aus wirtschaftlicher Sicht noch Platz für ein Refresh Ende 2013.

boxleitnerb

2012-11-05, 18:30:21

Ich sehe da einmal +7%/+4% (680 u. 7970) bei BF3, bei Metro 2033 ist es gerade andersherum mit dem Gewinn durch mehr Bandbreite. Oft bringts auch fast gar nix:
http://www.gtreviews.co.uk/gtx-680-sli-memory-overclocking/
Wobei es da fraglich ist, ob wirklich fordernde Einstellungen (MSAA+hohe Auflösung) getestet wurden.

Die GHz Ed. kam doch als Referenzdesign praktisch nicht in den Handel, die Partnermodelle brauchen allesamt klar weniger. Bissl mehr als die 7970 ist es meist schon, aber es geht auch sparsamer, siehe hier: http://www.hardocp.com/article/2012/10/30/xfx_double_d_hd_7970_ghz_edition_video_card_review/10
AMD war absolut bescheuert, die Karte so testen zu lassen, das gab nur negative Publicity.

OgrEGT

2012-11-05, 20:02:22

Die werden hoffentlich für Geforce gesammelt :)

Es geht ja drum, welcher bin den Großteil von den Chips eines Wafers darstellt. Charlie meint wohl 13 SMX, ich schätze 14 SMX. 15 wird es eben nicht sein, das ist auch unrealistisch, dass bei den meisten generell funktionellen Chips gleich alle 15 SMX laufen.

Gab es das überhaupt mal irgendwo? Also dass (unabhängig von den process yields) die binning yields beim kompletten Ausbau am größten waren? Kann ich mir ehrlich gesagt nicht vorstellen. Es dürften mehr "GTX570" vom Wafer gefallen sein als "GTX580", dasselbe mit 280/260, 7970/7950 usw. usf. Man korrigiere mich bitte, falls ich falsch liege. Aber bei so großen Chips ist es mMn wahrscheinlicher, dass ein Chip "kaputt" ist als dass er vollkommen heile ist.

Wobei es bei binning um die Erfüllung der jeweils festgelegten Spezifikation geht. Das schließt auch ein Power Target ein, welches der Chip bei x aktiven Einheiten einhalten muss. Das kann dazu führen, dass ein Chip voll funktionsfähig ist, aber kastriert werden muss, da er mit allen aktiven Einheiten das Power Target sprengen würde.

Godmode

2012-11-05, 20:45:44

Wobei es bei binning um die Erfüllung der jeweils festgelegten Spezifikation geht. Das schließt auch ein Power Target ein, welches der Chip bei x aktiven Einheiten einhalten muss. Das kann dazu führen, dass ein Chip voll funktionsfähig ist, aber kastriert werden muss, da er mit allen aktiven Einheiten das Power Target sprengen würde.

In der Vergangenheit wurde es ja meistens mit der Taktfrequenz kombiniert, dh. weniger Einheiten und weniger Takt. Wird wohl auch dieses mal so sein...

Ailuros

2012-11-06, 06:38:45

Willst du damit sagen das es gar keine mit 15 zu kaufen geben wird?

Kann ich noch nicht mit Sicherheit wissen. Der Punkt ist dass wenn Tesla K20 mit N Spezifikationen in perf/W konkurrenzfaehig ist besteht kein einziger Grund NICHT den groesstmoeglichen bin zu benutzen, egal ob es jetzt 13 oder 14 SMXs sind.

Bei 15 SMXs hypothetisch wuerde die Frequenz sowieso nicht ueber 705-732MHz
steigen; je nach Frequenz waere der Unterschied zu den OakRidge SKUs irgendwo zwischen 5 und 7%.

Wobei es bei binning um die Erfüllung der jeweils festgelegten Spezifikation geht. Das schließt auch ein Power Target ein, welches der Chip bei x aktiven Einheiten einhalten muss. Das kann dazu führen, dass ein Chip voll funktionsfähig ist, aber kastriert werden muss, da er mit allen aktiven Einheiten das Power Target sprengen würde.

Dave Baumann sagte mal bei B3D dass die reine de-aktivierung von clusters (stets in Grenzen) den Stromverbrauch sehr wenig beinflusst wenn die Frequenzen gleich bleiben und ich hab auch keinen Grund ihm nicht zu glauben. Anders ob 15SMX@732MHz oder 14SMX@732MHz (bei gleicher Speichermenge, Speicherfrequenz etc.) duerfte es nicht sehenswert den TDP beinflussen.

Es ist aber eben so dass in der breiten Mehrzahl der Faelle weniger clusters mit niedrigeren Frequenzen kombiniert werden. In solch einem Fall ist es mir schon klar dass die meisten denken dass die de-aktivierung weniger clusters den Stromverbrauch beinflusst.

Im gegebenen Fall geht es IMHO nur um binning yields.

G 80

2012-11-06, 14:16:32

Das mit den Clustern würde ich gerne mal untersucht sehen, aber mal kleines Gedankenspiel.

Jetzt rein von der Logik: Wenn ich von 15 einen abschalte hab ich (Basis 14 fürs rechnen) 1/14 - maximal - eingespart.
Wären also bei sagen wir 225 W maximal 32 W. (was aber kompletter Blödsinn ist, ist ja nicht nur der Chip alleine ..... aber lassens wirs mal so stehen)

Realistisch wirds wohl so zwischen 3 und ka max. vielleicht 8 W sein - das fällt schon unter die normale Streuung ..... :freak:

Anders siehts wohl aus wenn sagenwir nen G 80 A 2 auf 88 GTX und 88 GTS vergleiche. Letzterem fehlen gut ein Viertel der Shader und ein Fünftel der Rops/Vram; das man das selbst bei gleichen Taktraten noch merkt ist auch klar. Wobei man ja nicht vergessen darf das die kaputten Chips ja nicht ohne Grund auf kleine Karten gesetzt werden; seis weil wirklich ein Cluster hinüber ist oder er eben über x Frequenz anfängt zu saufen - streuts alleine durch solche Gründe enorm.

Ist jetzt aber eher ein extremes Beispiel und dazu müssten dann schon bei nem GK 110 4+ SMX tot sein ...

Also rein Gedanklich ist shcon die Aussage von Bauman nachzuvollziehen, und ich sehe kein Bespiel das dem extrem Widerspricht.

Coda

2012-11-06, 14:22:11

Jetzt rein von der Logik: Wenn ich von 15 einen abschalte hab ich (Basis 14 fürs rechnen) 1/14 - maximal - eingespart.
So einfach ist das nicht. Man hat öfters Mal Ausreiser von Chipteilen die eine viel höher Spannung brauchen um mit dem gleichen Takt zu laufen.

Das ist neben Defekten auch eine Aufgabe des Binnings.

Gipsel

2012-11-06, 14:42:19

G 80

2012-11-06, 14:46:33

ähm

(was aber kompletter Blödsinn ist, ist ja nicht nur der Chip alleine ..... aber lassens wirs mal so stehen)

nicht ohne Grund auf kleine Karten gesetzt werden; seis weil wirklich ein Cluster hinüber ist oder er eben über x Frequenz anfängt zu saufen - streuts alleine durch solche Gründe enorm.

Stimmt natürlich was du schreibst, aber ich hab schon gehofft es ist auch klar, das ich das miteinbeziehe wenn ich so allgemein schreibe. ;)

€:

Realistisch wirds wohl so zwischen 3 und ka max. vielleicht 8 W sein - das fällt schon unter die normale Streuung ..... :freak:

Sind dann 1,3 bzw. 3,5 % und wie gesagt geht völlig in der normalen Streung unter - schreibe ich so unverständlich oder überfliegts ihrs nur? ;)

€2: Aber mal was anderes ist eigentlich irgendwas in Entwicklung um derartiges Gating ohne einen größeren Transistoraufwand (ohne gehts ja nicht, die zusätzliche Logik wird einem leider nicht geschenkt) zu realisieren. Besteht überhaupt Bedarf jenseits von wünschenswert wärs?

Locuza

2012-11-06, 15:52:29

Trinity kann doch auch einzelne SIMDs-Arrays powergaten?
http://www.abload.de/img/173bua5.png

Hübie

2012-11-06, 17:41:22

Was würdet ihr sagen wenn ein SMX auf GK110 nicht 192 sondern 240 CUDA-Cores hat?

Gipsel

2012-11-06, 17:48:30

Was würdet ihr sagen wenn ein SMX auf GK110 nicht 192 sondern 240 CUDA-Cores hat?
Das es nicht stimmt. Das widerspricht nämlich der Beschreibung in nVs eigenem Whitepaper zum GK110 (http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf). ;)

Selbst wenn Du die ominösen DP-Einheiten als separate Einheiten zählst (was sie ziemlich sicher nicht sind), dann wären es höchsten 192 SP- und 64 DP-Einheiten, also zusammen 256.

Hübie

2012-11-06, 17:51:40

Verdammt. Wär mal ne neue Spekulation. Nu haste se im Keim erstickt ;D

Gipsel

2012-11-06, 18:40:02

Trinity kann doch auch einzelne SIMDs-Arrays powergaten?
http://www.abload.de/img/173bua5.pngDas höre ich zum ersten Mal. Daß das komplette Shader-Array bei Trinity (wie auch bei Bobcat) gegated werden kann, ist ja bekannt. Aber einzelne SIMDs? AMD schildert es normalerweise so, daß sie bei niedrigeren Anforderungen alle SIMDs bei einem niedrigeren Takt betreiben (dann bringt es auch die ganze Work distribution nicht durcheinander). Wer weiß, ob das in der Folie nicht nur ein Block sein soll.

Egal, so oder so sagt das alleine über die dedizierten Grafikkarten auch noch nicht so viel aus, zumal GF betont, daß in ihrem 32nm Gate First SOI-HKMG-Prozeß Powergate-Transistoren erheblich besser funktionieren (sie belegen bei gleichen Fähigkeiten angeblich deutlich weniger Fläche) als in TSMCs Gate Last bulk-HKMG Prozeß, so daß es bei TSMC nur für low power Chips praktikabel wird (weil sonst das Powergating Unmenge an Fläche frißt). Die 40nm Chips hatten kein solches Powergating. Und AMD bewirbt das Powergating des Shaderarrays (es ist auf den Folien etwas zweideutig formuliert, aber eine klare Ansage, daß sie einzelne CUs gaten, machen sie nicht, sie sprechen nur von der "engine" im Singular) eigenartigerweise nur bei CapeVerde-Mobilchips, Pitcairn kann das angeblich schon nicht mehr (verbraucht schon zuviel?). Ansonsten können nur kleinere Bereiche gegated werden, wie z.B. der UVD-Bereich. Das ZeroCore-Feature funktioniert soweit ich weiß auch nicht über Powergating. Da wird einfach die Spannungsversorgung für die GPU (bzw. den Großteil davon, das PCI-Express-Interface wird von einer kleinen Extraphase weiterversorgt) an den Spannungsreglern gekappt.

OgrEGT

2012-11-06, 18:43:58

Und es ist sogar noch komplizierter, weil man natürlich die einzelnen SMx nicht powergaten kann (höchsten clockgaten). Was man also spart, ist nicht 1/14 der Stromverbrauchs, sondern 1/14 des dynamischen Stromverbrauchs der SMx. Leaken tut das Ding nach wie vor (ist mit HKMG etwas besser geworden als noch in 40nm). Außerdem verbrauchen nicht nur die SMx Strom, der ganze Rest vom Chip natürlich auch.

Im Endeffekt wird von Deinem 1/14 vermutlich nur 1/30 oder so übrig bleiben. Und 3% bis 4% sind dann irgendwann wirklich kaum noch entscheidend, wenn man es mal mit +16% vergleicht, die durch eine 5% Taktanhebung begleitet von einer 5% Spannungsanhebung zu erwarten sind. In dem Zusammenhang ist die Aussage von Dave Baumann zu sehen. ;)

Klar. # Einheiten, TDP sind nicht die einzigen Kriterien. Bei den Salvage parts wird meist ja auch das Speicherinterface reduziert, zusätzlich Frequenzen und damit evtl auch Spannung gesenkt. All das in der Summe kann dann dazu führen, dass ein eigentlich voll funktionsfähiger Chip teildeaktiviert und limitiert werden muss damit das Powertarget eingehalten werden kann.

G 80

2012-11-07, 05:41:44

Nochmal zu den einzelnen Simds: Ich dachte ich hätte in Erinnerung das PCGH im Trinity Review was dazu geschrieben hat:

Im Leerlauf sinkt die CPU-Frequenz auf 1,4 GHz (7x 200 MHz) und Power Gating deaktiviert nicht benötigte Chipteile, darunter einzelne Module, die GPU-Kerne, den UDV3 oder das PCI-Express-Interface.
- http://www.pcgameshardware.de/CPU-Hardware-154106/Tests/AMD-Trinity-Test-883503/

Aber nix was man nicht eh schon weis bzw. Klarheit bringen würde. Ich gehe ehrlich gesagt davon aus, das die jweilige Funktionsgruppe als Block zu verstehen ist.

Ailuros

2012-11-07, 06:38:24

Stromverbrauch hin und her, es bleibt eine zweifellose Tatsache dass man mit einem zusaetzlichem cluster (und gleichen Frequenzen) in solchen Faellen (16SMs oder 15SMXs) nicht mehr als ca. 5% Leistung dazugewinnt.

Ergo auf rein praktischer Basis angenommen NV veroeffentlicht nur einen 14SMX desktop chip bei sagen wir mal 850MHz ist es ein Netto Verlust von ca. 5% gegen 15 SMX und wenn sie dann Monate spaeter eine 15 SMX Variante nachladen sollte dann eben auch mit hoeherer Frequenz weil sonst ein refresh keinen Sinn machen sollte. Diesbezueglich ist es nach wie vor wurscht ob es beim ersten release 14 oder 15 SMXs sind so lange sie ~850/1500 an Frequenzen mit logischem Stromverbrauch erreichen koennen.

G80,

Ich hab ehrlich gesagt keine Ahnung wie es auf Trinity oder anderen desktop SoCs wirklich aussieht, aber ein SoC ist auch ein ganz anderes Tier als eine high end desktop standalone GPU. Im ersten Fall - da die Dinger auch in notebooks integriert werden - ist Stromverbrauch um zich Male wichtiger als auf einer high end GPU. Bei einem 7.1Mrd. chip der locker =/>250W verdonnern kann wird man wohl schwer an zusaetzliche Logik fuer power gating denken.

V2.0

2012-11-07, 07:52:04

Da NV vor der Refreshgeneration von AMD launchen wird, macht es Sinn am unteren Level der Möglichkeiten zu beginnen, da man so selber noch einen Refresh von GK110 bringen kann, der nicht völlig absurd ausfallen wird.

14SMX 13SMX@ 850 > 13SMX15SMX@ 950Mhz ~ 20-22% mehr Leistung

boxleitnerb

2012-11-07, 07:58:18

Dafür müsste man einen neuen Chip designen, GK110 hat ja nur 15 SMX. 950 MHz wirds nicht geben in 40nm 28nm, zaubern kann Nvidia auch nicht.

Ailuros

2012-11-07, 08:10:06

Dafür müsste man einen neuen Chip designen, GK110 hat ja nur 15 SMX. 950 MHz wirds nicht geben in 40nm, zaubern kann Nvidia auch nicht.

ROFL GK110 wird auch nicht unter 40nm hergestellt :P

Sonst sind nach N Monaten 10% hoehere Frequenzen schon moeglich; die Frage waere dann eher ob man es wirklich brauchen wird. AMD klingt mir schon seit einiger Zeit nicht mehr nach einem IHV der genug Resourcen auflegen kann fuer zich kurzfristige refreshes. Teufel bis jetzt war NV sogar mit nur einem 15% Leistungsunterschied zu AMD's performance GPUs "zufrieden". Sonst haetten sie auch einen 580-refresh hinterlegen koennen mit 10% Mehrleistung und einem TDP irgendwo zwischen 250 und 300W. Irgendwo heisst es eben "gut genug" und man konzentriert sich auf andere Sachen.

boxleitnerb

2012-11-07, 08:12:01

Darf man sich denn nichtmal vertippen hier... :cool:

Ailuros

2012-11-07, 08:17:35

Darf man sich denn nichtmal vertippen hier... :cool:

Passiert jedem. Ich musste aber trotzdem lachen dass Du Ihn korrigiert hast und es hat sich noch ein zusaetzlicher Fehler/typo reingeschlichen ;)

boxleitnerb

2012-11-07, 08:19:36

Ich hab eigentlich nicht den Eindruck, dass sich ein IHV in der nächsten Zeit traut, eine SGPU-Karte rauszubringen mit mehr als 250W TDP. Die Zeiten haben sich geändert.

Ailuros

2012-11-07, 08:34:52

Ich hab eigentlich nicht den Eindruck, dass sich ein IHV in der nächsten Zeit traut, eine SGPU-Karte rauszubringen mit mehr als 250W TDP. Die Zeiten haben sich geändert.

Was meinst Du mit "trauen"? Macht es ueberhaupt irgendwelchen Sinn? Im Vergleich zu Cayman haette ein >244W TDP GF110 schon Sinn gemacht, wenn NV wirklich so geil darauf gewesen waere einen groesseren Abstand zur ersten zu haben.

Mit PCI-e 3.0 sehe ich keine besonderen Probleme per se fuer >250W und zu guter letzt mGPUs sind auch fast immer bei 290-300W. Wenn es jetzt wirklich notwendig waere etwas mit 260-270W zu veroeffentlichen ist es kein Weltuntergang. Der board form factor ist fuer solche GPUs so oder so bei 300W.

boxleitnerb

2012-11-07, 08:43:26

Hübie

2012-11-07, 08:54:02

GF110 überschreitet aber gerne mal die angegebenen 244 Watt. In Zeiten steigender Energiepreise überlegt sich jeder genau was er zum rollout bringt und was nicht. Und GK110 wäre schlecht beraten mehr als 250 Watt zu versemmeln. Wenn ich mir allerdings AMDs Gigawatt-Edition ansehe bin ich mir nicht sicher ob bei allen die Überlegungen zu Ende geführt werden.

boxleitnerb

2012-11-07, 08:57:59

Nun wie gesagt, diese GHz Edition aus den Tests gibt es im Handel praktisch nicht. Die Referenzkarte läuft bei bis zu 1.256V durch den Boost; bei den 7970 GE der Partner ist das eigentlich immer niedriger oder der Takt höher. AMD hat sich echt keinen Gefallen getan, das Referenzdesign überhaupt testen zu lassen.

Ailuros

2012-11-07, 09:06:42

Technisch geht es, keine Frage. Aber es kommt nicht gut an - die Leute schauen heute verstärkt auf Effizienz. Wenn man für die letzten 5-10% nochmal 10-20% mehr Strom verbraucht, wird das nicht gern gesehen, auch im Highend. Nvidia wurde zurecht dafür gerüffelt, dass der Verbrauch seit G80 stetig stieg und man sich die Leistung zu einem beträchtlichen Teil so erkaufte. Wenn man damit jetzt weitermachen würde, müsste man sich unweigerlich die Frage stellen, wo es aufhört. Hat Maxwell dann 350W und Einstein 400W?

mGPU ist ja wieder was anderes, das lief eigentlich schon immer "außer Konkurrenz" mMn.

Wir stimmen eigentlich ueberein. Ich sage lediglich dass wenn NV hypothetisch zu stark unter Druck gesetzt wuerde, wuerden sich auch etwas nachlaessiger sein mit dem TDP stets aber immer noch in Grenzen. G80 ist ein ganz anderes Kapitel da es unter 90nm hergestellt wurde ebenso wie dessen Vorgaenger.

Es ist alles bis zu einem Punkt relativ zu dem was die Konkurrenz auftischt; wenn AMD hypothetisch eine GPU veroeffentlichen wuerde die 250W verbraucht und zu gefaerhlich nahe an GK110 Leistung liegen wuerde, haette NV keine andere Wahl. Keiner dieser Thesen sind reale Moeglichkeiten und mit Verlaub 10-20W hypothetisch hoeheres TDP ueber 250W sind ein ganz anderes Kapitel als Dein 350-400W Beispiel.

boxleitnerb

2012-11-07, 09:14:16

Ailuros

2012-11-07, 09:27:43

Ich meinte ja ausgehend von G80. GT200 wurde in 65nm hergestellt und hat mehr verbraucht. GF100 in 40nm und hat nochmal mehr verbraucht. GK110 in 28nm und evtl. nochmal mehr. Das wäre schon ein Trend.

Andere Frage:
Warum muss Nvidia immer schneller sein? Die 590 haben sie nicht weiter hochgeprügelt, die 680 erst recht nicht. Gleichstand bei gleichem Verbrauch ist doch auch ok. Nvidia zeigt doch mit GK104, dass man auch etwas langsamere Karten sehr gut verkaufen kann, wenn Nvidia draufsteht und die Features stimmen.

Es gibt nirgends einen Gleichstand bei gleichem Verbrauch zwischen Tahiti und GK104. Die GTX680 hat einen offiziellen TDP von 195W und hat einen 225W board form factor (2*6pin); ob man jetzt innerhalb dem letzten 170 oder 200W verbraucht ist es ziemlich wurscht so lange die Leistung stimmt. Oder willst Du mir weissmachen dass sich die GTX680 schlechter verkauft haette wenn sie einen 210W TDP und 6pin+8pin haette? GK104 ist nach wie vor performance Material und bei dem bis heute Strassenpreis waere ein 300W form factor bei weitem kein Problem; nicht mal ein 4GB framebuffer egal wie ueberfluessig.

Single chip high end ist fuer NV stets seit einigen Jahren 6pin+8pin und wie Huebie schon oben sagte es ist eben nicht so dass eine GTX480 "nur" 250W verdonnert unter Umstaenden.

Nochmal der eigentliche Punkt ist dass wenn man mit N TDP gut anliegt gibt es keinen Grund an aggressivere Strategien zu denken; in jeglichem Gegenfall kann man unter Umstaenden etwas nachlaessiger mit einem logischen Prozentual von TDP sein um den gewuenschten Unterschied zu erreichen.

boxleitnerb

2012-11-07, 09:44:27

Es gibt nirgends einen Gleichstand bei gleichem Verbrauch zwischen Tahiti und GK104. Die GTX680 hat einen offiziellen TDP von 195W und hat einen 225W board form factor (2*6pin); ob man jetzt innerhalb dem letzten 170 oder 200W verbraucht ist es ziemlich wurscht so lange die Leistung stimmt. Oder willst Du mir weissmachen dass sich die GTX680 schlechter verkauft haette wenn sie einen 210W TDP und 6pin+8pin haette? GK104 ist nach wie vor performance Material und bei dem bis heute Strassenpreis waere ein 300W form factor bei weitem kein Problem; nicht mal ein 4GB framebuffer egal wie ueberfluessig.

Single chip high end ist fuer NV stets seit einigen Jahren 6pin+8pin und wie Huebie schon oben sagte es ist eben nicht so dass eine GTX480 "nur" 250W verdonnert unter Umstaenden.

Nochmal der eigentliche Punkt ist dass wenn man mit N TDP gut anliegt gibt es keinen Grund an aggressivere Strategien zu denken; in jeglichem Gegenfall kann man unter Umstaenden etwas nachlaessiger mit einem logischen Prozentual von TDP sein um den gewuenschten Unterschied zu erreichen.

Ich meinte Venus vs GK110. Da könnte man sich ja auch mit einem Unentschieden begnügen, statt unbedingt wieder 10-15% schneller sein zu müssen.

Bzgl. GK104 vs. Tahiti muss man schon ehrlich sein: Es gibt einen Unterschied bei der Effizienz, aber der ist doch recht klein und hängt vor allem von der Auflösung und vom Spiel ab. Der Catalyst 12.11 hat ja nochmal ein paar Prozent draufgelegt.

210W vs. 195W ist praktisch "egal", mein Punkt ist, dass es eine psychologische Sache ist, wenn die Maximalgrenze für eine sGPU-Karte wieder hochgesetzt wird.

Ailuros

2012-11-07, 09:52:48

Ich meinte Venus vs GK110. Da könnte man sich ja auch mit einem Unentschieden begnügen, statt unbedingt wieder 10-15% schneller sein zu müssen.

Hier sieht es bis jetzt nach allen Indizien nicht mehr als 7970GE+15% aus. Ergo besteht erstmal ueberhaupt kein Grund an irgendwelche extreme Turnereien zu denken.

Bzgl. GK104 vs. Tahiti muss man schon ehrlich sein: Es gibt einen Unterschied bei der Effizienz, aber der ist doch recht klein und hängt vor allem von der Auflösung und vom Spiel ab. Der Catalyst 12.11 hat ja nochmal ein paar Prozent draufgelegt.

Bei perf/W liegt die 104 aber immer noch nicht im Nachteil und es ist eben nicht so dass NV's Treiberteam nur sich den Hintern kratzt.

210W vs. 195W ist praktisch "egal", mein Punkt ist, dass es eine psychologische Sache ist, wenn die Maximalgrenze für eine sGPU-Karte wieder hochgesetzt wird.

Siehe erster Paragraph oben. Wenn Tahititi's Nachfolger =/>30% Leistung zulegen wuerde rein hypothetisch wuerde NV auch nicht nur die Haende kreuzen und dickkoepfig nur auf 240-250W TDP fuer GK110 beharren.

G 80

2012-11-07, 16:35:22

G80 ist ein ganz anderes Kapitel da es unter 90nm hergestellt wurde ebenso wie dessen Vorgaenger.

Va Vergessen darf man nicht das ein G80 SLI nicht soviel mehr verbraucht hat als zB X1950XTX CF (ich habe 40 W im Kopf) aber oft in hohen Quali Setting schon eine 88er Karte für das CF gepann gereicht hat.
Das ganze aber bei mehr Features, höherem DX Level und mehr Vram aber gleichen 90 nm.

zum Gating noch: Natürlich hast du recht, und mann muss auch sagen das die aktuellen Technologien, zumindest mir, reichen. Highend Grafikkarten die um die 20 W idlen sind, nach kein Stromsparmodus G 80 Zeiten, eine wohltat und ok. Ich war nur an dem Thema interessiert wegen der Trinity Folie.
Außerdem denke ich gäbs auch Fälle bei denen ein verbesserte Power Gating auch bei größeren Chips wünschenswert wäre (wenn billig ginge).

Ich wollte eigentlich noch die GTX 480M in Spiel bringen: GF 100 mit Drittel vom SI weg (aber 1/4 mehr VRam), 11 statt 16 Cluster, ~ 2/3 Chiptakt, und dafür 70 W TDP (waren da nicht 100 realistischer :uponder: ) gegen eben 250+.
Das müssen dann ja praktisch Chips sein die 470 Destop Lvl nicht mehr gepackt haben (warum auch immer), die aber in niedrigen Taktregionen noch recht genügsam bleiben, alles in allem.

Hübie

2012-11-07, 17:08:51

Erst kommende GPUs setzten auf deutlich dynamischeres Power-Management. Damit meine ich nicht Kepler sondern Maxwell and beyond. Es ist ohne hin nicht sehr einfach die Schaltungen zu implementieren. Angesichts der Packdichte und Größe von highend-GPUs war es auch kaum mehr möglich solche Dinge zuverlässig unterzubringen. AMD forschte schon 2005 an dem was wir jetzt zero core nennen.
Zugegeben ist es im Nachhinein recht simpel aber damals war es eine Herausforderung.

LG Hübie