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

[Hübie]

Na irgendetwas wird schon stimmen. Und sei es PCIe-3.0 ;D

[Nightspider]

Hätte man GF110 einfach in 28nm geshrinkt, wäre dieser merklich langsamer gewesen als GK104 bei größerer Fläche.

Glaubst du im Ernst das der Prozess dafür verantwortlich ist, für die +30%?

Eine GTX 460 hat damals kaum auf eine GTX 285 drauf gelegt, trotz neuem Prozess.

Die Kepler Architektur war und ist einfach stark im Vergleich zu Fermi. Und bei Maxwell könnte Nvidia das Gleiche wiederholen.

[fondness]

Macht ein großer 28nm Chip Mitte 2014 wirklich noch Sinn? Ich weiß nicht. IMO kommt von Maxwell höchstens Kleinkram in 28nm. GM104 erwarte ich bereits in 20nm Ende 2014. GM110 macht sowieso nur in 20nm oder womöglich 16nm (20nm FinFET) Sinn.

[Duplex]

Nvidia hat in jedem Segment konkurrenzfähige Produkte, die Leistunggskrone wurde mit der Ti gesichert, man kann bis ende 2014 damit den Marktz bedienen. AMD hat auch fast 2 Jahre keine neuen High End Karten vermarktet. Ich denke das Nvidia wenn überhaupt nur kleine Maxwell Chips für Broadwell Kombis plant, der Rest kommt in 20nm und danach mit FF.

[Nakai]

GK110 als Spielekarte ist für NV relativ wenig profitabel. Ein Gamingchip auf Titanniveau bei ~400mm² wäre hierbei besser.

GK104/114 hat 8 SMX, DP von 1:24, also genau 200SPs.
Für GM104 erwarte ich:
- SP-Ops auf DP-SPs
- mehr SPs pro SMX (256SPs pro SMX).
- ähnliche DP-Rate
- etwas mehr SMXs.

Spekus:
GM104 mit 10 SMX mit je 256SPs(davon 16 DP-SPs ingesamt; DP-Rate 1:16).

2560SPs(10 SMX; 5GPCs)
160TMUs
40 ROPs(5 ROP-Cluster)
320Bit SI(5 MCs)

In etwa 25% mehr als GK104 im Vollausbau. Performancezuwachs wird ähnlich sein, evtl etwas größer sein. Leistungszuwachs könnte wie GTX580 -> GTX680 sein(~30%). Sollte unter 400mm² möglich sein, je nachdem, welcher Takt und welche Packdichte kommt.

[Tesseract]

Hätte man GF110 einfach in 28nm geshrinkt, wäre dieser merklich langsamer gewesen als GK104 bei größerer Fläche.

Glaubst du im Ernst das der Prozess dafür verantwortlich ist, für die +30%?

natürlich ist vor allem der prozess dafür verantwortlich - in kombination mit schnelleren verfügbaren speicherchips. GK104 taktet höher und hat mehr transistoren trotz einsparungen beim speichercontroller und dem computezeug.
eine GK104-ähnliche umsetzung eines fermi wär eher was in richtung eines doppelten GF114 in 28nm mit ~1GHz takt.

[Sunrise]

Nvidia hat in jedem Segment konkurrenzfähige Produkte, die Leistunggskrone wurde mit der Ti gesichert, man kann bis ende 2014 damit den Marktz bedienen. AMD hat auch fast 2 Jahre keine neuen High End Karten vermarktet. Ich denke das Nvidia wenn überhaupt nur kleine Maxwell Chips für Broadwell Kombis plant, der Rest kommt in 20nm und danach mit FF.
NV rechnet in Q4 mit geringeren Margen. Rate mal, warum das so ist. Maxwell ist nicht nur eine Möglichkeit, die Leistung zu steigern, sondern evtl. auch um die Margen zu verbessern, im Preiskampf mit AMD.

NV kann es sich nicht erlauben, 2 Jahre zu warten, das ist einfach völliger Quatsch. NV weiß schon lange, das 20nm planar potentiell untauglich für deren GPUs ist. Und diese Zeit musst du irgendwie überbrücken.

[Mancko]

Maxwell wird IMHO im unteren Bereich in 28nm kommen und dort die Chips <= GK104 ersetzen.
Im High End hat Nvidia derzeit keinen Handlungsbedarf. Da wird alles beim alten bleiben. Das einzige was ich mir vorstellen könnte ist, dass sie zu gegebener Zeit die GTX690 ersetzen. Entweder durch deaktivierte und heruntergetaktete GK110 GPUs mit dem B1 Stepping oder durch Maxwell Nachfolger vom GK104.

[Gaestle]

Scheiss egal wie der Nachfolger heißt, sollte GM104 schneller als GK110 sein, dann wird Nvidia auch den neuen Chip wieder teuer verkaufen wollen, da gibt es nichts preiswerteres, deshalb wird GM104 gegenüber GK110 total uninteressant, paar neue Features, 512 Bit SI, 4GB & 5-15% mehr Performance als GK110. Große Performance Steigerungen wird man erst in 20nm & 16nm (20FF) sehen.

es ist eben nicht egal, welche chips in welchen segmenten einzuordnen sind. Seit einiger zeit kann es sich nv zwar leisten, mit performance-chips vorübergehend preisliches high-end zu bedienen. Dass heißt aber nicht, dass es aus der sicht von nv unsinnig wäre amd deutlich zu schlagen und zwar mit einem kleineren chip als gk110-b1.
Außerdem müssen sie sicherlich auch mit hpm erfahrungen sammeln und werden sich auch in dem prozess langsam steigern, mit dem größten chip als letzten release. Somit muss der kleinere chip sowieso kommen, und wenn er in der produktion billiger ist als gk110, ist es nur logisch, dass sie amd damit so schnell wie möglich angreifen und eben nicht 2014 komplett mit gk110 als hawai-konkurrenten aussitzen (oder verschlafen).

AMD ermöglicht momentan, dass nv die chip-klasse von der preisklasse entkoppeln kann. Deswegen sind es eben zwei parallele betrachtungen. Und wenn man sich beschwert, dass das nächste (preisliche) high-end in der leistung nur einen gewissen schnitt über gk110 liegt, dann sollte man nicht ignorieren, mit welcher chipklasse dieser erste schritt erfolgt und dass der eigentliche gk110-nachfolger eben erst in einem zweiten schritt dann in der gleichen chip-klasse wie gk110 stattfindet, die dann aber erst 6-12 monate später kommt.

Letztendlich fusst die ganze beschwerde darauf, dass der neue performance chip nicht doppelt so schnell ist, wie der alte maximalausbau. Das ist schlicht mit zweierlei maß gemessen.

Ich bezweifle auch 512bit für gm104. Man kann mit on-chip-caches offenbar auch viel erreichen und das an mehreren stellen im berechnungsprozess (auch für zwischenspeicherungen) und damit möglicherweise auch mehr effizienz erreichen, als mit einem stumpf breiteren SI als einzige maßnahme.

[Nightspider]

natürlich ist vor allem der prozess dafür verantwortlich - in kombination mit schnelleren verfügbaren speicherchips. GK104 taktet höher und hat mehr transistoren trotz einsparungen beim speichercontroller und dem computezeug.
eine GK104-ähnliche umsetzung eines fermi wär eher was in richtung eines doppelten GF114 in 28nm mit ~1GHz takt.

Der Prozess ist für einen "Grundsprung" verantwortlich wie von GTX285 zu GTX460 aber wieviel schneller ist ein GK104 als GF104? 150% schneller? Das lag definitiv nicht nur am Prozess sondern auch stark an der sehr guten Kepler Architektur.

Vielleicht kannst du dich noch erinnern als die Nvidia Ingenieure sagten, das sie mehr Leistung von der HD7970 erwartet hätten.
Nvidia weiß schon seit langem das 20nm womöglich kaum Effizienzvorteile bringen wird und wird deshalb schon lange massiv daran arbeiten, die Effizienz stark zu steigern.

Ein großer Sprung in der Architektur-Effizienz und Weglassen des Compute Ballast und schon ist ein GM104 deutlich schneller als eine 780ti.

[Coda]

Was soll bitte "Compute Ballast" sein?

Nennenswert ist da nur DP und das ist bei 104-GPUs sowieso schon minimalisiert.

[Knuddelbearli]

Der Prozess ist für einen "Grundsprung" verantwortlich wie von GTX285 zu GTX460 aber wieviel schneller ist ein GK104 als GF104? 150% schneller? Das lag definitiv nicht nur am Prozess sondern auch stark an der sehr guten Kepler Architektur.


Naja sin aber auch 160W vs 240W dazu bessere Auslastung der TDP durch Boost

[Ailuros]

Der Prozess ist für einen "Grundsprung" verantwortlich wie von GTX285 zu GTX460 aber wieviel schneller ist ein GK104 als GF104? 150% schneller? Das lag definitiv nicht nur am Prozess sondern auch stark an der sehr guten Kepler Architektur.

Eine GTX680 war bei ihrem launch um >80% schneller als eine GTX560Ti, aber auch mit deutlich hoeherem Stromverbrauch. Mit Treiber-updates stieg es dann langsam auf Faktor 2x an, ergo wenn man auf perf/W vergleicht (welches auch etwas gerechter ist) dann ist eine 660Ti schon um 80% schneller als eine 560Ti.

Theoretisch haette man die GK104 Leistung mit einem shrink eines GF114 unter 28nm erreichen koennen aber wie Tesseract schon sagt mit einer ziemlich extravaganten core Frequenz wobei aber das Resultat wieder verdammt blamierend waere bei einem perf/W Vergleich zwischen Fermi und Kepler.
-------------------------------------------------------------------------------------------------------------------------------------------

Nebenbei und obwohl ich fuer das OT genauso verantwortlich bin, darf ich daran erinnern dass einen dedizierten Maxwell thread gibt?

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

Da dieses komische hin und her der letzten paar Seiten als Ziel hat zu definieren ob NV etwas mit Maxwell unter 28nm anrichten koennte ist die Antwort von der technischen Seite ein ganz klares JA von mir; das warum "nicht" liegt dann im Tegra thread vergraben. Ich schreib mir ja schon seit Jahren die Finger wund dass sie beim letzten nur Scheiss bauen, aber ich mach es ja nur um die NV Juenger anzupinkeln oder? Schaut Euch mal die letzten News bzw. Analysten Reaktionen auf NVs finanzielle Zahlen an und es ist schnell zu sehen wo die Problematik liegt.

Sonst zurueck zum obrigen ein performance Maxwell braucht ungefaehr Titan Bandbreite IMHO um sich deutlich von GK104 absetzen zu koennen. Geht man so weit dann ist jegliche Aenderung auf Kepler Basis diesbezueglich Bloedsinn und man geht gleich ganz auf Maxwell und das meinte ich auch in meinem vorigen Post. Eine Milchmaedchen-Rechnung waere +50% Bandbreite im Vergleich zu GK104 und dementsprechend so viel mehr Einheiten um eine solche Steigerung zu unterstuetzen und +30% von architektur-bedingten Aenderungen (caches, cache-Effizienz, Daten-verleitungen etc.).

[robbitop]

Was soll bitte "Compute Ballast" sein?

Nennenswert ist da nur DP und das ist bei 104-GPUs sowieso schon minimalisiert.
Größere Caches, Register? War es nicht so, dass GK104 bei Compute ziemlich eingebrochen ist? Das muss schon nicht unwesentlich sein. Skalierst du linear (ich weiß - Milchmädchenrechnung) GK104 auf die Rohleistung von GK110, kommst du irgendwo bei 500...510 sqmm heraus (bzw ca. 6,5 von 7,1 Mrd Transistoren). Das sind immerhin 10 %.

[Ailuros]

Größere Caches, Register? War es nicht so, dass GK104 bei Compute ziemlich eingebrochen ist? Das muss schon nicht unwesentlich sein. Skalierst du linear (ich weiß - Milchmädchenrechnung) GK104 auf die Rohleistung von GK110, kommst du irgendwo bei 500...510 sqmm heraus (bzw ca. 6,5 von 7,1 Mrd Transistoren). Das sind immerhin 10 %.

Ist mir zu naiv selbst als Milchmaedchen-rechnung da der Bus breiter ist auf GK110 und der letzte auch 8x Mal so viele DP Einheiten hat pro SMX als GK104.

Und wieso sollte eine solche Milchmaedchen-rechnung ueberhaupt auf mm2 Basis und nicht auf Transistoren-Basis skalieren?

3.54Mrd. +50% = 5.31Mrd. und jetzt schnall einfach die Kosten eines 384bit bus noch mit.

[robbitop]

Um einen Vergleich zwischen GK110 und GK104 durhzuführen, skaliere ich GK104 auf die Ausführungseinheitenanzahl von GK110 hoch. Wenn ich 2880 / 1536 (1,875) dividiere, wird alles auf der GK104 mit dem Faktor skaliert. Dann komme ich auf 6,6 Mrd Transistoren. Ein paar müsste man abziehen, da das SI + ROPs nur 50 % breiter ist und nicht 87,5 % und sicher auch ein paar andere Dinge, die nicht mitskalieren (2D Teil, Videoprozessor...).

Dann liegt man irgendwo im Bereich 6...6,6 Mrd Transistoren. Also auf 84...92% der Größe eines GK110.Aber durch nicht oder nur teilweise Skalierung einiger Teilbereiche eher der untere Wert. Sind also ca. 10 %.

[Ailuros]

Mir klingt es als viel zu viel, ist aber bei so einer rein theoretischen Rechnung ziemlich egal.

[Nightspider]

Eine GTX680 war bei ihrem launch um >80% schneller als eine GTX560Ti, aber auch mit deutlich hoeherem Stromverbrauch. Mit Treiber-updates stieg es dann langsam auf Faktor 2x an, ergo wenn man auf perf/W vergleicht (welches auch etwas gerechter ist) dann ist eine 660Ti schon um 80% schneller als eine 560Ti.

Theoretisch haette man die GK104 Leistung mit einem shrink eines GF114 unter 28nm erreichen koennen aber wie Tesseract schon sagt mit einer ziemlich extravaganten core Frequenz wobei aber das Resultat wieder verdammt blamierend waere bei einem perf/W Vergleich zwischen Fermi und Kepler.[/b]

Okay, danke.
Ich hatte da größere Zahlen von GF104 auf GK104 im Kopf aber ich habe eben nochmal nachgeschaut, du hast Recht.

Allerdings muss man dem GK104 auch zu gute halten, das dieser stärker durch die Bandbreite ausgebremst wird als GF104, wenn nicht sogar recht stark.

Merkt man ja daran, das 670 kaum langsamer war als 680. Vor allem in hohen Settings. Mit einem 384Bit SI hätte GK104 sicherlich nochmal mindestens 20% zulegen können, schätze ich.

[Dural]

gf114 und gk104 nehmen sich nicht viel, ausser eben 40nm vs 28nm / 1,9 vs 3.5 miliarden transistoren.

[Felixxz2]

Wenn das so wäre, hätte sich nVidia GK110 auch sparen können, wenn ein GK104@384Bit auf die selbe Leistung kommt :freak:

[Knuddelbearli]

und was macht man dann mit dem Server / Profibereich? ^^

[Nightspider]

Ein GK110 kommt mit gleicher Taktrate und im Vollausbau aber eher Richtung +80% im Vgl zur 680, wenn nicht sogar 100%.

[fondness]

Größere Caches, Register? War es nicht so, dass GK104 bei Compute ziemlich eingebrochen ist? Das muss schon nicht unwesentlich sein. Skalierst du linear (ich weiß - Milchmädchenrechnung) GK104 auf die Rohleistung von GK110, kommst du irgendwo bei 500...510 sqmm heraus (bzw ca. 6,5 von 7,1 Mrd Transistoren). Das sind immerhin 10 %.

Auch ein GK110 ist bei Compute alles andere als berühmt. Da gibt es wenig Unterschiede zwischen GK104 und GK110. GK110 hat halt deutlich mehr ALUs.

[Ailuros]

Merkt man ja daran, das 670 kaum langsamer war als 680. Vor allem in hohen Settings. Mit einem 384Bit SI hätte GK104 sicherlich nochmal mindestens 20% zulegen können, schätze ich.

Die GTX770 hat knapp 17% mehr Bandbreite als eine GTX680. Wieso ist der durchschnittliche Unterschied dann in Echtzeit bei nur 4-6%? http://www.computerbase.de/artikel/grafikkarten/2013/nvidia-geforce-gtx-770-im-test/4/

Du bekommst durch die hoeheren Frequenzen einen schoenen 230W TDP fuer eine performance GPU wie die 770 und ich bezweifle dass es irgendwie besser gewesen waere mit einem 384bit bus:

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-770/specifications

Die Realitaet ist IMHO anders: der GK104 war nie wirklich original selbst fuer die GTX680 Hoehe ausgelegt aber fuer eher ein bescheideneres Nivaeu in der 660-660Ti Region. Schoen man kann eventuell hier und da aufpumpen aber am Ende macht Dir das Gesamtgeruest schon irgendwo schlapp. Du bekommst bei einem Kaefer mit einem Porsche-Motor auch nicht wirklich eine wahre Porsche oder?

Auch ein GK110 ist bei Compute alles andere als berühmt. Da gibt es wenig Unterschiede zwischen GK104 und GK110. GK110 hat halt deutlich mehr ALUs.

Es wurde schon zich Male etabliert dass es Unterschiede beim 110 gibt fuer caches und register file Groessen und dass es eben NICHT nur auf der Anzahl der ALUs beruht. So langsam koennte man es endlich schlucken. Sonst sind u.a. auch NV's OpenCL Treiber verdammt miserabel; im Gegenfall wuerde es zwar keine Wunder bringen aber es waere auf jeden Fall um ein gutes Stueck besser.

[Thunder99]

Dafür performet der Porsche-Motor Käfer schon ziemlich gut :D

Wie ihr aber auf bis zu +100% kommt gegenüber einer GTX680@1,GHz vs. 780Ti @1,1GHz (Quelle der Aussage CB) ist mir schleierhaft. OC der GTX780Ti bringt ihr gute 20% (mal mehr mal weniger). Ergo zur GTX680 eine Steigerung in Crysis 3 ~ +45%

Kommt noch eine GTX780i oder wird diese nur auf dem asiatischen Markt "vorgestellt"?

[Radeonfreak]

Dafür performet der Porsche-Motor Käfer schon ziemlich gut :D

Wie ihr aber auf bis zu +100% kommt gegenüber einer GTX680@1,GHz vs. 780Ti @1,1GHz (Quelle der Aussage CB) ist mir schleierhaft.

Das hab ich mich auch gefragt. :confused:

[Nightspider]

Bei Metro LL müssten es es ~85 % sein in angemessen hohen Auflösungen.

Und bei Crysis 3 sind es eher 60% gegenüber der 680.
Schließlich hat die 680 schon den größeren Grundtakt und wenn beide mit 1,1Ghz betrieben werden, müsste man bei einer Hochrechnung ~60% haben bei C3 unter 1920. Unter höheren Auflösungen natürlich mehr als 60%.

Wo genau stehst das mit +45% ?

[Radeonfreak]

http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/28513-nvidia-geforce-gtx-780-ti-im-test.html?start=15

Ich komm da auf bestenfalls 30-50%.

[Nightspider]

Ich sehe da 47% bei Stock-Taktraten. Bei 1,1 Ghz dürften es dann rund 60-70% sein.

Wobei Crysis3 eh auch stark CPU limitiert ist und man bei dem Spiel aufpassen muss.

[Coda]

Die GTX770 hat knapp 17% mehr Bandbreite als eine GTX680. Wieso ist der durchschnittliche Unterschied dann in Echtzeit bei nur 4-6%? http://www.computerbase.de/artikel/grafikkarten/2013/nvidia-geforce-gtx-770-im-test/4/

Du bekommst durch die hoeheren Frequenzen einen schoenen 230W TDP fuer eine performance GPU wie die 770 und ich bezweifle dass es irgendwie besser gewesen waere mit einem 384bit bus:

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-770/specifications

Die Realitaet ist IMHO anders: der GK104 war nie wirklich original selbst fuer die GTX680 Hoehe ausgelegt aber fuer eher ein bescheideneres Nivaeu in der 660-660Ti Region. Schoen man kann eventuell hier und da aufpumpen aber am Ende macht Dir das Gesamtgeruest schon irgendwo schlapp. Du bekommst bei einem Kaefer mit einem Porsche-Motor auch nicht wirklich eine wahre Porsche oder?



Es wurde schon zich Male etabliert dass es Unterschiede beim 110 gibt fuer caches und register file Groessen und dass es eben NICHT nur auf der Anzahl der ALUs beruht. So langsam koennte man es endlich schlucken. Sonst sind u.a. auch NV's OpenCL Treiber verdammt miserabel; im Gegenfall wuerde es zwar keine Wunder bringen aber es waere auf jeden Fall um ein gutes Stueck besser.
Die Caches und Register-Files pro SMX sind gleich groß.

[Hübie]

Ich verstehe Ail eher so dass er den ganzen Chip meint. Also L2-Anbindung und Größe pro GPC. Wie groß sind eigentlich texture- und shared-caches in GK104 bzw. GK110? Sind die ebenfalls exakt gleich groß pro SMX? TexC sind afaik 48 KB im GK104 SMX...

Edit: :redface: Stimmt ja. Ggü. Fermi ist der TexC nicht mehr nur ein reiner Textur-Cache.

256KB of register file space, 64KB of L1 cache, 48KB of uniform cache Quelle (http://www.anandtech.com/show/6446/nvidia-launches-tesla-k20-k20x-gk110-arrives-at-last/3)

Sind also alle gleich groß. Lediglich der L2 pro SMX ist dann halt unterschiedlich.

[Tesseract]

Der Prozess ist für einen "Grundsprung" verantwortlich wie von GTX285 zu GTX460 aber wieviel schneller ist ein GK104 als GF104? 150% schneller? Das lag definitiv nicht nur am Prozess sondern auch stark an der sehr guten Kepler Architektur.

der vergleich hinkt. die 285 ist ein ans limit geprügeltes monster, die 460 eine teildeaktivierte, relativ niedrig getaktete karte und die 680 irgendwo dazwischen. natürlich hat es eine 460 da im vergleich schwer.

dass kepler besser ist als fermi bestreitet ja keiner, aber der fertigungsprozessbereinigte unterschied ist - zumindest was die leistung betrifft - nicht so groß wie du es suggerieren willst.

[Hübie]

Hä? Mein smartphone spinnt voll rum...

Hier stand dass CB mal einen taktbereinigten Test GK104 vs. GF110 machte und dabei ~5% raus kamen. Is natürlich wegen der hotclocks etwas unfair aber die deutlich höhere ALU-Anzahl haut wieder was raus.

[Ailuros]

Die Caches und Register-Files pro SMX sind gleich groß.

GF1xx und GK104 haben alle 63 registers/thread; GK110 255/thread.

[Skysnake]

Naja sin aber auch 160W vs 240W dazu bessere Auslastung der TDP durch Boost
Ja, die TDP ist um 50% angewachsen, und der Transistorcount um 81,5%!

Das darf man auf keinen Fall unter den Tisch fallen lassen.

Größere Caches, Register? War es nicht so, dass GK104 bei Compute ziemlich eingebrochen ist?

Ja GK104 ist relativ stark eingebrochen bei Compute. Die kleineren Caches/ALU sind auch durchaus eine Kritik bei GK110. Man gleicht das teilweise aber auch wieder dadurch aus, das man mehr Register pro Wavefront nutzen kann. Unterm Strich aber nicht wirklich ein Fortschritt zu GF110. Und das Fazit kommt von jemandem, den sich nVidia inzwischen geholt hat.

Ein GM104 wird aber sicherlich NICHT die Register vergrößern, ehe sogar verkleinern/vereinfachen. Bei den Caches kommts drauf an. Der L1 wird wohl so bleiben, der Shared könnte aber schrumpfen, dafür der L2 wieder wachsen.

Ich erwarte auch 256ALUs/SMX und nicht mehr die 192ALUs/SMX. Das reduziert auch wieder den Verbrauch für die Instructionsdecodierung usw usw.

Bei Graphics dürfte das alles auch nicht wirklich negativ einschlagen. Ich gehe aber davon aus, das GM104 bei COmpute noch schlechter performen wird als GK104. Also jetzt relativ gesehen.

Der Abstand zwischen theoretischer Leistungsfähigkeit und der Realen wird ansteigen. Ist halt wie bei AMDs VLIW ein bischen. Das Ding war teilweise richtig göttlich, aber eben nur in ganz ganz wenigen Fällen bei COmpute.

Die kochen halt alle nur mit Wasser.

Auch ein GK110 ist bei Compute alles andere als berühmt. Da gibt es wenig Unterschiede zwischen GK104 und GK110. GK110 hat halt deutlich mehr ALUs.
GK110 bringt vor allem HyperQ, DynamicParallelism und GPUDirect 2.0, also zero copy RDMA über Infiniband.

DAS sind die Hauptvorteile von GK110, und die Sachen, die das Ding wirklich gut machen, und ihn von der Konkurrenz absetzen.

Das hat aber mindestens genau so viel mit Software zu tun, wie mit echter Hardware. :ugly:

nVidia ist halt wenn man sich mal so anschaut, was die so machen, genau so ein softwareunternehmen wie ein Hardwareunternehmen. Und meistens ist es die Software, die am Ende das Zünglein an der Wage spielt. Schon bitter irgendwie :D

[Ailuros]

Ich erwarte auch 256ALUs/SMX und nicht mehr die 192ALUs/SMX. Das reduziert auch wieder den Verbrauch für die Instructionsdecodierung usw usw.

Es sind schon 256 stream processors/SMX auf GK110 (192 FP32 + 64 FP64); ich kann mir nicht vorstellen dass die hw designer in dem Fall den Kopfschmerz FP64 nicht von Anfang mitberechnet haben. Bleiben sie bei SIMD32 oder werden die doch groesser; bleiben sie bei dedizierten FP64 SPs oder wird es eine neue Aenderung diesbezueglich geben? *schulterzuck*

[Skysnake]

Es wird ganz sicher Änderungen geben. bzgl DP.

Bei SIMD32 wird man wohl ziemlich sicher auch bleiben. Mehr macht eigentlich keinen Sinn, und würde tiefgreifende Änderungen erfordern bzgl der Softwarearchitektur.

[Ailuros]

Es wird ganz sicher Änderungen geben. bzgl DP.

Bei SIMD32 wird man wohl ziemlich sicher auch bleiben. Mehr macht eigentlich keinen Sinn, und würde tiefgreifende Änderungen erfordern bzgl der Softwarearchitektur.

Ein SMX hat ohnehin schon 6+2 SIMDs; weder die Anzahl der clusters noch die Anzahl der SIMDs kann IMHO unendlich breit werden. Zur Erinnerung bei G80 waren es mal 8 lanes/SIMD.

[Coda]

GF1xx und GK104 haben alle 63 registers/thread; GK110 255/thread.
Das hat nichts mit der Register-File-Größe zu tun. Beide haben 64k 32-Bit-Register pro SMX. Mehr Register in einem Warp benutzen zu können hilft nur in bestimmten Grenzfällen und braucht auch nicht bedeutend mehr Logik

[Sunrise]

...Sonst zurueck zum obrigen ein performance Maxwell braucht ungefaehr Titan Bandbreite IMHO um sich deutlich von GK104 absetzen zu koennen. Geht man so weit dann ist jegliche Aenderung auf Kepler Basis diesbezueglich Bloedsinn und man geht gleich ganz auf Maxwell und das meinte ich auch in meinem vorigen Post. Eine Milchmaedchen-Rechnung waere +50% Bandbreite im Vergleich zu GK104 und dementsprechend so viel mehr Einheiten um eine solche Steigerung zu unterstuetzen und +30% von architektur-bedingten Aenderungen (caches, cache-Effizienz, Daten-verleitungen etc.).
Das hört sich auch schon durchaus realistisch und machbar an.

Wird halt dann deutlich breiter und größer das Ding, als es GK104 war (meine Schätzung +30% ging ja etwa von GK104-Größe aus), aber für GM100/GM110 wäre dann auf 28nm nur noch wenig Platz für große Experimente, da so ein Design sicher um die 380mm²-420mm² liegen wird (eher am oberen Ende). Und an einen großen Maxwell auf 20nm planar kann ich nicht so recht glauben, wenn GM104 auf 28nm kommt. Identische Architektur bei unterschiedlichem Prozess innerhalb eines Jahres halt ich für extrem unwahrscheinlich. Daher auch meine Skepsis respektive eines so großen Sprungs.

Während GK104 dann eher eine im Takt recht hoch geprügelte, auf minimale Die-Size optimierte Kepler-Variante war (vs. 7970), wäre GM104 dann (gemäß obrigen Beispiel) wieder eine ausgeglichenere, balanciertere Variante insgesamt. GK104 konnte ja nur deshalb so klein sein, weil sowohl der Architektur- als auch der Prozess-Sprung vorhanden war und beides ziemlich große und starke Änderungen ermöglichte.

Wo ich aber wieder etwas dagegen haben werde, ist, wenn NV das Teil dann wieder über bzw. ab $649 MSRP und höher ansetzt. Denn dann sind wir bei noch abartigeren Preisen als bei GK110 mit noch kleinerem Die. Wird aber wohl passieren, wenn das wirklich eintritt und AMD bis dahin nichts deutlich schnelleres als die Ti liefern kann.

[boxleitnerb]

Es ist illusorisch, dass dieser Maxwell die 780 Ti erreichen wird. 780 Ti, 780 Ti Black Edition, Maxwell...laufend dasselbe Performancesegment zu refreshen macht keinen Sinn. Es gibt SKUs, die dringender eine Ablösung brauchen, GTX 650 Ti Boost, GTX 760, GTX 770. Der Chip wird sicher unterhalb von der 780 Ti angesiedelt sein. Preislich und von der Leistung her.

[Gaestle]

Es ist illusorisch, dass dieser Maxwell die 780 Ti erreichen wird.

rechne doch mal aus, wo die genannte schätzung landet (1,8x gk104). Und das ist ja (wahrscheinlich) kein wunschdenken, sondern eher erfahrung aus der vergangenheit.

[boxleitnerb]

rechne doch mal aus, wo die genannte schätzung landet (1,8x gk104). Und das ist ja (wahrscheinlich) kein wunschdenken, sondern eher erfahrung aus der vergangenheit.

Nur dass wir diesmal keinen entsprechenden Prozess haben. 28HPM mag besser sein als 28HP, aber Wunder würde ich keine erwarten. Zudem, was macht es für einen Sinn, die 780 Ti und die 780 Ti Black Edition zu bringen, wenn man sie zwei, drei Monate später gleich wieder einstampft?

[AffenJack]

Nur dass wir diesmal keinen entsprechenden Prozess haben. 28HPM mag besser sein als 28HP, aber Wunder würde ich keine erwarten. Zudem, was macht es für einen Sinn, die 780 Ti und die 780 Ti Black Edition zu bringen, wenn man sie zwei, drei Monate später gleich wieder einstampft?

Gabs bisher nicht immer nur Aussagen zu irgendwann Q1? Können also eh schon 5Monate werden. Und dafür brauchte man was zum Überbrücken und Konkurenzfähig bleiben. 780Ti ist billiger als Titan mit dem RAM und man lässt Titan nen Alleinstellungsmerkmal, anstatt sie auf die Hälfte ihres Preises zu senken.

Zu 780TI sinds nur 40%. Wie langsam soll Maxwell denn werden deiner Meinung nach? 30% sollte alleine durch nen breiteren Chip drin sein und noch paar % durch HPM, dann landest du schon bei der 780 Ti. Bloß dürfte das dann mit Hawaigröße möglich sein, was bessere Margen erlaubt.
Frag dich lieber, was fürn Sinn es machen würde Maxwell in 28nm zu launchen, wenn man nur 20% mehr Leistung als GK104 hinkriegt.

[Nakai]

Nur dass wir diesmal keinen entsprechenden Prozess haben. 28HPM mag besser sein als 28HP, aber Wunder würde ich keine erwarten. Zudem, was macht es für einen Sinn, die 780 Ti und die 780 Ti Black Edition zu bringen, wenn man sie zwei, drei Monate später gleich wieder einstampft?

Wir werden wohl erstmal keinen GM104 sehen. Eher GM106 oder GM108.
Mit Intels Iris GPU braucht man erstmal etwas im mobilen Segment. GK108 ist nicht ausreichend. Einen hypothesierter GM108 mit 3 SMX(je 256SPs) oder ein GM104 mit 5-6 SMX unter 28nm wäre im mobilen Segment notwendig.

28nm ist auch in Ordnung, solange man HPM nutzt. 20nm bleibt noch lange ziemlich teuer und eher für kleinere Stückzahlen erstmal nutzbar.
Ein Pipecleaner erwarte ich nur von AMD, Nvidia ist da konservativer...

[Ailuros]

Nur dass wir diesmal keinen entsprechenden Prozess haben. 28HPM mag besser sein als 28HP, aber Wunder würde ich keine erwarten. Zudem, was macht es für einen Sinn, die 780 Ti und die 780 Ti Black Edition zu bringen, wenn man sie zwei, drei Monate später gleich wieder einstampft?

Seit wir gesichert haben dass Hawaii 28HP ist und auch einer Aussage (wer war es nochmal?) die von jemand hier gepostet wurde dass HPM eigentlich mehr fuer mobile geeignet sei, hab ich so manche Zweifel dafuer und Maxwell (obwohl ich den angeblichen Mist mit Frequenzen auch nicht verstehen kann denn die Logan GPU wird unter 28HPM auch nicht gerade bescheiden takten...).

Sonst stimme ich voll mit Affenjack's letzten Post ein.

So und jetzt such ich mir vorsichtig die Maxwell relevanten Posts der letzten Seiten aus und schick sie in den Maxwell thread wo sie hingehoeren ;)

Dafür performet der Porsche-Motor Käfer schon ziemlich gut :D

Gut dann schmeiss mal eine echte Porsche mit der maximal moeglichen Geschwindigkeit in eine scharfe Kurve und versuch das genau gleiche mit dem Kaefer (wenn Du's zweite dann ueberhaupt ueberlebst).

Wie ihr aber auf bis zu +100% kommt gegenüber einer GTX680@1,GHz vs. 780Ti @1,1GHz (Quelle der Aussage CB) ist mir schleierhaft. OC der GTX780Ti bringt ihr gute 20% (mal mehr mal weniger). Ergo zur GTX680 eine Steigerung in Crysis 3 ~ +45%

Kommt noch eine GTX780i oder wird diese nur auf dem asiatischen Markt "vorgestellt"?

In 1600p + 4xAA wohl eher GTX780Ti vs. GTX680 je nachdem wie man sich die benchmarks ausgesucht hat 60-70% durchschnittlicher Unterschied. Bei einer 780Ti Black Edition@1GHz (oder wie die sonst heissen wird) wohl dann eher zumindest +70-80%. Ist aber auch ein daemlicher Vergleich weil eine 780Ti und co eher in Aufloesungen bedienen wuerde wo der 2GB framebuffer einer 680 ziemlich schnell schlapp machen wuerde.


Sonst um mich selber zu korrigieren GK104 ist schon fast 2x Mal schneller als eine GF114 wenn man die GTX770 mit der GTX560Ti vergleicht.

[Dawn on Titan]

28HPM kann für GM108/GM106 ein Thema sein. (bei GM104 halte ich das wegen der wahrscheinlichen Diegröße und Taktanforderung für eher unwahrscheinlich)

[Ailuros]

28HPM kann für GM108/GM106 ein Thema sein. (bei GM104 halte ich das wegen der wahrscheinlichen Diegröße und Taktanforderung für eher unwahrscheinlich)

Mach mal eine Liste wo jeweils GK106 bzw. GK107 fuer desktop genau takten.

[AffenJack]

Sind Xbox One und PS4 nicht auch 28nm HPM? Meine das früher gelesen zu haben. Die takten zwar etwas tiefer, aber so groß ist der Unterschied dann auch nicht mehr zu den Gpus.

[Dawn on Titan]

Mach mal eine Liste wo jeweils GK106 bzw. GK107 fuer desktop genau takten.
Für Desktop. Für Mobile liegen sie meist unter <825Mhz. Und da braucht man den Refesh imho am meisten. Wenn man nun davon ausgeht, dass sie bei der TDP keinen Spielraum haben (sie haben einen GK208 gemacht um die TDP zu drücken) scheint gegenwärtig nur 28HPM eine reale Option zu sein um Spielraum zu bekommen.

[Ailuros]

Sind Xbox One und PS4 nicht auch 28nm HPM? Meine das früher gelesen zu haben. Die takten zwar etwas tiefer, aber so groß ist der Unterschied dann auch nicht mehr zu den Gpus.

Das sind dann aber wieder SoCs; zugegeben ziemlich grosse aber trotzdem. Die NV Logan GPU soll doch im idealsten Fall auf fast 1GHz Frequenz unter 28HPM reichen.

Für Desktop. Für Mobile liegen sie meist unter <825Mhz. Und da braucht man den Refesh imho am meisten. Wenn man nun davon ausgeht, dass sie bei der TDP keinen Spielraum haben (sie haben einen GK208 gemacht um die TDP zu drücken) scheint gegenwärtig nur 28HPM eine reale Option zu sein um Spielraum zu bekommen.

Kein Einwand :)

[robbitop]

Auch ein GK110 ist bei Compute alles andere als berühmt. Da gibt es wenig Unterschiede zwischen GK104 und GK110. GK110 hat halt deutlich mehr ALUs.
Siehe die Skalierung. Für irgendwas müssen die 10 % ja gebraucht werden.

[Gaestle]

Seit wir gesichert haben dass Hawaii 28HP ist und auch einer Aussage (wer war es nochmal?) die von jemand hier gepostet wurde dass HPM eigentlich mehr fuer mobile geeignet sei, hab ich so manche Zweifel dafuer und Maxwell [...]

Was giobt es denn für Alternativen (ehrliche Frage)?

28HP zeigt in der R9 290X, dass man offenbar nahe der Grenze ist (auch wenn verschiedene Designs die Grenzen unterschiedlich weit verschieben können). 20nm kommt viel zu spät. Wenn R9 in 28HPM als Spekulation ernst genommen wurde, muss auch das Potential dafür da sein. Das und die Spekulation, dass HPM fast so leistungsfähig wie ein hypothetischer Zwischenschritt zu 20nm wäre (Meine ich irgendwo in den Speku-Threads zu Maxwell / 780Ti oder Hawai hier bei 3DC gelesen zu haben - AFAIR von einem Member, was ernstzunehmen ist).

[Undertaker]

(sie haben einen GK208 gemacht um die TDP zu drücken)

Eher um die Kosten zu drücken. GK208 ist durch das schmälere SI ziemlich bescheiden von der Energieeffizienz im Vergleich zu GK107.

[Dawn on Titan]

Eher um die Kosten zu drücken. GK208 ist durch das schmälere SI ziemlich bescheiden von der Energieeffizienz im Vergleich zu GK107.

TDP von 65 auf 49W im Desktop. HWLux hat rund 12-13W effektiv gemessen.

[ndrs]

Eher um die Kosten zu drücken. GK208 ist durch das schmälere SI ziemlich bescheiden von der Energieeffizienz im Vergleich zu GK107.
Beim Grund für den GK208 hast du sicher recht (Diesize für nV, PCB für die Partner), nicht jedoch bei der Effizienz. Der Chip ist auf der GT640 leicht schneller als GK107 bei deutlich geringerem Stromverbrauch (TDP 65W vs 49W). Da der Speicher weit von der Kotzgrenze entfernt ist und deshalb mit moderaten Spannungen laufen kann, sollte das 64Bit GDDR5 Interface einiges Sparsamer als das 128Bit-DDR3-Interface sein.

Edit: too late ...

[Ailuros]

Eher um die Kosten zu drücken. GK208 ist durch das schmälere SI ziemlich bescheiden von der Energieeffizienz im Vergleich zu GK107.

Nicht nur; GK208 ist der engste Verwandte von GK20A/Laguna.

[Undertaker]

Ich bezog mich da eher auf den Notebook-Bereich, wo GK107-Lösungen mit moderater Taktrate (~700 MHz) durch GK208-Modelle mit Boost-Taktraten im GHz-Bereich ersetzt wurden (GT 730M, 740M), während die Bandbreite bei gleichbleibendem DDR3-Speicher halbiert wurde. Folge: Schlechtere Performance bei ähnlichem bis höherem Verbrauch... :rolleyes:

Bei 64 Bit GDDR5 vs. 128 Bit DDR3 und konstanten Taktraten mag das anders aussehen.

[Ailuros]

Ich versteh schon was Du meinst aber das ganze wurde ja nochmal vom GK208 auf ULP SoC TDP Ebene reduziert. Bei voller Taktung fuer die Logan/GPU muessten es schon bis zu 10W TDP sein.

[Ailuros]

http://www.anandtech.com/show/7515/nvidia-announces-cuda-6-unified-memory-for-cuda

Meanwhile it’s interesting to note that this comes ahead of NVIDIA’s upcoming Maxwell GPU architecture, whose headline feature is also unified memory. From what NVIDIA is telling us they developed the means to offer a unified memory implementation today entirely in software, so they went ahead and developed that ahead of Maxwell’s release. Maxwell will have some kind of hardware functionality for implementing unified memory (and presumably better performance for it), though it’s not something NVIDIA is talking about until Maxwell is ready for its full unveiling. In the interim NVIDIA has laid the groundwork for what Maxwell will bring by getting unified memory into the toolkit before Maxwell even ships.

[Hübie]

War das nicht schon mal über ein slide so kommuniziert worden? :| Konkretes steht da ja nicht.

[Skysnake]

Ich weiß gar nicht, wo überhaupt das Problem mit dem unified Adressspace ist...

Das ist ne reine Treiber/Firmware Sache.

RDMA geht ja auch. Also was soll der Affenzirkus?

[Ailuros]

Ich weiß gar nicht, wo überhaupt das Problem mit dem unified Adressspace ist...

Das ist ne reine Treiber/Firmware Sache.

RDMA geht ja auch. Also was soll der Affenzirkus?

Das kommt sicher mit einer secret sauce wie bei Denver; was besonderes wird es nicht sein aber die engineers haben wohl Spass daran Dir Material zu geben damit Du drueber laestern kannst :freak:;D:eek:

[Skysnake]

Ich hab mich in den letzten Monaten sehr intensiv mit Addresstranslation und I/O-Remapping usw usf beschäftigt, und ich verstehs wirklich nicht, was da jetzt das Problem sein soll. Jetzt nicht mit GK110, aber nach dem was das Ding an sich kann, seh ich keinen Grund, warum man das nicht lauffähig machen können soll. Man braucht halt ne MMU, die sollte zumindest GK110 aber eh haben wegen RDMA.

Ob ich jetzt transparent in nen bar eines anderen PCI-E Devices schreib/lese, oder in den Hauptspeicher der CPU ist an sich scheis egal, man muss dem Host-OS halt nur mitteilen, das man die physikalischen Adressen als Speicher verwendet, damit es nicht die gleichen physikalischen Adressen für was anderes benutzt. Das würde sonst zu SEHR lustigen Ergebnissen führen ;D

[Hugo78]

Und das reicht wenn Nvidia vor hat ihre GPUs und künftigen Denver CPU Kerne auf einen Die zupacken und mit gemeinsamen Speicherzugriff?!
Ne Softwarelösung mit X Overhead wie sie jede Softwarelösung im Vergleich zu einer in HW hat?!

Komisch das ich da noch nichts von dir gelesen hab, als AMD mit ihrem hUMA angewackelt kam.
Ist das selbe in Grü ... ähm Rot.

[Skysnake]

Natürlich brauchst du Hardware in den GPUs! Die Hardware sollte nur eben bereits da sein ;) Ansonsten würden nämlich so manche anderen Spielereien nicht funktionieren, die beide machen.

Was halt fehlt ist die Implementierung in die Treiber für andere Dinge. An sich sollte die Hardware aber dazu bereits in der Lage sein. Sie hat halt "nur" noch keine entsprechenden API-Schnittstellen.

Ansonsten sprach ich auch eher von dGPUs. SOCs machen es an sich eigentlich einfacher, da man den selben Memorycontroller, die selben DMAs und auch die selben MMUs und TLB s nutzen kann. Das macht es an sich eigentlich einfacher. Man muss die Sachen "nur" verheiraten und entsprechende Arbiter implementieren.

Die Tücke steckt da halt im Detail, das in hardware performant zu machen, und zwar in 99% der Fälle. An sich wissen die Jungs und Mädels aber schon, was Sie zu tun haben, damit das läuft. Das ist relativ straight forward. Es braucht halt nur viel Zeit und Manpower, da man schon an vielen Stellen Hand anlegen muss.

[Coda]

Cache Coherency *hust*

[Skysnake]

Das ist nur für SOCs relevant.

Für dGPUs kann ich mir immer noch nicht so 100% vorstellen, wie AMD das performant implementieren will, aber ich lasse mich da gern überraschen.

Ansonsten kann man Cache-Cohärenz "einfach" ausklammern. Gerade bei GPUs ist das ja nichts, was unbedingt zwingend erforderlich ist. Erfordert halt andere Kommunikations-/Programmierparadigmen. Ist halt dann eher Messagepassing und kein Shared Memory, auch wenn man auf einem gemeinsamen Adressraum arbeitet. Muss ja wie gesagt nicht zwingend Cache-Cohärent sein, wobei man das bei SOC natürlich mitnehmen kann, aber dann auch klar mehr Aufwand bedeutet auf SEite der iGPU. Man muss die dann halt in MESI oder was auch immer mit einbinden.

PS:
Coda würdest du ernsthaft traurig sein bei dGPUs auf Cache-Kohärenz verzichten zu müssen? Klar nimmt man das gern mit, aber würde es wirklich weh tun? Kann ich mir nicht so recht vorstellen.

[Coda]

Wenn man keine Kohärenz hat, kann man es bleiben lassen. Das wäre unbeherschbar.

[Hübie]

Hab mir das eben durch gelesen. Ist ja eine reine Simplifizierung für Devs. Unter Umständen gehen damit Performance-Verluste einher. Also bis wirklich gemeinsamer Speicher genutzt wird dauert es noch. Bei der PS4 is das ja schon out of the box möglich (konstruktionsbedingt).

[Skysnake]

Wenn man keine Kohärenz hat, kann man es bleiben lassen. Das wäre unbeherschbar.
Naja, du sparst dir die Adressumsetzung bzw kannst Sie in Hardware erledigen. Auch sparst du dir die expliziete Copy wenn du Daten nur einmalig nutzt/änderst.

Klar musst du dich dann noch um die Syncs kümmern, aber einen Tod muss man halt sterben, und es gibt schlimmeres. Es muss halt "nur" performant sein.

[HPVD]

schön zusammenfassend erklärt was mit "CUDA6s unified memory" wie geht und was nicht ists hier:
The big news here – and the headlining feature for CUDA 6 – is that NVIDIA has implemented complete unified memory support within CUDA. The toolkit has possessed unified virtual addressing support since CUDA 4, allowing the disparate x86 and GPU memory pools to be addressed together in a single space. But unified virtual addressing only simplified memory management; it did not get rid of the required explicit memory copying and pinning operations necessary to bring over data to the GPU first before the GPU could work on it.

With CUDA 6 NVIDIA has finally taken the next step towards removing those memory copies entirely, by making it possible to abstract the memory management away from the programmer. This is achieved through the CUDA 6 unified memory implementation, which implements a unified memory system on top of the existing memory pool structure. With unified memory, programmers can access any resource or address within the legal address space, regardless of which pool the address actually resides in, and operate on its contents without first explicitly copying the memory over.

Now to be clear here, CUDA 6’s unified memory system doesn’t resolve the technical limitations that require memory copies – specifically, the limited bandwidth and latency of PCIe – rather it’s a change in who’s doing the memory management. Data still needs to be copied to the GPU to be operated upon, but whereas CUDA 5 required explicit memory operations (higher level toolkits built on top of CUDA withstanding) CUDA 6 offers the ability to have CUDA do it instead, freeing the programmer from the task.

Quelle: http://www.anandtech.com/show/7515/nvidia-announces-cuda-6-unified-memory-for-cuda
auch insgesamt sehr lesenswert...

[Skysnake]

Ja, jetzt aber nicht wirklich ne große Neuerung. Das ist halt eine Abstraktionsschicht dazu.

[Kriton]

Klingt für mich als wenn NVidia einfach ihr eigenes Ding gegen hUMA setzen will.

[gnahr]

naja, etwas huma-ähnliches haben sie ja schon vor huma eingeführt.
von daher ist diese "konter"-idee etwas dahergeholt. die konzepte sind viel älter als sie jetzt in der pr aufgekocht werden.

[Hübie]

Allerdings. Obwohl ich den Sinn mit der aktuellen Lage nicht ganz kapiere. Einmal hast du den schnellen GDDR5 RAM und dann halt den vergleichsweise langsamen DDR3. Wo jetzt welche Operation landet "entscheidet" künftig also der Compiler? Oder steckt mehr dahinter? Bitte mal etwas für die dummen (mich) ausführen :)
Gipsel? Skysnake? Anyone else? :naughty:

[Skysnake]

Klingt für mich als wenn NVidia einfach ihr eigenes Ding gegen hUMA setzen will.
Nicht so 100%.

hUMA funktioniert ja so richtig gut nur mit einem gemeinsamen Speicher, und den hat man bei ner dGPU halt nicht.

Was nVidia halt macht ist nen pagefault automatisch zu handeln. Mehr ist das eigentlich nicht.

Seitenfehler->GPU holt sich die entsprechende Adresse aus dem CPU Speicher und schreibt die Daten in den GPU-Speicher->GPU arbeitet weiter

Das ist eigentlich möglich seit dem die GPUs nicht mehr auf 32 Bit oder gar weniger beschränkt sind. Aktuelle GPUs können aber alle mit 64 Bit Adressen umgehen, die Frage ist nur wie breit die physikalischen Adressen sind. Sollte aber auch breit genug sein wegen z.B. GPU-Direct2 bei nVidia. Und auch ansonsten bei AMD und nVidia wegen den GPU mit großen Speicher und bei AMD auch wegen hUMA.

Die Frage ist da eher, wie viel ist davon Software, und wieviel davon wird wirklich in HArdware gemacht.

Wie schon gesagt, wenn ich mir anschaue, was die Hardware eigentlich alles schön eh können muss, dann ist das sehr sehr sehr wahrscheinlich einfach nur noch Software dazu. Es muss sich auch erst noch zeigen, wie performant das ganze dann am Ende ist mit dGPUs.

PS:
Schaut euch einfach mal GPU-Direct2 an. So nen großer Unterschied ist da eigentlich nicht mehr da.

EDIT:
@Hübie:
Es wird ziemlich sicher darauf hinaus laufen, das man eben manche Sachen nicht mehr von Hand machen muss, sondern CUDA sich darum kümmert. Wie gesagt. Am Ende läuft es ja auf die Behandlung eines Seitenfehlers drauf raus und das wars dann.

Was man halt machen muss ist, wenn man es einfahc haben will ;) PCI-E im 64 Bit Modus laufen zu lassen. Die bars sind dann so groß, das man ein 1:1 Mapping machen kann. Das ist echt verdammt simpel dann. Und ich sprech da aus eigener Erfahrung ;)

Mit 32 Bit wirds dann natürlich eklig, wenn man anfangen muss die Fenster hin und her zu schieben, wobei man auch da dann halt "einfach" sagen kann, adss das nicht geht und man nicht den kompletten Speicher nutzen kann. Als Hersteller der Hardware hat man da ja VIELE Freiheiten. :rolleyes:

[Nakai]

Die Frage ist da eher, wie viel ist davon Software, und wieviel davon wird wirklich in HArdware gemacht.


Naja schlecht ist es nicht, solange etwas vom Synchronisationsoverhead weggeht. Eine richtige Lösung gibt es eh erst mit einem gemeinsamen Speicher aka hUMA/HSA. Ich bin dennoch auf Maxwell und ihrer Implementierung einer ARM-CPU auf NV-GPU gespannt. Falls der/die ARM-Kern/e genug Leistung haben, könnten deutlich mehr Teile des Codes komplett auf der CPU laufen, vorausgesetzt es wird auch so implementiert(ein globaler Automatismus kann ich mir jetzt nicht vorstellen).

[Skysnake]

Naja, es spart dir nur halt keinen Synchoverhead an sich. Ob du es jetzt von Hand machst, oder automatisch spielt nicht wirklich DIE Rolle. Man konnte ja schon vorher auch auf Speicher zugreifen der im CPU-RAM lag.

Jetzt wird es halt einfacher, man sollte aber nicht erwarten, das man für die "Einfachheit" nicht mit etwas Performance büßen muss, auch wenn ich nicht von viel ausgehe in den meisten Fällen.

[Timbaloo]

Für einen Maxwell in 28nm ist es aber verdammt still.

[Ailuros]

Für einen Maxwell in 28nm ist es aber verdammt still.


*Laguna Laguna Laguna Laguna Laguna.....*

[boxleitnerb]

Was hat GK20A aus dem Tegra 4 mit Maxwell zu tun?

[Ailuros]

Was hat GK20A aus dem Tegra 4 mit Maxwell zu tun?

Μit Tegra4 hat Laguna/GK20A/Logan sowieso nichts gemeinsam, aber NV moebelt momentan fieberhaft am Shield2-waynescherts rum.

[boxleitnerb]

Achso das meinst du. Vielleicht hält man auch einfach besser dicht diesmal. Wenn Samples schon seit einem halben Jahr unterwegs sind, ist ja da durchaus was im Gange, wir kriegen es nur nicht öffentlich mit.

[Ailuros]

Achso das meinst du. Vielleicht hält man auch einfach besser dicht diesmal. Wenn Samples schon seit einem halben Jahr unterwegs sind, ist ja da durchaus was im Gange, wir kriegen es nur nicht öffentlich mit.

"samples" von was genau und ja es ist eine ehrliche Frage. Klar duerften irgendwelche low end Maxwell samples schon seit geraumer Zeit herumschwirren aber das hat mit dem performance chip auf den wir meistens zielen bei solchen Debatten wohl wenig zu tun.

Sonst gilt eigentlich das was immer fuer solche Faelle gilt: kein IHV sitzt und bruetet auf einem fertigen design. Natuerlich gibt es Ausnahmen wo es sich um klare Geschaefts-entscheidungen handelt aber in solchen Faellen hat man im schlimmsten Fall eine Verspaetung von ein paar Wochen.

Ich lass mich zwar gerne ueberraschen aber nach einem Q1 release riecht das Ganze nicht mehr.

[Nightspider]

Bei dem neuen unified memory benötigt man aber weiterhin doppelten VRAM für SLI, richtig?

[Ailuros]

http://semiaccurate.com/2013/12/02/nvidia-exits-another-major-market-segment/

Hab keinen Bock dafuer einen neuen thread aufzumachen; ich hab nicht die geringste Ahnung was er meinen koennte, aber es wuerde mich kein bisschen ueberraschen wenn es Denver betreffen wuerde.

[Blediator16]

Oder sie machen sich keine Mühe mehr für low end mobile GPUs.

[Burgard]

Oder sie machen sich keine Mühe mehr für low end mobile GPUs.
Warum auch, dazu sind die SOCs doch biel zu stark geworden und werden immer stärker.
Der Lowend-Markt stirbt eh aus.

[fondness]

NV braucht das low-end GPUs mehr den je gerade wegen der SoCs. In Tegra 5 steckt ein "Kepler".

[Skysnake]

http://semiaccurate.com/2013/12/02/nvidia-exits-another-major-market-segment/

Hab keinen Bock dafuer einen neuen thread aufzumachen; ich hab nicht die geringste Ahnung was er meinen koennte, aber es wuerde mich kein bisschen ueberraschen wenn es Denver betreffen wuerde.
Ja hab ich auch schon gelesen, und mich gefragt, was er da ausbrütet, aber den Wurf hierher mal unterlassen. Oft genug kommt da ja nur gehate, vor allem wenns sowas von Charlie kommt... Das kann man sich dann auch gleich ersparen.

Die Idee mit Denver hatte ich btw auch schon. Von Denver hat man schon ewig nichts mehr gehört und an sich ist das Konzept inzwischen auch mehr als tot... Wer holt sich denn bitte freiwillig ARM, wenn er von Intel praktisch das Gleiche fix und fertig mit x86 bekommen kann. MIC hat hier Denver einfach überholt, und auf der anderen Seite beist sich Denver halt auch mit dem IBM/Power deal....

Ich halte Denver also am wahrscheinlichsten. Eventuell ist die Idee mit Low-End oder gar Mobile-GPUs aber auch gar nicht schlecht. Apple holt sich in die Laptops wohl keine dedizierte GPU mehr in Zukunft, und auch sonst wird es da immer enger.

[Timbaloo]

Also "market segment" hört sich für mich eher weniger nach Denver an.

[Ailuros]

Also "market segment" hört sich für mich eher weniger nach Denver an.

Viele deuten auf "mobile" und es ist offensichtlich nicht Tegra gemeint. Low end notebooks z.B. koennte man durchaus mit einen SoC mit Denver bedienen.

Sonst kann ich mir wirklich schwer vorstellen welches Markt-Segment sie hypothetisch aufgeben wuerden.

[Timbaloo]

Low end notebooks z.B. koennte man durchaus mit einen SoC mit Denver bedienen.
Stimmt, den hatte ich nicht auf dem Schirm.

[Undertaker]

Warum auch, dazu sind die SOCs doch biel zu stark geworden und werden immer stärker.
Der Lowend-Markt stirbt eh aus.

Eine echte Low-End-GPU hat Nvidia schon in der aktuellen Generation nicht mehr. Der kleinste Chip, GK208, ist als GT 740M einzig der Iris Pro 5200 unterlegen, die wiederum nur in homöopathischen Dosen verbaut wird. Und genau dieser GK208 bzw. auch der GK107 sind im Notebooksektor mehr oder weniger das Hauptgeschäft und werden ganz sicher nicht eingestampft.

[Ailuros]

Stimmt, den hatte ich nicht auf dem Schirm.

Denver war auch indirekt gemeint; ich koennte mir schon vorstellen dass sie die Dinger immer noch fuer high end GPUs gebrauchen koennten.

Es gab aber wenn ich mich nicht irre einige newsblurbs in der Presse die auch die Moeglichkeit erwaehnten Denver cores in SoCs fuer low end PC/notebooks zu benutzen. Ein "Markt-Segment" waere es dann schon.

Die eher radikale These dass Tegra damit gemeint ist lehne ich momentan ab, obwohl wenn man NV's marketing Gefusel richtig interepretiert ist Tegra bei meiner These oben auch direkt betroffen.

[Timbaloo]

Denver war auch indirekt gemeint; ich koennte mir schon vorstellen dass sie die Dinger immer noch fuer high end GPUs gebrauchen koennten.
Nachdem man kürzlich getönt hatte man würde mit der Denver-Integration mehr gewinnen als AMD mit Mantle (ob das bzw. der Vergleich Sinn macht sei mal dahingestellt) würde mich schwer wundern wenn Denver nicht für High(er)-End GPUs kommt.

[Ailuros]

Nachdem man kürzlich getönt hatte man würde mit der Denver-Integration mehr gewinnen als AMD mit Mantle (ob das bzw. der Vergleich Sinn macht sei mal dahingestellt) würde mich schwer wundern wenn Denver nicht für High(er)-End GPUs kommt.

Interessant. Hast Du vielleicht einen link?

[Skysnake]

Eine echte Low-End-GPU hat Nvidia schon in der aktuellen Generation nicht mehr. Der kleinste Chip, GK208, ist als GT 740M einzig der Iris Pro 5200 unterlegen, die wiederum nur in homöopathischen Dosen verbaut wird. Und genau dieser GK208 bzw. auch der GK107 sind im Notebooksektor mehr oder weniger das Hauptgeschäft und werden ganz sicher nicht eingestampft.
Also ich seh GK208 schon ohne Zukunft. Derart "kleine" Chips haben einfach keine Zukunft.

Denver war auch indirekt gemeint; ich koennte mir schon vorstellen dass sie die Dinger immer noch fuer high end GPUs gebrauchen koennten.

Es gab aber wenn ich mich nicht irre einige newsblurbs in der Presse die auch die Moeglichkeit erwaehnten Denver cores in SoCs fuer low end PC/notebooks zu benutzen. Ein "Markt-Segment" waere es dann schon.

Die eher radikale These dass Tegra damit gemeint ist lehne ich momentan ab, obwohl wenn man NV's marketing Gefusel richtig interepretiert ist Tegra bei meiner These oben auch direkt betroffen.
Also Tegra an sich kann ich mir nicht vorstellen, dass die das beenden, aber ich habe auch nie gedacht, dass die IPs verkaufen.

Wer weiß, am Ende steigt nVidia tatsächlich aus dem Tegra Geschäft an sich aus, und will "nur" noch IPs verkaufen :freak: So wirklich vorstellen kann ich es mir aber ehrlich gesagt nicht, auf der anderen Seite aber auch nicht kategorisch ausschließen. nVidia hatte diesbezüglich einfach zu viele Überraschungen in letzter Zeit.

[Timbaloo]

Interessant. Hast Du vielleicht einen link?
Hmmm, "getönt" ist dann vielleicht doch ein wenig ermmm.... *rausred* übertrieben, ich habe gefunden wo ich das gelesen habe:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9946140&postcount=557

:freak:

"then 64 bit arm cores developed by nv gets integrated on the same die. they can coherently access the common l3 cache. the big thing is that they will be used by the graphics driver to offload some heavy lifting from the system cpu. basically most part of the driver will be running on the gpu itself! nvidia expects this will give them at least the same speed up as amd will get from mantle, but without using a new api with straight dx11 or opengl code!"

Sorry, hat sich bei mir im Hirn irgendwann zu einer Aussage von NV gewandelt :biggrin:

[Hübie]

Denver ist ja ein zweischneidiges Schwert: Einmal als integration in eine GPU geplant und einmal als standalone SoC (mit nVidia GPU) für ultra mobile. Ich vermute ersteres wird ersatzlos gestrichen, da eine integration in eine (highend-) GPU nicht mehr viel Sinn ergeben würde.
Intel hat mit KC und KL nun einen fetten Einstand bzgl. x86-basierte HPC-Aufgaben während man selber mit Quadro und Tesla breit aufgestellt ist.
Ich habe vor nicht allzu langer Zeit erfahren dass nVidia künftig HPC, Desktop und Mobile mit ihren Produkten stärker trennen möchte, während die Architekturen immer näher zusammenrücken.
Das würde bedeuten dass wir momentan z.B. keine GeForce zur Quadro umflashen oder gar Tesla umlöten könnten und in Smartphones ein SoC mit Kepler-CUDA-Cores sitzen würde.

Ergibt auch irgendwie Sinn wenn man so drüber nachgrübelt.

[Ailuros]

Sorry, hat sich bei mir im Hirn irgendwann zu einer Aussage von NV gewandelt :biggrin:

Εrrrrr nein natuerlich LOL :P

Denver ist ja ein zweischneidiges Schwert: Einmal als integration in eine GPU geplant und einmal als standalone SoC (mit nVidia GPU) für ultra mobile. Ich vermute ersteres wird ersatzlos gestrichen, da eine integration in eine (highend-) GPU nicht mehr viel Sinn ergeben würde.
Intel hat mit KC und KL nun einen fetten Einstand bzgl. x86-basierte HPC-Aufgaben während man selber mit Quadro und Tesla breit aufgestellt ist.
Ich habe vor nicht allzu langer Zeit erfahren dass nVidia künftig HPC, Desktop und Mobile mit ihren Produkten stärker trennen möchte, während die Architekturen immer näher zusammenrücken.
Das würde bedeuten dass wir momentan z.B. keine GeForce zur Quadro umflashen oder gar Tesla umlöten könnten und in Smartphones ein SoC mit Kepler-CUDA-Cores sitzen würde.

Ergibt auch irgendwie Sinn wenn man so drüber nachgrübelt.

Erstes ist aber kein ("major") Markt-Segment :rolleyes:

[Undertaker]

Also ich seh GK208 schon ohne Zukunft. Derart "kleine" Chips haben einfach keine Zukunft.

Von der absoluten Leistung ja, von der Marktpositionierung sitzt GK208 aber genau über der derzeit verbreitetsten Onboard-Lösung HD 4400/HD 4600. Packt Broadwell bei dieser Mittelklasse-IGP z.B. 50% dazu und der GK208-Nachfolger ebenfalls, bleibt die Situation genau so bestehen und der Chip behält seine Daseinsberechtigung.

[Hübie]

Erstes ist aber kein ("major") Markt-Segment :rolleyes:

Auch wieder wahr. Also weiter rätseln. Hat wer bezahlt? Ich hasse paywall :freak:

[Ailuros]

Auch wieder wahr. Also weiter rätseln. Hat wer bezahlt? Ich hasse paywall :freak:

Wer wird wohl bei SA so leicht fuer die paywall bezahlen?

[Hübie]

Du? :freak: Duck und weg.

Wär ich Anleger würds Sinn machen. Aber so... pff

[Skysnake]

Denver ist ja ein zweischneidiges Schwert: Einmal als integration in eine GPU geplant und einmal als standalone SoC (mit nVidia GPU) für ultra mobile. Ich vermute ersteres wird ersatzlos gestrichen, da eine integration in eine (highend-) GPU nicht mehr viel Sinn ergeben würde.

Seit wann ist Denver ultra mobile :ugly:

Project Denver ziehlt auf alles aber, aber NICHT ultra Mobile....


Intel hat mit KC und KL nun einen fetten Einstand bzgl. x86-basierte HPC-Aufgaben während man selber mit Quadro und Tesla breit aufgestellt ist.
Ich habe vor nicht allzu langer Zeit erfahren dass nVidia künftig HPC, Desktop und Mobile mit ihren Produkten stärker trennen möchte, während die Architekturen immer näher zusammenrücken.

Von wem haste denn so einen Schwachsinn erfahren? nVidia kann sich das gar nicht leisten nur für den Servermarkt einen eigenen Chip zu entwickeln. Wenn bringen Sie für IBM ne IP, aber das wars dann auch. Das sind keine eigens entwickelten Chips nur dafür.


Das würde bedeuten dass wir momentan z.B. keine GeForce zur Quadro umflashen oder gar Tesla umlöten könnten und in Smartphones ein SoC mit Kepler-CUDA-Cores sitzen würde.

Ergibt auch irgendwie Sinn wenn man so drüber nachgrübelt.
Nicht wirklich :tongue:

Von der absoluten Leistung ja, von der Marktpositionierung sitzt GK208 aber genau über der derzeit verbreitetsten Onboard-Lösung HD 4400/HD 4600. Packt Broadwell bei dieser Mittelklasse-IGP z.B. 50% dazu und der GK208-Nachfolger ebenfalls, bleibt die Situation genau so bestehen und der Chip behält seine Daseinsberechtigung.
Ja, aber jetzt auch nicht wirklich fett, und Sie wird eben von der schnellsten iGPU geschluckt. Das Segment ist also tot, da die dGPU nur normal skalieren kann, da man ansonsten die Karten drüber zu stark bedrängen würde, die iGPUs entwickeln sich aber eben deutlich schneller als die dGPUs.

Somit fällt der Teil halt doch trotzdem weg in den nächsten 1-2 Jahren.

[Hübie]

Parker ist ein Denver basierter Tegra SoC und somit für ultra mobile. :rolleyes: Und ich sagte nicht dass es nur Chips für HPC geben wird, sondern dass man sich stärker abgrenzt. Wohl eher aufs PCB bezogen... Und wenn du es als Schwachsinn siehst bitte sehr. Wir reden 2015 noch mal über die Strategie.

[Skysnake]

Nen HPC/Desktop System willst und kannst du nicht in den Ultra-Mobile Markt drücken.

SOC ist nicht gleich SOC, genau wie die "Kepler" GPU bei Tegra 5 nicht identisch zu den Desktop/Mobile Keplers sein wird.

[Hübie]

Hä? Okay lassen wir das :rolleyes:

Edit: Nicht weil ich dich für zu blöde halte sondern weil es zuviel Text wäre und ich pennen muss.

[Undertaker]

Ja, aber jetzt auch nicht wirklich fett, und Sie wird eben von der schnellsten iGPU geschluckt. Das Segment ist also tot, da die dGPU nur normal skalieren kann, da man ansonsten die Karten drüber zu stark bedrängen würde, die iGPUs entwickeln sich aber eben deutlich schneller als die dGPUs.

Somit fällt der Teil halt doch trotzdem weg in den nächsten 1-2 Jahren.

Da die schnellste iGPU bei Intel derzeit nicht in der Breite verbaut wird, gilt das eben nicht. Und ob Intel wirklich auch bei kleineren Modellen in einen EDRAM investieren will? Ohne den verhungert jegliche Mehrleistung nahezu komplett, wie man sehr schön an der HD 5000 oder Iris 5100 sieht. Zumindest bis DDR4 kommt, ist das Thema Bandbreite ein ziemliches Problem für jede integrierte Lösung (ohne EDRAM).

[boxleitnerb]

Dazu muss man auch sagen, dass die Entwicklung bei den dGPUs ja nicht stehen bleibt. 20nm, neue Architekturen...man wird IMMER einen gewissen Abstand einhalten können zu den iGPUs, solange die nicht in ähnliche TDP und Transistor-Budget-Sphären vorstoßen (dürfen).

[Dawn on Titan]

Tegra ist imho wahrscheinlich. Man geht wahrscheinlich auf einen reinen IP Verkauf.

[AffenJack]

Tegra fallen zu lassen macht im Moment gar keinen Sinn und IP Verkauf bringt viel zu wenig ein, da kann mans auch ganz lassen. Man hat gerade erst angefangen sich endlich ernsthaft um den Markt zu bemühen, da lässt man es doch nicht sofort. Shield, eigene Referenzdesign. Da hängt soviel dran, was man fallen lassen würde. Nee, glaub ich nicht.
Low End Laptop ist das wahrscheinlichste, weil der Markt sowieso gerade stirbt.

[Hübie]

Nen HPC/Desktop System willst und kannst du nicht in den Ultra-Mobile Markt drücken.

SOC ist nicht gleich SOC, genau wie die "Kepler" GPU bei Tegra 5 nicht identisch zu den Desktop/Mobile Keplers sein wird.

So jetzt noch mal aufgegriffen:
Momentan ists ja so, dass Tegra4 der erste SoC mit eine unified shader architecture ist die einen Effizienzgrad aufweist wie man sie halt von den Desktop-Kepler kennt. Das die nicht identisch sein können sollte bei dem Transistorbudget bzw. der die-area und TDP-Grenze irgendwie klar sein. Was willst du z.B. mit den 8 64fp-units vom GK104 SMx in einem SoC? Kepler ist aber schon "alt" und kommt jetzt erst im ultra-mobile Segment. Tegra4 wird aber wohl eh keine große Verbreitung finden. Phoenix ist ja irgendwie tot und shield ist halt was für Desktop-User, aber wird sicher kein smartphone / tablet Ersatz. Mal sehen was dann mit Logan kommt und wie sinnvoll das wird.
So und Denver ist ein Projekt was erst mal alles umfasst. Die konstante ist halt Arm(v8?)<->x86, welche meiner Meinung nach in einem Smartphone wenig Sinn ergeben würde, da der Markt sehr weit aufgestellt ist. Es gibt alles für Arm was man benötigt (oder?;)) was die Übersetzung von x86 obsolet machen würde.
Im HPC-Markt sehe ich das anders, da man hier Intel (zumindest auf dem Papier) angreifen könnte und dort Teile des Kuchens abzwacken kann. Immerhin ist der Code ja dann schon für massive Parallelisierung optimiert (KC / KL).
Auf dem Desktop könnte ein nativer Arm-Core in einer GPU viele Aufgaben erledigen. Ob man da jetzt irgendwie von x86 zu Arm "konvertieren" muss weiß ich nicht, dazu fehlt mir einfach das Fachwissen wie man sowas mit dem Treiber "vereinbaren" kann oder was da alles in Hardware gegossen sein müsste.

So, ich muss aufhören...

[robbitop]

Tegra 4 ULP ist kein USC.

[Hübie]

Was ist denn jetzt wieder USC?

[robbitop]

Unified shader core. Erst Tegra 5 hat einen.

[Skysnake]

/sign Tegra 4 hat noch keine unified shader, sondern vertex usw shader.

Ansonsten kann ich deine Aussagen auch überhaupt nicht nachvollziehen Hübie.

X86 ersetzt man oft nicht mal eben so. Das liegt daran, das man doch einiges an Bibs verwendet. Die müssen also erstmal vorhanden sein. Dazu kommt dann noch, dass du ARM-Treiber für den Interconnect brauchst, und zwar solche die auch performant sind. Mit Ethernet kommste da nicht weit.

Das hört sich jetzt nicht nach viel an, ist aber doch nochmal deutlich mehr als mit ner dGPU in nem x86 System, und schon die bekommen ja immer mehr Probleme die Leute davon zu überzeugen eingesetzt zu werden anstatt MIC.

Mit ARM+GPU hast du alle Nachteile auf einmal. Wenn muss sowas wie HSA kommen, damit man sich um den GPU Part nicht mehr in dem Umfang kümmern muss. Aber auch da bleibt eben das ARM Problem bestehen.

Und nur mal so als Randnotiz. Mellanox arbeitet mit nVidia sehr sehr eng zusammen. Dennoch ist das alles noch in der Mache, wo Intel halt schon ein fertiges Eco-System dastehen hat, und dann 2015 auch standalone wird. nVidia ist da einfach zu spät dran.

http://ir.mellanox.com/releasedetail.cfm?ReleaseID=771771
https://www.isc-events.com/ir/files/pressbox/2013/10/61/Press%20Release%20on%20PRACEpedraforca_v6.pdf
http://www.itproportal.com/2013/06/17/mellanox-showcases-first-infiniband-connection-nvidia-tegra-arm-processors/

Mellanox ist ein wichtiger player, aber mit denen allein wird man auch nicht durchkommen. So ne Treiberportierung ist aber nicht mal eben gemacht...

[Coda]

Was soll bitte an "ARM"-Treibern ein Problem sein? Im HPC-Bereich benutzt man Linux und da läuft jeder Treiber normalerweise auf allen Platformen.

[Hübie]

Wir sind uns doch einig, dass Denver eine ARM-CPU ist welche in x86 übersetzen kann oder? Das ergibt halt nicht in allen Segmenten Sinn. Das ist der Kern meiner oben ausgeführten Aussage. Was gibt es da nicht nachzuvollziehen?

@robbitop: Danke für die Korrektur. Da lag ich wohl falsch ;) Tegra4 hat ja nun wirklich nix mit Kepler gemeinsam. Untermauert ja halt die Aussage noch mehr dass die weit auseinander driften. Wer hatte denn noch USA? Mali? :|

[AffenJack]

Wir sind uns doch einig, dass Denver eine ARM-CPU ist welche in x86 übersetzen kann oder? Das ergibt halt nicht in allen Segmenten Sinn. Das ist der Kern meiner oben ausgeführten Aussage. Was gibt es da nicht nachzuvollziehen?


Nö, sind wir uns glaube nicht. Denver ist doch einfach ein hochgezüchtetes ARMv8 Design. Den X86 Gedanken gabs doch nur zu Anfang, aber das hat sich dann als Blödsinn entpuppt bzw Nv hat gemerkt, dass es nicht zu machen ist.

[Skysnake]

Was soll bitte an "ARM"-Treibern ein Problem sein? Im HPC-Bereich benutzt man Linux und da läuft jeder Treiber normalerweise auf allen Platformen.
Weil die Treiber teilweise in Assembler geschrieben sind, um eben das kopieren von Daten usw wirklich schnell und effizient zu machen?

Das ist teilweise schon bäh, wenn du Treiber umschreiben musst, weil gewisse Sachen halt einfach nicht gehen. Das es überhaupt läuft ist weniger das Problem, wenn der Treiber gut strukturiert geschrieben ist, und eventuell sogar mit dem Hintergedanke entwickelt wurde mehrere Platformen zu unterstützen. Das haste in relativ kurzer Zeit durch, aber dass das ganze dann auch wieder performant ist, ist was ganz anderes...

Natürlich sind das keine unlösbaren Probleme, aber es muss sich halt jemand hinsetzen, und das wirklich machen, und du weißt ja das Entwickler auf dem lvl nicht gerade billig sind. Vor allem muss das Zeug ja auch bis zum erbrechen getestet werden. Was glaubste, was passieren würde, wenn alle 48h mal es zu nem Datenverlust kommt, weil die Daten nicht richtig kopiert werden, weil man irgend einen Cornercase übersehen hat, weil man eben manche Sachen umschreiben musste.

Ich kann jetzt halt nur direkt von meiner Erfahrung aus der Portierung eines Treibers von x86 auf MIC sprechen. Allein das man "xfence" und SSE nicht unterstützt hat einiges an Arbeit gemacht, obwohl es auch x86 ist.

Mit ARM läufste da in ähnliche Probleme rein. Die Tücke steckt da echt im Detail...

[Hübie]

Nö, sind wir uns glaube nicht. Denver ist doch einfach ein hochgezüchtetes ARMv8 Design. Den X86 Gedanken gabs doch nur zu Anfang, aber das hat sich dann als Blödsinn entpuppt bzw Nv hat gemerkt, dass es nicht zu machen ist.

Ach echt? Das is wohl an mir vorbei gezogen. Wenn das so ist verstehe ich weshalb skysnake mich nicht versteht :freak:
Dann vote ich auch für lowend mobile GPUs.

[Dural]

irgend wie hab ich das gefühl das ihr hier um nichts diskutiert, zudem hat ja bis heute offensichtlich den ganzen artikel noch keiner ganz gelesen?!

zudem reitet charlie seit jahren immer noch auf dem chipsatz geschäft von NV rum, das war für NV umsatz mässig nie von belangen, das geld wurde immer mit igpus oder dgpus gemacht. es nerft langsam.


und überhaupt, was hat das mit maxwell zutun?

[Hübie]

Ja hast ja recht :P
Der Artikel ist hinter einer paywall und wir sind nicht gewillt da unser Geld zu verbrennen. Also raten wir munter drauf los.

[Coda]

Weil die Treiber teilweise in Assembler geschrieben sind, um eben das kopieren von Daten usw wirklich schnell und effizient zu machen?
BULLSHIT! Die Linux-Treiber sind alle reines C, falls überhaupt was Assembler ist wird es wegabstrahiert.

Hör damit auf FUD zu verbreiten.

[del_4901]

BULLSHIT! Die Linux-Treiber sind alle reines C, falls überhaupt was Assembler ist wird es wegabstrahiert.

Hör damit auf FUD zu verbreiten.
ASM ist sicherlich nicht der springende Punkt. Aber jede Platform hat ihre Eigenheiten, wenn es um Device Initialisierung geht.

[Skysnake]

Ach echt? Das is wohl an mir vorbei gezogen. Wenn das so ist verstehe ich weshalb skysnake mich nicht versteht :freak:
Dann vote ich auch für lowend mobile GPUs.
Dann ist ja gut :tongue:

Jetzt versteh ich auch, warum du mich nicht verstanden hast ;D

BULLSHIT! Die Linux-Treiber sind alle reines C, falls überhaupt was Assembler ist wird es wegabstrahiert.

Hör damit auf FUD zu verbreiten.
Coda, das "BILLSHIT" kannste dir ans Rever tackern. Wer schreibt an dem Treibercode? Du oder ich?

Meinste nicht, dass das geringfügig anmasend ist, über Code urteilen zu wollen, an dem ich arbeite?

ASM ist sicherlich nicht der springende Punkt. Aber jede Platform hat ihre Eigenheiten, wenn es um Device Initialisierung geht.
Jaein. Teilweise ist es halt doch ein Problem, das einem Kopfschmerzen macht. Wenn einem ein Befehl nicht zur Verfügung steht, muss man schauen, welche Auswirkungen das hat, ob es dadurch irgendwelche Cornercases gibt, an denen was schief laufen kann und ob man nicht andere Treiberteile umschreiben muss, weil eben eine Idee so nicht mehr funktioniert. Das zieht nen riesen Rattenschwanz hinter sich her, und teils sitzt man Wochen dran, bis man ein Problem erkennt und lösen kann. Wenn alle paar Stunden, unter Volllast nur ein Fehler auftritt, dann lässt sich das halt verdammt schlecht debuggen....

Ich hab z.B. vor paar Wochen ein Problem gelöst, welches, wie sich herausgestellt hat auch ein anderes Problem gelöst hat, welches ich schon 6-9 Monate mit rum geschleppt hatte, und mit dirty hacks gefixed hatte, weil ich die Ursache nicht fand...

Und an solchen Problemen sitzte halt an sich beliebig lange, wenn du nicht die zündende Idee hast.

[del_4901]

Jaein. Teilweise ist es halt doch ein Problem, das einem Kopfschmerzen macht. Wenn einem ein Befehl nicht zur Verfügung steht, muss man schauen, welche Auswirkungen das hat, ob es dadurch irgendwelche Cornercases gibt, an denen was schief laufen kann und ob man nicht andere Treiberteile umschreiben muss, weil eben eine Idee so nicht mehr funktioniert. Das zieht nen riesen Rattenschwanz hinter sich her, und teils sitzt man Wochen dran, bis man ein Problem erkennt und lösen kann. Wenn alle paar Stunden, unter Volllast nur ein Fehler auftritt, dann lässt sich das halt verdammt schlecht debuggen....

Ich hab z.B. vor paar Wochen ein Problem gelöst, welches, wie sich herausgestellt hat auch ein anderes Problem gelöst hat, welches ich schon 6-9 Monate mit rum geschleppt hatte, und mit dirty hacks gefixed hatte, weil ich die Ursache nicht fand...

Und an solchen Problemen sitzte halt an sich beliebig lange, wenn du nicht die zündende Idee hast.Sorry wenn ich da etwas direkt bin: Aber das sind alles Probleme mangels Erfahrung an guten Herangehensweisen.

[Skysnake]

Das stimmt in dem Fall sogar, aber anders als du es wohl meinst ;)

Wenn einfach noch niemand so was gemacht hat, gibts halt auch noch keine Erfahrungen bzgl Herangehensweise.

[del_4901]

Wenn einfach noch niemand so was gemacht hat, gibts halt auch noch keine Erfahrungen bzgl Herangehensweise.
Ich spreche von generellen Herrangehensweisen, das ist nichts was man aktiv lernen kann, das kommt einfach mit der Zeit.

[Skysnake]

Klar, Valgrind, gdb, entsprechende Dokus und Testmethodiken muss man kennen und auch in der Handhabung erlernen. Wenns die Dinger aber nicht gibt, haste halt Pech gehabt und es wird spannend ;D

Aber ja, das "Gespür" ist sicherlich am meisten wert, und am schwierigsten zu erlangen. Das geht nur über Erfahrung, da kann man noch so viel lernen und lesen wie man will. Wenn man nicht die richtige Idee hat, steht man wie der Ochs vorm Berg und kommt keinen Millimeter weiter, und muss halt bischen Pinata spielen. Das macht doch aber auch gerade erst den Spaß an der ganzen Sache aus, oder nicht? :biggrin:

Wenn man immer sofort wüsste was das Problem ist, bzw was die Lösung, wäre es doch stinke langweilig.

[Ailuros]

irgend wie hab ich das gefühl das ihr hier um nichts diskutiert, zudem hat ja bis heute offensichtlich den ganzen artikel noch keiner ganz gelesen?!

zudem reitet charlie seit jahren immer noch auf dem chipsatz geschäft von NV rum, das war für NV umsatz mässig nie von belangen, das geld wurde immer mit igpus oder dgpus gemacht. es nerft langsam.


und überhaupt, was hat das mit maxwell zutun?

Es koennte alles oder gar nichts mit Maxwell zu tun haben und wie ich schon sagte mach ich dafuer einen neuen thread auf. Aber wenn Du eine direktere Relevanz zu Maxwell haben willst, behaupte ich jetzt mal aus dem blauen dass das letzte einen kleineren Leistungs-unterschied machen wird wie bei vorigen Generationen und warte dann schoen auf Dein spekulatives feedback zu diesem.

[Ailuros]

Forbes fuer NV's GPU Geschaeft:

http://www.forbes.com/sites/greatspeculations/2013/12/02/nvidias-gpu-business-outperforms-pcs-for-various-reasons/

[Coda]

Coda, das "BILLSHIT" kannste dir ans Rever tackern. Wer schreibt an dem Treibercode? Du oder ich?
Ich kenne aus diversen Gründen so gut wie alle Ecken des Linux-Source-Trees und da ist kein Assembler in den Device-Treibern.

Nur weil ihr euer eigenes Zeug so schreibt brauchst du das noch lange nicht auf die Allgemeinheit übertragen.

Und ja, ich schreibe unter anderem auch Code auf unterster HW-Ebene.

[Iruwen]

Steckt HPC Code mit im "normalen" Source Tree?

[Hübie]

Forbes fuer NV's GPU Geschaeft:

http://www.forbes.com/sites/greatspeculations/2013/12/02/nvidias-gpu-business-outperforms-pcs-for-various-reasons/

Recht einseitige Betrachtung. AMD stellt sich auch immer breiter auf und zieht mit Sonderfunktionen nach (Mantle, Eyefinity, Raptr). Im HPC breitet sich Intel weiterhin aus.
In den nächsten Jahren wird es eh immer schwieriger die Leistung kontinuierlich zu "verdoppeln" (GF110 <-> GK110 = ~ +50%). Intel selbst sagt schon voraus, dass Moore's law nicht mehr lange Gültigkeit haben wird und obendrein werden die kleineren Strukturen unverhältnismäßig teurer als z.B. noch beim Sprung von 65 auf 40 (55-nm-Prozess mal aussen vor).
Weiterhin hat man mit Kepler eine sehr schnelle Architektur die effizient zu werke geht, was Maxwell wahrscheinlich erst mal nicht so interessant werden lässt um bestehende HPC-Cluster umzurüsten.
Naturgemäß werden immer zu Wahlzeiten in den USA Gelder für R&D locker gemacht, was Maxwell noch unattraktiver machen könnte. Wieviele der aktuellen deals aber schon mit Maxwell kalkuliert wurden / werden kann natürlich keiner der hier Anwesenden sagen, aber mit ungelegten Eiern handelt man bekanntlich nicht. Ich bin mir also nicht mal sicher ob Maxwell an den Erfolg von Kepler anknüpfen kann.
Die zusätzlichen Spekulationen über das verlassen eines Marktsegments wird hier ebenfalls völlig ausser acht gelassen (hätten man wenigstens als Randnotiz nehmen können).
Also warten wir mal und mischen dann die Karten neu. Das sollte man berücksichtigen. Ich kenne mich mit Aktien zu wenig aus um der Analyse so zu zustimmen, aber finde dass deren stagnierende Prognose realistisch erscheint.

Dieses Jahr werden wir wohl eh nix mehr von Maxwell hören, denn man will ja nicht vom bevorstehenden Produkt-Release ablenken :freak:

[boxleitnerb]

Wie kommst du auf nur 50%? Die 780 Ti ist knapp doppelt so schnell wie die GTX 580 bei sogar geringfügig niedrigerer Leistungsaufnahme. Mit 20 nm ohne FinFETs könnte das aber durchaus anders aussehen.

[Skysnake]

Ich kenne aus diversen Gründen so gut wie alle Ecken des Linux-Source-Trees und da ist kein Assembler in den Device-Treibern.

Nur weil ihr euer eigenes Zeug so schreibt brauchst du das noch lange nicht auf die Allgemeinheit übertragen.

Und ja, ich schreibe unter anderem auch Code auf unterster HW-Ebene.
Komisch grep __asm liefert mir da folgendes:


./drivers/char/bfin_jtag_comm.c: __asm__ __volatile__("emudat = %0;" : : "d"(emudat));
./drivers/char/bfin_jtag_comm.c: __asm__ __volatile__("%0 = emudat;" : "=d"(emudat));
./drivers/char/scc.h: __asm__ __volatile__ ( " nop; nop"); \
./drivers/char/scc.h: __asm__ __volatile__ ( "tstb %0" : : "g" (*_scc_del) : "cc" );\
./drivers/char/vme_scc.c:#define scc_delay() do { __asm__ __volatile__ (" nop; nop"); } while (0)
./drivers/ide/ide-h8300.c: __asm__("mov.b %w1,r1h\n\t" \
./drivers/misc/vmware_balloon.c: __asm__ __volatile__ ("inl (%%dx)" : \
./drivers/net/atarilance.c: __asm__ __volatile__ ( "movec %/vbr,%0" : "=r" (vbr) : );
./drivers/net/atarilance.c: __asm__ __volatile__
./drivers/net/atp.h: __asm__ __volatile__ ("inb %w1,%b0" :"=a" (_v):"d" (port));
./drivers/net/bmac.c: __asm__ volatile( "stwbrx %0,0,%1" : : "r" (x), "r" (a) : "memory");
./drivers/net/bmac.c: __asm__ volatile ("lwbrx %0,0,%1" : "=r" (swap) : "r" (a));
./drivers/net/ioc3-eth.c: __asm__("sync" ::: "memory")
./drivers/parisc/power.c: __asm__ __volatile__ ( \
./drivers/scsi/in2000.h: __asm__ __volatile__ ("\n \
./drivers/scsi/in2000.h: __asm__ __volatile__ ("\n \
./drivers/scsi/mac_scsi.c:__asm__ __volatile__ \
./drivers/scsi/mac_scsi.c:__asm__ __volatile__ \
./drivers/scsi/ultrastor.c: __asm__ ("xchgb %0,%1" : "=q" (reg), "=m" (*mem) : "0" (reg));
./drivers/serial/bfin_sport_uart.c: __asm__ __volatile__ (
./drivers/serial/bfin_sport_uart.c: __asm__ __volatile__ (
./drivers/video/fsl-diu-fb.c: __asm__ __volatile__ (
./drivers/video/uvesafb.c: __asm__ __volatile__(
./drivers/video/uvesafb.c: __asm__ __volatile__(
./drivers/video/vesafb.c: __asm__ __volatile__(
./drivers/video/vesafb.c: __asm__ __volatile__(

./char/mwave/smapi.c: __asm__ __volatile__("movw $0x5380,%%ax\n\t"
./isdn/i4l/isdn_audio.c: __asm__ __volatile__(
./media/video/stradis.c: * writing non-portable __asm__ directives.
./mtd/maps/nettel.c: __asm__ ("wbinvd");
./mtd/maps/nettel.c: __asm__ ("wbinvd");
./mtd/maps/nettel.c: __asm__ ("wbinvd");
./net/arm/am79c961a.c: __asm__(
./net/arm/am79c961a.c: __asm__(
./net/arm/am79c961a.c: __asm__(
./net/arm/am79c961a.c: __asm__(
./net/arm/am79c961a.c: __asm__ __volatile__("str%?h %2, [%0], #4"
./net/arm/am79c961a.c: __asm__ __volatile__(
./net/arm/am79c961a.c: __asm__ __volatile__("str%?h %2, [%0], #4"
./net/arm/am79c961a.c: __asm__ __volatile__(
./net/arm/am79c961a.c: __asm__ __volatile__(
./net/arm/am79c961a.c: __asm__ __volatile__(
./net/arm/ether1.c: __asm__ __volatile__(
./net/arm/ether1.c: __asm__ __volatile__(
./net/ixp2000/caleb.c: __asm__ __volatile__("mov %0, %0" : "+r" (dummy));
./net/ixp2000/pm3386.c: __asm__ __volatile__("mov %0, %0" : "+r" (dummy));
./net/pcmcia/xirc2ps_cs.c: __asm__("rorl $16,%0\n\t"
./net/wan/sbni.c: __asm__ __volatile__ (
./pci/hotplug/cpqphp_nvram.c: __asm__ (
./pnp/pnpbios/bioscalls.c:__asm__(".text \n"
./pnp/pnpbios/bioscalls.c: __asm__ __volatile__("pushl %%ebp\n\t"
./sbus/char/jsflash.c: __asm__ __volatile__("lda [%1] %2, %0\n\t" :
./sbus/char/jsflash.c: __asm__ __volatile__("sta %0, [%1] %2\n\t" : :
./scsi/arm/arxescsi.c: __asm__ __volatile__(
./staging/echo/fir.h: __asm__("I0 = %1;\n\t"
./staging/hv/Hv.c: __asm__ __volatile__("mov %0, %%r8" : : "r" (outputAddress) : "r8");
./staging/hv/Hv.c: __asm__ __volatile__("call *%3" : "=a" (hvStatus) :
./staging/hv/Hv.c: __asm__ __volatile__ ("call *%8" : "=d"(hvStatusHi),
./staging/hv/logging.h: __asm__ __volatile__("int3"); \
./staging/wlags49_h2/hcfcfg.h:#define IN_PORT_STRING_8_16( port, addr, len) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push di \
./staging/wlags49_h2/hcfcfg.h: __asm push es \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,len \
./staging/wlags49_h2/hcfcfg.h: __asm les di,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep insw \
./staging/wlags49_h2/hcfcfg.h: __asm pop es \
./staging/wlags49_h2/hcfcfg.h: __asm pop di \
./staging/wlags49_h2/hcfcfg.h:#define OUT_PORT_STRING_8_16( port, addr, len) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push si \
./staging/wlags49_h2/hcfcfg.h: __asm push ds \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,len \
./staging/wlags49_h2/hcfcfg.h: __asm lds si,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep outsw \
./staging/wlags49_h2/hcfcfg.h: __asm pop ds \
./staging/wlags49_h2/hcfcfg.h: __asm pop si \
./staging/wlags49_h2/hcfcfg.h:#define IN_PORT_STRING_8_16( port, addr, n) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push di \
./staging/wlags49_h2/hcfcfg.h: __asm push es \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,n \
./staging/wlags49_h2/hcfcfg.h: __asm les di,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep insw \
./staging/wlags49_h2/hcfcfg.h: __asm pop es \
./staging/wlags49_h2/hcfcfg.h: __asm pop di \
./staging/wlags49_h2/hcfcfg.h:#define OUT_PORT_STRING_8_16( port, addr, n) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push si \
./staging/wlags49_h2/hcfcfg.h: __asm push ds \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,n \
./staging/wlags49_h2/hcfcfg.h: __asm lds si,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep outsw \
./staging/wlags49_h2/hcfcfg.h: __asm pop ds \
./staging/wlags49_h2/hcfcfg.h: __asm pop si \
./staging/wlags49_h2/hcfcfg.h:#define IN_PORT_STRING_16( port, addr, len) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push di \
./staging/wlags49_h2/hcfcfg.h: __asm push es \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,len \
./staging/wlags49_h2/hcfcfg.h: __asm les di,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep insw \
./staging/wlags49_h2/hcfcfg.h: __asm pop es \
./staging/wlags49_h2/hcfcfg.h: __asm pop di \
./staging/wlags49_h2/hcfcfg.h:#define OUT_PORT_STRING_16( port, addr, len) __asm \
./staging/wlags49_h2/hcfcfg.h: __asm push si \
./staging/wlags49_h2/hcfcfg.h: __asm push ds \
./staging/wlags49_h2/hcfcfg.h: __asm mov cx,len \
./staging/wlags49_h2/hcfcfg.h: __asm lds si,addr \
./staging/wlags49_h2/hcfcfg.h: __asm mov dx,port \
./staging/wlags49_h2/hcfcfg.h: __asm rep outsw \
./staging/wlags49_h2/hcfcfg.h: __asm pop ds \
./staging/wlags49_h2/hcfcfg.h: __asm pop si \
./staging/wlags49_h2/hcfcfg.h: #define __asm__ asm
./staging/wlags49_h2/hcfcfg.h: #define EIEIO() __asm__(" eieio")
./staging/wlags49_h2/hcfcfg.h: #define __asm__ asm
./staging/wlags49_h2/hcfcfg.h: #define EIEIO() __asm__(" eieio")
./staging/wlags49_h2/hcfcfg.h: #define __asm__ asm
./staging/wlags49_h2/hcfcfg.h: #define EIEIO() __asm__(" eieio")
./staging/wlags49_h2/hcfcfg.h: #define __asm__ asm
./staging/wlags49_h2/hcfcfg.h: #define __asm__ asm



Also für mich ist das inline assembler. Zwar nicht viel, aber es kann dir schon harte Kopfschmerzen bereiten, wenn man so Sachen dann umbiegen muss. Das Zeug fügt man ja nicht aus Jux und Dollerei ein.

[Coda]

Du hast von "Interconnect" geredet. Ich seh da nix von. Aber du hast recht und ich meine Ruhe.

Mal ganz abgesehen davon, dass das Zeug in den Fällen immer auch einen allgemeinen C-Pfad hat.

[Coda]

Steckt HPC Code mit im "normalen" Source Tree?
Zumindest Infiniband. Cray mag propritären Code haben.

Es ging mir darum, dass Treiber in aller Regel architekturspezifischen Code enthalten würden. Dem ist nicht so.

[Skysnake]

Also keine Ahnung, wie es jetzt genau aussieht bei Mellanox usw. bzgl offenen Treibern, aber der Treiber, den man einfach bei denen so runterladen kann (http://www.mellanox.com/page/products_dyn?product_family=27), verwendet nicht mal nen volatile oder sonst wie sse oder sonst was. Das glaub ich jetzt eher weniger, dass die davon rein gar nichts nutzen. Damit würde man unnötig Performance liegen lassen.

Und ansonstne CODA, gerade bei nem Infiniband/HPC Interconnect ist Latenz sehr wichtig. Deswegen will man ja so Sachen wie SSE benutzen, damit man eventuell Datenpackete direkt in einem Rutsch verarbeiten kann. Bei nem schnöden Ethernettreiber wirste sowas natürlich nie finden. Das Zeug ist eh schnarch langsam, da kommts darauf eh nicht mehr an.

[Hübie]

Wie kommst du auf nur 50%? Die 780 Ti ist knapp doppelt so schnell wie die GTX 580 bei sogar geringfügig niedrigerer Leistungsaufnahme. Mit 20 nm ohne FinFETs könnte das aber durchaus anders aussehen.

Ähm ich hätte ~ -50% schreiben sollen :biggrin:

[Coda]

Also keine Ahnung, wie es jetzt genau aussieht bei Mellanox usw. bzgl offenen Treibern, aber der Treiber, den man einfach bei denen so runterladen kann (http://www.mellanox.com/page/products_dyn?product_family=27), verwendet nicht mal nen volatile oder sonst wie sse oder sonst was. Das glaub ich jetzt eher weniger, dass die davon rein gar nichts nutzen. Damit würde man unnötig Performance liegen lassen.

Und ansonstne CODA, gerade bei nem Infiniband/HPC Interconnect ist Latenz sehr wichtig. Deswegen will man ja so Sachen wie SSE benutzen, damit man eventuell Datenpackete direkt in einem Rutsch verarbeiten kann. Bei nem schnöden Ethernettreiber wirste sowas natürlich nie finden. Das Zeug ist eh schnarch langsam, da kommts darauf eh nicht mehr an.
Laber nich. Im kompletten Infiniband-Source-Tree von Linux gibt es keine SSE-Intrinsics.

Wofür auch? Das einzige was mir in den Sinn kommt ist memcpy und das ist generell auf die CPU optimiert die gerade läuft. Aber das meiste wird DMA sein, da spielt das erst recht keine Rolle.

[Ailuros]

Wie kommst du auf nur 50%? Die 780 Ti ist knapp doppelt so schnell wie die GTX 580 bei sogar geringfügig niedrigerer Leistungsaufnahme. Mit 20 nm ohne FinFETs könnte das aber durchaus anders aussehen.

Ja aber auch mit einem ziemlich riesigen Zeitabstand. Haette NV die 780Ti im September 2012 auf die Ladentische gebracht waere der Stromverbrauch keineswegs so bescheiden gewesen wie heute.

Mit der obrigen Logik oben aber (ergo wenn man auswartet bis jegliche 20nm Variante fuer high end am Ausgang ist) koennten sie schon etwas mehr anrichten und dabei ist FinFET auch ziemlich wurscht denn 16 FinFET bringt auch nicht unbedingt den Fruehling.

[Knuddelbearli]

Ja aber auch mit einem ziemlich riesigen Zeitabstand. Haette NV die 780Ti im September 2012 auf die Ladentische gebracht waere der Stromverbrauch keineswegs so bescheiden gewesen wie heute.



deshalb ja 580 und nicht 480

[Skysnake]

DMA macht nur Sinn, wenn das Zeug auch wirklich hinreichend groß ist.

Für Barriers usw. ist es halt ganz interessant, es anders zu machen. Und ja ich weiß, dass das definitiv nicht 0815 Zeug ist. Aber bei sowas schauste halt auch wo du noch ein paar Takte rausholen kannst.

Bei Einstelligen µs an Halfroundtrip Latenzen oder sogar noch darunter haste halt nichts zu verschenken.

Die ganze Sache ist an sich aber ganz schön offtopic hier an sich.

[Ailuros]

deshalb ja 580 und nicht 480

780Ti = GK110 B1
Titan = GK110 A1

Ausser Du willst mir einen einfachen metal spin wie oben mit einem hw bugfix chip wie zwischen GF110 und GF100 vergleichen.

[Duplex]

Die letzten Beiträge sind doch alle offtopic und haben mit dem Thema nichts zu tun...
Warum nicht gleich den Namen ändern?

[Knuddelbearli]

solange ein Mod dabei mitmacht ^^

und da es nie einen GK100 gab erübrigt sich es wieder. ansonsten nimmt halt Titan die war A1 und nur wenige Prozent langsamer

[Skysnake]

Ich glaub er meint eher, dass sich so wirklich gar kein Beitrag mehr um Maxwell dreht.

[Hugo78]

Die letzten Beiträge sind doch alle offtopic und haben mit dem Thema nichts zu tun...

Es kommt halt nur Gülle dabei raus, wenn man auf die selbstgefällige Scheiße vom NV-Hater der SA eingeht.

[boxleitnerb]

Ja aber auch mit einem ziemlich riesigen Zeitabstand. Haette NV die 780Ti im September 2012 auf die Ladentische gebracht waere der Stromverbrauch keineswegs so bescheiden gewesen wie heute.


Zum zeitlichen Abstand:
Klar, es ging aber doch um die Architektur glaube ich?

Zum Verbrauch:
Was willst du damit sagen? Dass der Verbrauch schlechter wird, je später man die Karte bringt?? Man hätte die Karte zahmer auslegen können, dann wäre sie sparsamer aber auch langsamer.


Mit der obrigen Logik oben aber (ergo wenn man auswartet bis jegliche 20nm Variante fuer high end am Ausgang ist) koennten sie schon etwas mehr anrichten und dabei ist FinFET auch ziemlich wurscht denn 16 FinFET bringt auch nicht unbedingt den Fruehling.

40nm war bei der GTX 580 ja auch ziemlich ausgereizt. Vergleiche sollte man schon bei ähnlichen Reifegraden des Prozesses ziehen, ja.

[Timbaloo]

Wie könnte denn das Denver in Maxwell (oder generell) denn genau aussehen? O.K. ARMv8. Es wurden in der Vergangenheit "(full) custom" Kerne genannt mit einer "secret sauce". Aber diesbezüglich ist bisher kaum was detaillierteres durchgesickert (oder an mir vorbeigesickert). Ist es wirklich ein komplettes Eigendesign? Oder hat man "nur" gewisse Teile angepasst? Vielleicht NV-eigenes SIMD? Oder hat man etwas zu fett auf die Kacke gehaut und jetzt kommt erst nur ein Standard Cortex-A5x? Für meinen Geschmack ein bißchen zu geheim die Soße :P

[Skysnake]

Darf nVidia überhaupt komplett eigene CPUs auf Basis der ARM ISA bauen?

[Timbaloo]

Laut wikipedia gibt es ein Lizenzmodell für diesen Fall:

http://en.wikipedia.org/wiki/ARM_architecture#Architectural_licence

Wobei der Beisatz "These cores must comply fully with the ARM architecture" neue Fragen aufwirft.

[Coda]

DMA macht nur Sinn, wenn das Zeug auch wirklich hinreichend groß ist.

Für Barriers usw. ist es halt ganz interessant, es anders zu machen. Und ja ich weiß, dass das definitiv nicht 0815 Zeug ist. Aber bei sowas schauste halt auch wo du noch ein paar Takte rausholen kannst.

Bei Einstelligen µs an Halfroundtrip Latenzen oder sogar noch darunter haste halt nichts zu verschenken.

Die ganze Sache ist an sich aber ganz schön offtopic hier an sich.
Du hast meine Frage nicht beamtwortet: Wo wollst du da SSE verwenden?

Jetzt nicht ablenken. Die Signalverarbeitung ist bei Infiniband alles in der Hardware.

[Skysnake]

Für nen Reduce z.B.

Oder wenn du RDMA machen willst mit kleinen buffern von <1-4kB usw. Da ist der Overhead von nem DMA viel zu groß.

xfence ist auch sehr gut um die Latenz zu drücken.

[Coda]

Was ist "Reduce"? xfence ist keine SSE-Instruction und dein RDMA klingt nach memcpy wo ich schon gesagt habe dass man das gefälligst wegabstrahiert.

[Skysnake]

Na du weißt z.B. durch nen Interrupt, dass die Daten da sind, und du Min/Max oder eben ne Summe aus 2-6 Werten bilden musst. Da kannste einfach den SSE Befehl nutzen.

Oder bei KNC halt z.B. in einem Rutsch 512 Bit rumkopieren.

Wobei ich bei paar Sachen nachschauen über fastmemcpy gestolpert bin in den Kernelsourcen. Das müsste ich mir mal in Ruhe genauer anschauen, inwieweit das alles/fast alles abdeckt.

Das "normale" memcpy im kernel verwendet ja nur mmx/3dnow. Zumindest ist mein Stand, das SSE und schon gar nicht AVX im kernel für memcpy verwendet wird. Zumindest ist das MEIN Infostand.

Falls du da andere Infos hat, und mir sogar ne Kenerlversion nennen kannst, bei der das anders ist, dann immer her damit! Auf ne neuere Kernelversion als bisher gehen ist je nachdem sicherlich schneller und einfacher gemacht, als die Sachen selbst zu implementieren.

Wobei ich bei KNC zumindest auf den 2.6.32-131er Kernel festgelegt bin und die 512 Bit Register definitiv nicht verwendet werden.

Die Idee dahinter ist ja sowas wie hier:
http://joryanick.com/retro/memcpy.htm

[Coda]

Wenn du wirklich glaubst, dass es sich bei sowas lohnt SSE zu verwenden wenn darum alles branch heavy Steuercode ist mit verstreuten Speicherzugriffen dann äähhh. Ach egal.

[Skysnake]

Also ich seh in meinem Code sehr wenige Branches und nur sehr wenige nicht zusammenhängende Speichersegmente, zudem solltest du den Leuten die den Code schreiben überlassen, ob sich etwas lohnt oder nicht. Vor allem ohne den Code jemals gesehen zu haben...

Das ist schon ziemlich tollkühn.

[Coda]

Es ist im Grunde auch egal ob sich solche Mikrooptimierungen lohnen oder nicht, nur wird kein ordentlicher Programmierer Treiber aus diesem Grund an eine Architektur ketten.

Linux und FreeBSD kannst du alles anschauen. Sauber, fast reines C und so weit es irgendwie geht platformneutral. Und erzähl mir bitte nicht das Zeug wäre nicht optimiert.

Es wäre außerdem auch mal interessant zu Erfahren für was dieser Treiber von dem du immer redest sein soll.

[Timbaloo]

Es ist im Grunde auch egal ob sich solche Mikrooptimierungen lohnen oder nicht, nur wird kein ordentlicher Programmierer Treiber aus diesem Grund an eine Architektur ketten.
Man kann ja auch spezielle Optimierungen optional einbauen wenn sie denn a) Sinn machen und b) in die Struktur der portablen Implementierung passen.
Mit Ach und Krach und wenig Not etwas komplett unportables zusammenzufrickeln macht natürlich wenig Sinn.

[Ailuros]

solange ein Mod dabei mitmacht ^^

und da es nie einen GK100 gab erübrigt sich es wieder. ansonsten nimmt halt Titan die war A1 und nur wenige Prozent langsamer

Es gab keinen GK100 weil eben mit GK110 alles von Anfang an stimmte; dass sie bis zum kotzen den letzteren ausgemelkt haben ist eine andere Geschichte. Es dauerte ein ganzes Jahr bevor sie zu einem einfachen metal spin kamen, wobei GF100 schon vor dem GTX480 release ganze zwei metal spins auf dem Buckel hatte.

Zum zeitlichen Abstand:
Klar, es ging aber doch um die Architektur glaube ich?

Zum Verbrauch:
Was willst du damit sagen? Dass der Verbrauch schlechter wird, je später man die Karte bringt?? Man hätte die Karte zahmer auslegen können, dann wäre sie sparsamer aber auch langsamer.

Um den Verbrauch ging es eigentlich; es sollte wohl klar sein dass ein Jahr nach dem originalen release es ein Kinderspiel sein sollte alle SMXs einzuschalten und etwas an der Taktschraube zu drehen ohne dass der Stromverbrauch beinflusst wird. Haette NV eine 780Ti schon im September 12' in die Produktion geschickt haette das Resultat wohl NICHT nur 250W TDP gehabt.


40nm war bei der GTX 580 ja auch ziemlich ausgereizt. Vergleiche sollte man schon bei ähnlichen Reifegraden des Prozesses ziehen, ja.

GF110 wurde in knapp in einem Halbjahr aufgelegt und der design war schon fertig bevor NV mit GF100 in die Massenproduktion ging. Rechnen kannst Du selber und es dauert im allerbesten Fall vom finalen tape out zur Massenproduktion 6 Monate. Wirklich "reif" ergo so bezahlbar wie aehnliche Prozesse der Vergangenheit und vergleichbare yields war 40G erst innerhalb 2012.

[boxleitnerb]

Um den Verbrauch ging es eigentlich; es sollte wohl klar sein dass ein Jahr nach dem originalen release es ein Kinderspiel sein sollte alle SMXs einzuschalten und etwas an der Taktschraube zu drehen ohne dass der Stromverbrauch beinflusst wird. Haette NV eine 780Ti schon im September 12' in die Produktion geschickt haette das Resultat wohl NICHT nur 250W TDP gehabt.


Ah ok, es klang bei dir irgendwie umgekehrt ;)
Aber der Verbrauch ist ja schon etwas gestiegen ggü. Titan. Die Frage ist, ob es an der GPU selbst oder am höheren Speichertakt liegt.


GF110 wurde in knapp in einem Halbjahr aufgelegt und der design war schon fertig bevor NV mit GF100 in die Massenproduktion ging. Rechnen kannst Du selber und es dauert im allerbesten Fall vom finalen tape out zur Massenproduktion 6 Monate. Wirklich "reif" ergo so bezahlbar wie aehnliche Prozesse der Vergangenheit und vergleichbare yields war 40G erst innerhalb 2012.

So spät? Hätte ich nicht gedacht. Jedenfalls dürfte es sicher bist 2015 dauern, bis 20nm für Enthusiast-GPU bereit ist.

Was ich letztendlich sagen wollte:
+100% sind immer noch drin, es dauert nur etwas länger, aber so ganz 3 Jahre sind es noch nicht, eher 2,5.

[Ailuros]

Wie könnte denn das Denver in Maxwell (oder generell) denn genau aussehen? O.K. ARMv8. Es wurden in der Vergangenheit "(full) custom" Kerne genannt mit einer "secret sauce". Aber diesbezüglich ist bisher kaum was detaillierteres durchgesickert (oder an mir vorbeigesickert). Ist es wirklich ein komplettes Eigendesign? Oder hat man "nur" gewisse Teile angepasst? Vielleicht NV-eigenes SIMD? Oder hat man etwas zu fett auf die Kacke gehaut und jetzt kommt erst nur ein Standard Cortex-A5x? Für meinen Geschmack ein bißchen zu geheim die Soße :P

Als was wuerdest Du Apple's A7 Cyclone (64bit) CPU bezeichnen?


So spät? Hätte ich nicht gedacht.

Dass Prozesse zunehmend problematisch sind ist doch nichts mehr Neues.

Jedenfalls dürfte es sicher bist 2015 dauern, bis 20nm für Enthusiast-GPU bereit ist.

Ein 20nm Maxwell ist vom design her auf jeden Fall schon fertig.

Was ich letztendlich sagen wollte:
+100% sind immer noch drin, es dauert nur etwas länger, aber so ganz 3 Jahre sind es noch nicht, eher 2,5.

Maxwell wird am Anfang mit aller Wahrscheinlichkeit nicht den gleichen Unterschied wie Kepler vs. Fermi bzw. Fermi vs. Tesla machen. Mein Verdacht ist dass dafuer mit der Zeit vielleicht die sw aufholen muss. Sollte auch keine wundern mit der Richtung die GPUs zunehmend in letzter Zeit nehmen.

[Timbaloo]

Als was wuerdest Du Apple's A7 Cyclone (64bit) CPU bezeichnen?
Hab mich nie mit Apples Designs auseinandergesetzt. Die Frage kann ich nicht beantworten.
Aber du weisst doch mehr, lass raus :P

[boxleitnerb]

Ein 20nm Maxwell ist vom design her auf jeden Fall schon fertig.


Auch der große Maxwell?


Maxwell wird am Anfang mit aller Wahrscheinlichkeit nicht den gleichen Unterschied wie Kepler vs. Fermi bzw. Fermi vs. Tesla machen. Mein Verdacht ist dass dafuer mit der Zeit vielleicht die sw aufholen muss. Sollte auch keine wundern mit der Richtung die GPUs zunehmend in letzter Zeit nehmen.

Ich dachte Maxwell sollte eher stärker sein weil du ja mal gemeint hattest, die Unterschiede zwischen Maxwell und Kepler sind größer als Kepler vs Fermi.

[Skysnake]

Auch der große wird sicherlich vom Design an sich her fertig sein. Was halt noch massig zu tun sein wird ist das Timing und halt Debugging. Da kannste massig Zeit für einplanen.

Es ist im Grunde auch egal ob sich solche Mikrooptimierungen lohnen oder nicht, nur wird kein ordentlicher Programmierer Treiber aus diesem Grund an eine Architektur ketten.

Weil man ja auch keine #ifdef verwenden kann :rolleyes:

Zumal man auch mal über den Verwendungsbereich nachdenken sollte. Wieviele CPUs ohne SSE kennste denn in HPC Clustern abgesehen von IBM und Sparc?


Linux und FreeBSD kannst du alles anschauen. Sauber, fast reines C und so weit es irgendwie geht platformneutral. Und erzähl mir bitte nicht das Zeug wäre nicht optimiert.
Da haste aber auch ne komplett anderes Ausgangslage. Das Zeug muss so ziemlich auf allem laufen, was es nur irgendwo gibt.

Was du hier propagierst ist als ob du Konsolenentwicklern raten würdest, Sie sollten doch möglichst nur reines C und keine spezifischen Sachen usw nutzen, nur damit es möglichst portabel ist...


Es wäre außerdem auch mal interessant zu Erfahren für was dieser Treiber von dem du immer redest sein soll.
Kerneltreiber für nen NIC für HPC Cluster, wobei ich mich um die XeonPhi-Portierung der kompletten Software von unten bis oben kümmere. Und nein, du hast da absolut nichts zu verschenken...

[del_4901]

Weil man ja auch keine #ifdef verwenden kann :rolleyes:In der codebase wuerde ich nicht arbeiten wollen... :rolleyes:

[Ailuros]

Hab mich nie mit Apples Designs auseinandergesetzt. Die Frage kann ich nicht beantworten.
Aber du weisst doch mehr, lass raus :P

Ist doch ein voller custom design basierend auf 64bit ARM ISA. Wen es bei Apple und auch Qualcomm geht, waere es absurd wenn NVIDIA es nicht duerfen koennte.

Auch der große Maxwell?

Ein design ist fertig; ein "auch" passt dann nicht in den gleichen Satz.

http://focustaiwan.tw/news/atod/201312050035.aspx

Industry sources said TSMC's 20nm production capacity has been booked up with orders from industry giants including Apple Inc., Qualcomm Inc., Xilinx, Altera, Supermicro, NVIDIA, MediaTek and Broadcom Corp.

Logan/T5 = 28HPm, Parker/T6 = 16 FinFET

Ich dachte Maxwell sollte eher stärker sein weil du ja mal gemeint hattest, die Unterschiede zwischen Maxwell und Kepler sind größer als Kepler vs Fermi.

Kommt es nicht eher darauf an wo die Unterschiede gerade liegen und dementsprechend wo sich die jeweiligen Vorteile auch wirklich ausspielen?

[Hübie]

Ich denke box meinte eher den Versatz wie bei GK104《》GK110. Die tapeouts lagen, wenn ich mich richtig erinnere 6 Monate auseinander. Und das Design hat ja im Detail ein paar Veränderungen (fp64 ALUs..).

[Skysnake]

In der codebase wuerde ich nicht arbeiten wollen... :rolleyes:
Och, das geht eigentlich ziemlich entspannt. Man muss halt "nur" wirklich sehr sehr diszipliniert sein und die Grundidee konsequent umsetzen. Dann geht das eigentlich. Mir reicht es ein #define zu setzen, und dann wars das. um zwischen x86 und KNC zu wechseln.

Da die Änderungen an den Funktionen nach außen hin fast immer transparent sind, hält sich die Komplexität auch in Grenzen. Kernelfunktionen da nachzuvollziehen empfinde ich da als tausendfach schlimmer, da man ja teilweise gar nicht sieht, welche Variante einer Funktion denn jetzt wirklich verwendet wird. Die Kernel-configs zu analysieren macht echt keinen Spaß :down:

[Timbaloo]

Ist doch ein voller custom design basierend auf 64bit ARM ISA. Wen es bei Apple und auch Qualcomm geht, waere es absurd wenn NVIDIA es nicht duerfen koennte.
Hab ich auch nie geglaubt.

[Ailuros]

Hab ich auch nie geglaubt.

Ich zumindest glaub auch nicht dass ihre angebliche "secret sauce" etwas besonderes ist, aber ich koennte auch damit der einzige sein ;)

[Timbaloo]

Aber "secret sauce" klingt toll. Wieviel Scoville die wohl hat? :freak:

[Hugo78]

Irgendwas wird sich von den Transmeta-Leuten schon verwerten lassen in einem eigenem Design.
Und mit Blick auf den IBM Deal könnte es diesmal ein Power/ARM-Hybrid werden.
damals:
Gerüchte, die besagten, dass Transmeta einen PowerPC/x86-Hybriden entwickle, was sie auch hätten tun können
- http://de.wikipedia.org/wiki/Transmeta

[Skysnake]

Das läuft doch schon darauf hinaus, was nVidia versucht hat. Eine Emulation von x86 dem Intel eine Absage erteilt hat.

Zudem gehe ich davon aus, das man die dynamische Taktung der GPUs praktisch als Ergebnis der Transmeta Leute ansehen kann.

[sth]

Ich habe im letzten Jahr gerade sämtliche Endianess-#ifdefs aus meiner Codebase entfernt, da ja nun endlich alle Mainstream-Plattformen die gleiche Byte Order haben und der Big Endian Codepfad ohnehin seit Jahren ungetestet brach liegt.

Nach Murphys Law müsste nun in absehbarer Zeit wieder was größeres im PowerPC-Bereich passieren. ;)

[Schnitzl]

ist da was dran?
http://www.computerbase.de/news/2013-12/hinweise-auf-nvidias-maxwell-im-1.-quartal-2014/

oder nur Taktik/Marketing? =)

[Blediator16]

Was genau meinst du denn? Wenn du denkst Highend ist damit gemeint, dann eher nicht.

[Burgard]

Wenn du denkst Highend ist damit gemeint, dann eher nicht.
WIeso, gerade da macht eine Risk-Produktion Sinn.
Eine Maxwell-Titan in 20nm kann man locker wieder für 1000 Euro an den Mann bringen, da ist die Ausbeute absolut nebensächlich.
Okay, eine schlechte Yield ist verschmerzbar. :biggrin:

Bei der normalen Highend-Class sehe ich das ganze schon kritischer und blicke eher in Richtung III- Quartal.

Noch besser geht es mit der Quadro.

[Ailuros]

WIeso, gerade da macht eine Risk-Produktion Sinn.
Eine Maxwell-Titan in 20nm kann man locker wieder für 1000 Euro an den Mann bringen, da ist die Ausbeute absolut nebensächlich.
Okay, eine schlechte Yield ist verschmerzbar. :biggrin:

Bei der normalen Highend-Class sehe ich das ganze schon kritischer und blicke eher in Richtung III- Quartal.

Noch besser geht es mit der Quadro.

A. Wofuer steht denn genau "risk production" Deiner Meinung nach?
B. Maxwell@20nm wird es definitiv nicht vor H2 14' geben.
C. "Eine schlechte Yield" ist eben NICHT verschmerzbar, wenn Du ueberhaupt wuesstest wieviel so ein chip in Herstellung kosten koennte.
D. Was ist ein III-Quartal?

[Burgard]

A. Wofuer steht denn genau "risk production" Deiner Meinung nach?
B. Maxwell@20nm wird es definitiv nicht vor H2 14' geben.
C. "Eine schlechte Yield" ist eben NICHT verschmerzbar, wenn Du ueberhaupt wuesstest wieviel so ein chip in Herstellung kosten koennte.
D. Was ist ein III-Quartal?
A.
Testbetrieb für Massenfertigung benutzen, das hat schon AMd mehr oder weniger erfolgreich gemacht.
B.
Ich schrieb ja auch dazu, dass es ggf. die Quadro wird.
C.
Wenn der VK-Preis entsprechend hoch ist, kann man durchaus mit einer niedrigen Yield leben.
Leider habe ich keine genaue Kostenaufstellung, aber zumindest soll ein Wafer in 20nm ca 140% betragen im Vergleich zu einem 28nm-Wafer,
wieviel das auch immer sein soll. (Ich hasse %-Angaben ohne dazugehörige Grösse)
http://www.3dcenter.org/dateien/abbildungen/Wafer-Kosten-28nm-20nm-14nm.jpg
Daher gehe ich eher von einem HOchpreisartikel aus, als ein Lowcost-Produkt, wie seinerzeit die Radeon 4770.

D.
Im dritten Quartal fängt dann vermutlich die Massproduktion in 20nm an.

“On 16 FinFET, technological development is progressing well. Risk production is on schedule by the end of this year. More than 25 customer product tape-outs are planned in 2014 including mobile computing, CPU, GPU, PLD and networking applications. We are on track to begin volume production within one year of 20nm,” explained the head of TSMC.
vom 22.10.2013
TSMC Shares More Details Regarding 16nm FinFET and 20nm Progress. (http://www.xbitlabs.com/news/other/display/20131022230815_TSMC_Shares_More_Details_Regarding_16nm_FinFET_and_20nm_Progress. html)

[Hübie]

Kann durchaus sein. Dann aber entweder noch 28 HPM oder kleine 20-nm-Dies. nVidia schießt sich ja nicht ins eigene Bein und veröffentlicht kurz nach dem GK110-Top-Dog schon den Maxwell-Top-Dog.

[Godmode]

Kann durchaus sein. Dann aber entweder noch 28 HPM oder kleine 20-nm-Dies. nVidia schießt sich ja nicht ins eigene Bein und veröffentlicht kurz nach dem GK110-Top-Dog schon den Maxwell-Top-Dog.

Also für Q2 2014 erwarte ich einen Nachfolger für GK104. Q4 2014 bis Q1-2 2015 dann den Nachfolger für GK110. Wer will mit mir wetten?

[Hübie]

Das meinte ich mit kleinen Die ;)

[Dawn on Titan]

Ich würde eher GM107/108 als ersten 20nm Chip erwarten.

[Ailuros]

A.
Testbetrieb für Massenfertigung benutzen, das hat schon AMd mehr oder weniger erfolgreich gemacht.

Von "risk production" bis zur Massenfertigung liegt im idealsten Fall eine Zeitspanne von ueber einem Jahr.
B.
Ich schrieb ja auch dazu, dass es ggf. die Quadro wird.

Man braucht auch so nicht besonders lange um zu sehen dass es sich nur um basislose frei erfundenen Optimismus handelt.

C.
Wenn der VK-Preis entsprechend hoch ist, kann man durchaus mit einer niedrigen Yield leben.
Leider habe ich keine genaue Kostenaufstellung, aber zumindest soll ein Wafer in 20nm ca 140% betragen im Vergleich zu einem 28nm-Wafer,
wieviel das auch immer sein soll. (Ich hasse %-Angaben ohne dazugehörige Grösse)

Tu mir den Gefallen und reim Dir keinen Stuss zusammen, nur damit Dir etwas in Deine Vorstellung passt. Die ersten Maxwell GPUs (und eben nicht der top dog) werden im ersten Halbjahr unter 28nm kommen, eben weil es trotz groesserer die area immer noch teurer sein wird unter 20SoC herzustellen.


D.
Im dritten Quartal fängt dann vermutlich die Massproduktion in 20nm an.

Nur war im link oben die Rede von einer Q1 Massenproduktion mit einer ~Maerz Veroeffentlichung.


vom 22.10.2013
TSMC Shares More Details Regarding 16nm FinFET and 20nm Progress. (http://www.xbitlabs.com/news/other/display/20131022230815_TSMC_Shares_More_Details_Regarding_16nm_FinFET_and_20nm_Progress. html)

Kannst Du Dir sparen; TSMC wie jegliche andere foundry erzaehlen einen Haufen Scheiss wenn der Tag lang ist. FYI wird es noch einige Zeit bis zum ersten 20SoC tape out dauern; wenn es erst zum finalen tape out kommt koennen wir im idealsten Fall noch 6 Monate fuer die Massenproduktion dazurechnen. Eben genau der Grund warum IHVs bevor das Ei gelegt ist dezent die Klappe halten. Vorruebergehend ist lediglich Maxwell@28nm eine Realitaet und dieses hauptsaechlich um stromsparendere GPUs auf die Schiene zu bringen.

[Dawn on Titan]

Also 28HPM? In 28HP dürfte ja nicht mehr viel Potential schlummern.

[Ailuros]

Also 28HPM? In 28HP dürfte ja nicht mehr viel Potential schlummern.

Ich hatte HPm im Visier so lange ich dachte dass AMD's Hawaii auf diesem hergestellt wurde; nachdem der letzte aber auf 28HP ist hab ich so manchen Zweifel. Ausschliessen kann man es zwar nicht, aber das einzige ueber das was ich mir fuer NVIDIA sicher bin ist Tegra5/Logan@TSMC 28HPm.

[Dawn on Titan]

AMD will ja im Frühjahr auch etwas launchen. Evtl. kommen beide dann mit HPM.

[Skysnake]

Da wir sicherlich die Mobile-Varianten wieder zuerst sehen werden, und auch da die kleineren, seh ich die Chancen für HPM gar nicht soo schlecht. Für Desktop ist das aber halt völlig uninteressant.

[AnarchX]

In China schwirren schon N15E-SKU-Varianten herum - GTX 880M/GTX 870M mit 8/6 GiB. Wobei das wahrscheinlich GK104-Rebrands sind.

[Ailuros]

Da wir sicherlich die Mobile-Varianten wieder zuerst sehen werden, und auch da die kleineren, seh ich die Chancen für HPM gar nicht soo schlecht. Für Desktop ist das aber halt völlig uninteressant.

ΝV wollte gerechtfertigt bevor GK104 fertig war nichts von Kepler ankuendigen; eben weil das meiste darunter keine besonderen Eindruecke gewinnen konnte und weil GK104 schon seit immer als der "top dog" fuer notebooks geplant war. Chancen dass sich die Masche auch mit Maxwell wiederholt sind nicht gering.

Wenn bis Maerz/April kein performance SKU ankommen sollte, besteht IMHO auch kein besonderer Grund fuer irgend eine Ankuendigung fuer Maxwell mit allen Fanfaren.

[Hübie]

Man muss ja auch mal ehrlich sagen dass das Performance-Segment mit der GTX 660 - 770 noch gut gedeckt ist. Ich erwarte jedenfalls keinen Knall im März/April. Zyklisch würde in der Tat eine Notebook SKU sinnvoll sein, aber die Präsens Intels iGPU im Haswell macht diese fast obsolet. Allerdings ist Iris Pro außerhalb der MacBooks immer noch ein Papiertiger.

[Duplex]

So oder so wird es erst spannend mit 20nm FF aka 16nm, alles unter 80% Speedup ist gegenüber GK110 uninteressant, vor 2015 wird das nichts mehr.

[Hübie]

Ack. Mit ersten 20-nm-GPUs rechne ich persönlich eher in Q3/2014. Und die, welche für GK110-Besitzer interessant werden entsprechend später.

[Ailuros]

So oder so wird es erst spannend mit 20nm FF aka 16nm, alles unter 80% Speedup ist gegenüber GK110 uninteressant, vor 2015 wird das nichts mehr.

http://phx.corporate-ir.net/phoenix.zhtml?c=116466&p=irol-IRHomeDisclaimer

Schau Dir mal das BMO Dezember 2013 an; sooooo "spannend" sind heutzutage Dinge bei NV so oder so. Was die sie kunterbuntes mit IP licensing gerade erhoffen wissen sie wohl selber.

[Nightspider]

alles unter 80% Speedup ist gegenüber GK110 uninteressant

Für dich vielleicht.

[Godmode]

Ack. Mit ersten 20-nm-GPUs rechne ich persönlich eher in Q3/2014. Und die, welche für GK110-Besitzer interessant werden entsprechend später.

Also mehr als 60% erwarte ich nicht gegenüber der schnellsten GK110 Lösung. Die Zeiten mit 80%+ sind schon lange vorbei.

[Duplex]

Also mehr als 60% erwarte ich nicht gegenüber der schnellsten GK110 Lösung
Ja, mit 20nm SOC sind 60% auch kein Problem.

Die Zeiten mit 80%+ sind schon lange vorbei.
Aber nicht mit (16nm) 20nm FF, darauf hin bezog ich mich vorhin.

2014 = 20nm SOC
2015 = 20nm FF (16nm)

[Ailuros]

Wenn NV wirklich den Maxwell top dog fuer den desktop unter 16 FinFET herstellen wuerde wie hier manche erwarten dann wird es schon um einiges mehr als 60% sein; das dumme ist dann halt eben dass man vor Herbst 2015 nichts bei der Komplexitaet unter 16 FinFET erwarten sollte :P Pick your poison :weg:

[Dawn on Titan]

Sagen wir Frühjahr 2016 wenn TSMC in gewohnter Form bleibt. Abgesehen davon was wäre an einem GM104 falsch der es auf ca. 780ti Leistung - 5% auf 400mm² (28HPM) bei 180W TDP bringt? (Alternativ 350mm² - 780ti + 20% @ 180W für 20nm)

[Ailuros]

Falsch ist so ein Resultat nie; jetzt musst Du eben nur noch eine spekulative These auflegen die auch Sinn macht wie man so weit kommt.

[Dawn on Titan]

Im Frühjahr 2014 wird da sicher schwer, da 20nm kein Thema ist und niemand sagen kann ob 28HPM überhaupt für große GPUs taugt und was es da bringt. Ich wäre schon erfreut, wenn sie 780 Leistung @ 180W TDP damit hinkriegen würden.

[Duplex]

28nm hat ausgedient

GT200A > 65nm
GT200B > 55nm

GF100 > 40nm
GF110 > 40nm

GK110A 28nm
GK110B 28nm

Maxwell war schon immer für 20nm geplant, was wollt ihr mit einem 28nm 400-450mm² Mawell und wo soll sich dieser einordnen?

[robbitop]

GK104 war IIRC nur 30% schneller als GF110. Das könnte ggf für GM104 auch ein Anhaltspunkt sein.

[Ailuros]

Im Frühjahr 2014 wird da sicher schwer, da 20nm kein Thema ist und niemand sagen kann ob 28HPM überhaupt für große GPUs taugt und was es da bringt. Ich wäre schon erfreut, wenn sie 780 Leistung @ 180W TDP damit hinkriegen würden.

Nur bleibt es leider ein rein theoretischer Wunschtraum wenn Du mir nicht sagen kannst wie sie dazu kommen wuerden.

28nm hat ausgedient

GT200A > 65nm
GT200B > 55nm

GF100 > 40nm
GF110 > 40nm

GK110A 28nm
GK110B 28nm

Sagt wer?

Maxwell war schon immer für 20nm geplant, was wollt ihr mit einem 28nm 400-450mm² Mawell und wo soll sich dieser einordnen?

Dann wende Dich doch bitte mal selber an NVIDIA wenn Du Dir so sicher bist dass alles Maxwell mir nichts Dir nichts 20nm sein muss, nur weil es rein zufaellig nicht in Deine Vorstellung passt. Es gibt momentan nur einen einzigen chip fuer 2014 fuer 20SoC geplant von dem was ich hoere. Aber es kann ja tatsaechlich sein dass Du wirklich etwas mit mehr Substanz hast dass wir nicht wissen als der obrige Kaese. Herstellungsprozesse werden zunehmend problematisch und IHVs werden zunehmend laenger auf einem jeglichen Prozess stecken bleiben. Was genau ist daran so schwer zu verstehen?

[Dawn on Titan]

Nur bleibt es leider ein rein theoretischer Wunschtraum wenn Du mir nicht sagen kannst wie sie dazu kommen wuerden.


Sollte HPM nicht bis zu 20'% weniger Lesitungsaufnahme bringen? Dazu ein entschlackter Chip ohne GPGPU Ballast mit den hoffentlichen Effizienzsteigerungen des Maxwell Designs. <200W TDP könnte in einem Bestcase Scenario denkbar sein.

[=Floi=]

GK104 war IIRC nur 30% schneller als GF110. Das könnte ggf für GM104 auch ein Anhaltspunkt sein.

kann man so nicht pauschal sagen, weil die keppler karte die doppelte theoretische rechenleistung besitzt und das schon durchschlagen kann.

[Timbaloo]

Es gibt momentan nur einen einzigen chip fuer 2014 fuer 20SoC geplant von dem was ich hoere.
Prickelnd :eek:

Da muss meine GF104 noch eine Weile aushalten :freak:

[Duplex]

GK104 hatte gegenüber GF110 ein neuen Prozess, beim gleichen Prozess hätte man kein Speedup gesehen.
Ein 28nm Maxwell ist nicht das Wahre, damit kann man keine 30% gegenüber GK104 zulegen, 10-15% lohnt nicht.

[Sunrise]

Ein 28nm Maxwell ist nicht das Wahre, damit kann man keine 30% gegenüber GK104 zulegen, 10-15% lohnt nicht.
Was du dir da immer aus den Fingern ziehst, da kann man nur staunen.

[Ailuros]

Sollte HPM nicht bis zu 20'% weniger Lesitungsaufnahme bringen? Dazu ein entschlackter Chip ohne GPGPU Ballast mit den hoffentlichen Effizienzsteigerungen des Maxwell Designs. <200W TDP könnte in einem Bestcase Scenario denkbar sein.

Engineers schalten bei chip-Entwicklung offensichtlich nicht auf den auto-pilot :rolleyes:

GK104 hatte gegenüber GF110 ein neuen Prozess, beim gleichen Prozess hätte man kein Speedup gesehen.

Wenn so viel am Prozess haengen wuerde wie Du Dir einreimen willst waere der GF110 28nm shrink effizienter gewesen als GK104; es war eher das brutale Gegenteil. Sonst natuerlich waere ein speedup auf einem hypothetischen GK104@40G moeglich gewesen. Es haette mehr an die area gekostet was dem Endkunden aber scheissegal sein haette koennen. Bei einem MSRP von fast $600 haette es auch keine rote Zahlen gegeben.

Ein 28nm Maxwell ist nicht das Wahre, damit kann man keine 30% gegenüber GK104 zulegen, 10-15% lohnt nicht.

Sunrise hat leider recht....:rolleyes:

***edit: und damit es nicht zu steril klingt sowohl Tahiti als auch Hawaii wurden unter 28HP hergestellt.

Prickelnd :eek:

Da muss meine GF104 noch eine Weile aushalten :freak:

Keine Ahnung fuer was; koennte aber locker aber auch HPC only sein. Wenn das Ding erstmal zum tape out kommt, hoeren wir vielleicht irgendwelches relevantes Gefluester und dann finden wir vielleicht auch heraus wie gross es ist.

[Dawn on Titan]

Sunrise hat leider recht....:rolleyes:

***edit: und damit es nicht zu steril klingt sowohl Tahiti als auch Hawaii wurden unter 28HP hergestellt.

10% mehr Diefläche - 10% mehr Effizienz + X für HPM.... wäre denkbar imho.

Wobei der Dreh- und Angelpunkt da der HPM Prozess ist. Ohne den würde so ein Chip sehr wenig Sinn machen.

[Nightspider]

Wenn Maxwell im Februar kommt, wird die 780ti sicherlich auf 500 Euro fallen und die 880 bei 700-800 Euro anfangen.
Bleibt die Frage wie viele Leute so viel Geld dafür ausgeben werden.

[Rente]

Warum sollte die Ti fallen? Außerdem kommt GM104 sicherlich nicht im Februar, erst mal sind die Low-End- und Notebook-Chips dran.

[Blaire]

Wenn Maxwell im Februar kommt, wird die 780ti sicherlich auf 500 Euro fallen und die 880 bei 700-800 Euro anfangen.
Bleibt die Frage wie viele Leute so viel Geld dafür ausgeben werden.

Unwahrscheinlich. Das würde voraussetzen, das keine weiteren GK110 Varianten mehr erscheinen, davon würde ich aktuell nicht ausgehn.

[Nightspider]

Warum sollte die Ti fallen? Außerdem kommt GM104 sicherlich nicht im Februar, erst mal sind die Low-End- und Notebook-Chips dran.

Weil die 780ti dann mit etwas größerem Abstand nicht mehr die schnellste Karte ist und mit Sicherheit nicht das Featureset der GTX880 haben wird.

Unwahrscheinlich. Das würde voraussetzen, das keine weiteren GK110 Varianten mehr erscheinen, davon würde ich aktuell nicht ausgehn.

Gehst du echt davon aus, das Nvidia in den nächsten 2 Monaten noch mehr GK110 Varianten auf den Markt wirft?

[Dawn on Titan]

Ne 6GB 780ti.

[Ailuros]

10% mehr Diefläche - 10% mehr Effizienz + X für HPM.... wäre denkbar imho.

Wobei der Dreh- und Angelpunkt da der HPM Prozess ist. Ohne den würde so ein Chip sehr wenig Sinn machen.

Ich bezweifle dass Du mich nicht vestehen kannst, Du willst es einfach nicht. Der Prozess ist lediglich ein Werkzeug ein bestimmtes design-Ziel leichter zu erreichen und nichts anderes. Bei einer neuen Architektur sollte die Mehrzahl der Effizienz-Steigerung von den Erweiterungen der Architektur selber kommen sonst wuerden wir von einem shrink bzw. refresh reden.

In der Zwischenzeit schmeisst Du mir nur mit sterilen Zahlen herum ohne selbst zu versuchen zu erklaeren wie man ein jegliches 10% durch die Architektur selber erreichen koennte.

Ne 6GB 780ti.

Ueberlaesst man den vendors ausser NV stellt einen weiteren Titan Black Edition vor mit 12GB um etwas verdammt nahe am Tausender wieder kassieren zu koennen.

Maxwell@28nm wird wohl auch nicht als Ziel haben jeglichen GK110 zu ersetzen.

Wenn Maxwell im Februar kommt, wird die 780ti sicherlich auf 500 Euro fallen und die 880 bei 700-800 Euro anfangen.
Bleibt die Frage wie viele Leute so viel Geld dafür ausgeben werden.

Es wird vorraussichtlich im H1 keinen high end Maxwell chip geben; selbst wenn es einen fuer 20SoC fuer's zweite Halbjahr geben sollte steht nirgendwo etwas das garantiert dass NV diesen NICHT vorruebergehend exklusiv fuer HPC benutzen wird bis die 20SoC yields/Kapazitaeten um zich Male besser werden.

[Dawn on Titan]

In der Zwischenzeit schmeisst Du mir nur mit sterilen Zahlen herum ohne selbst zu versuchen zu erklaeren wie man ein jegliches 10% durch die Architektur selber erreichen koennte.

Architektur und Prozess gehen bzw. gingen bisher aber Hand in Hand. Würde man z.B. feststellen, dass eine massive Vergrößerung der Caches die Effizienz verbessern würde, so muss man eben doch auch die Diefläche / das Transistorbudget haben um die Verbesserung realisieren zu können. Ich halte es für sehr schwierig zu schätzen welche Gewinne man mit einer neuen Architektur in einem konstanten Transistorbudget realisieren kann bzw. wie effektiv sich die neue Architektur dort umsetzen lässt. Dazu kommt natürlich noch, dass mehr Transistoren im alten Prozess nicht nur Diefläche kosten, was finanziell durch sinkende Waferpreise und steigende Yields evtl. kompensierbar ist, sondern meist auch mit einer steigenden Leistungsaufnahme einher gehen, was heute sicher nur noch in sehr geringem Umfang hinnehmbar ist. Je höher die Effizienz der alten Architektur desto schwieriger dürfte ein großer Sprung mit der neuen im alten Fertigungsprozess werden. Wenn wir Intel als Maßstab heranziehen, dann dürften 10% möglich sein.

[Ailuros]

Architektur und Prozess gehen bzw. gingen bisher aber Hand in Hand.

Das aendert gar nichts an der Tatsache dass der Prozess nach wie vor nur ein Werkzeug ist. Ein GF110 unter 28nm mit doppelt so viel Einheiten als der originale 40G/GF110 waere theoretisch nicht doppelt so schnell wie der letzte, ein GK110@28nm dann eben schon.

Würde man z.B. feststellen, dass eine massive Vergrößerung der Caches die Effizienz verbessern würde, so muss man eben doch auch die Diefläche / das Transistorbudget haben um die Verbesserung realisieren zu können. Ich halte es für sehr schwierig zu schätzen welche Gewinne man mit einer neuen Architektur in einem konstanten Transistorbudget realisieren kann bzw. wie effektiv sich die neue Architektur dort umsetzen lässt. Dazu kommt natürlich noch, dass mehr Transistoren im alten Prozess nicht nur Diefläche kosten, was finanziell durch sinkende Waferpreise und steigende Yields evtl. kompensierbar ist, sondern meist auch mit einer steigenden Leistungsaufnahme einher gehen, was heute sicher nur noch in sehr geringem Umfang hinnehmbar ist. Je höher die Effizienz der alten Architektur desto schwieriger dürfte ein großer Sprung mit der neuen im alten Fertigungsprozess werden. Wenn wir Intel als Maßstab heranziehen, dann dürften 10% möglich sein.

Dann koennen wir auch beruhigt den thread dicht machen. Fuer HPC zumindest verspricht NV zumindest >2x Mal so viel DP FLOPs/W. Das war und ist erstmal der erste Anhaltspunkt.

* Bleiben sie bei dedizierten FP64 ALUs und 3:1 oder wird es wieder eine Aenderung geben?

* Bleibt es bei SIMD32 oder koennte es sein dass sie vielleicht doch auch wie AMD auf SIMD64 gestiegen sind?

* etc etc.

Sonst kann ich bei bestem Willen nicht verstehen wofuer Intel und mit was ein Masstab sein soll. Ja Intel verspricht eine DP TFLOP Rate fuer Knights Landing in etwa in der Maxwell top dog Region....ja und?

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=548306

[Dawn on Titan]

Die Frage ist halt (imho) ob das "Maxwell Versprechen" sich auf die 28nm oder die 20nm Version bezog. Ich vermute ja letztere Variante. Denn ich bin mir nicht sicher, ob wir 28nm Maxwell im HPC sehen werden.

[Ailuros]

Die Frage ist halt (imho) ob das "Maxwell Versprechen" sich auf die 28nm oder die 20nm Version bezog. Ich vermute ja letztere Variante. Denn ich bin mir nicht sicher, ob wir 28nm Maxwell im HPC sehen werden.

Das es in 28nm im besten Fall bis zu einem performance chip von Maxwell sehen werden ist schon seit geraumer Zeit klar.

[Gaestle]

Maxwell@28nm wird wohl auch nicht als Ziel haben jeglichen GK110 zu ersetzen.


Wird den H1/2014-Maxwell zumindest alle derzeit verfügbaren Gamer-GK110 ersetzen können?

[Ailuros]

Wird den H1/2014-Maxwell zumindest alle derzeit verfügbaren Gamer-GK110 ersetzen können?

Wieso auch? Hat die GTX680 wirklich je eine GTX580 ersetzen koennen? Ja sie war um ca. 30% schneller aber ein wirklicher upgrade zum letzten wohl nicht.

[Dawn on Titan]

Das es in 28nm im besten Fall bis zu einem performance chip von Maxwell sehen werden ist schon seit geraumer Zeit klar.

Und ich bezog mich nur auf das Potential dieser Chips. GK104 war ja sogar auf einem neuen Prozess im Vergleich zur 580 eher mau. GM104 zu GK104 auf dem selben Prozess könnte noch öder werden.

[Timbaloo]

* Bleiben sie bei dedizierten FP64 ALUs und 3:1 oder wird es wieder eine Aenderung geben?
Laut dem von dir gefundenen Spekulations-Heureka (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9946140&postcount=557) wäre es sogar nur 4:1. Zwei FP64 ALUs pro SMX für 2:1?

[Sunrise]

GK104 war ja sogar auf einem neuen Prozess im Vergleich zur 580 eher mau.
Bitte was? GK104 war in Anbetracht der Größe ein ziemlich heftiger Schritt vorwärts. In fast jeder Hinsicht. Natürlich in dem Rahmen, den Ailuros erwähnt hat. Aber bei der Größe war das schon recht beachtlich.

Aus der Sicht der Endkunden war das natürlich eher mau, weil teuer verkauft und da natürlich auch deutlich mehr ging und das jeder wusste. Dennoch verkaufte sich das Teil und brachte NV sehr hohe Margen. Fragt sich nur, ob NV dieses Spielchen weiter spielen kann, wenn Ihnen jetzt sowohl von unten als auch von oben die Äste abgesägt werden.

[Hugo]

Sonst kann ich bei bestem Willen nicht verstehen wofuer Intel und mit was ein Masstab sein soll. Ja Intel verspricht eine DP TFLOP Rate fuer Knights Landing in etwa in der Maxwell top dog Region....ja und?

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=548306

Damit haben wir doch den ersten Anhaltspunkt.

KNL soll ja 3TFlops DP haben. Setzen wir das auch mal für Maxwell an.
Dann wären das bei einem 3:1 ja 9 TFlops SP oder bei 4:1 sogar 12 TFlops SP
Aber das sagt ja noch nichts aus wie Leistungsfähig Maxwell für uns Gamer sein kann.

[Skysnake]

DP:SP ist 1:2 bei KNL wie bei faktisch jeder CPU.

[Dawn on Titan]

Bitte was? GK104 war in Anbetracht der Größe ein ziemlich heftiger Schritt vorwärts. In fast jeder Hinsicht. Natürlich in dem Rahmen, den Ailuros erwähnt hat. Aber bei der Größe war das schon recht beachtlich.

Aus der Sicht der Endkunden war das natürlich eher mau, weil teuer verkauft und da natürlich auch deutlich mehr ging und das jeder wusste. Dennoch verkaufte sich das Teil und brachte NV sehr hohe Margen. Fragt sich nur, ob NV dieses Spielchen weiter spielen kann, wenn Ihnen jetzt sowohl von unten als auch von oben die Äste abgesägt werden.

GK104 hatte einen Prozessvorteil. Bleibt man aber in 28nm fällt der Größenvorteil schon einmal weitgehend weg und das Transistorbudget sowie das TDP-Budget bleiben praktisch unverändert. Abgesehen davon war Fermi deutlich ineffizienter als GK104, so dass auch mehr Potential da war.

[Sunrise]

GK104 hatte einen Prozessvorteil. Bleibt man aber in 28nm fällt der Größenvorteil schon einmal weitgehend weg und das Transistorbudget sowie das TDP-Budget bleiben praktisch unverändert. Abgesehen davon war Fermi deutlich ineffizienter als GK104, so dass auch mehr Potential da war.
Du hattest den Schritt von GF110 auf GK104 als mau bezeichnet, was nicht stimmt. Das mit der "Größe" bezog sich auf die relative die size. Den Rest bestreitet niemand, daher habe ich auch nur diesen einen Teil gequotet.

[Dawn on Titan]

"mau" im Sinne von dem Gewinn an Leistung gegenüber dem Topdog der Vorgängergeneration.

[Sunrise]

"mau" im Sinne von dem Gewinn an Leistung gegenüber dem Topdog der Vorgängergeneration.
GK104 ist eben auch kein Top Dog, da ist dein Denkfehler. Der wurde von NV nur so zur Überbrückung positioniert, weil es unternehmerisch Sinn ergeben hat. Und wenn du Mainstream-Performance mit High-End-Enthusiast vergleichst, dann kommen wir auch bei einer Maxwell-Einschätzung nicht weiter.

Und da du ja soviel auf den Prozess Wert legst, würde ich erstmal abwarten, ob du nicht noch eine Überraschung erlebst. Denn du musst die Bandbreite stark steigern und da gibt es derzeit starke Limitierungen. Willst du diese umgehen, musst du den Chip größer machen.

[Gaestle]

Wieso auch? Hat die GTX680 wirklich je eine GTX580 ersetzen koennen? Ja sie war um ca. 30% schneller aber ein wirklicher upgrade zum letzten wohl nicht.

So gesehen hast Du recht.

Ich hocke hier aber noch mit einer 260GTX und einem 420W-Netzteil rum, das Netzteil würde ich gerne behalten.

Deswegen interessiert mich:
Erreicht H1/2014-Maxwell in Games die Geschwindigkeit der 780Ti? Oder kann H1/2014-Maxwell in Games die 780Ti sogar schlagen (wenn auch knapp)? Und mit welchem Stromverbrauch?

[Dawn on Titan]

Wir sprechen aber gerade über die Maxwell Chips für H1/14 und keiner dieser wird der Topdog der Maxwell Serie sein. So gesehen ist es doch unbedeutend was ein GM110 leisten wird, der irgendwann Q4/14 - Q2/15 erscheinen könnte. So gesehen halte ich es für sinnig den GM104 mit dem sicherlich weiter erhältlichen GK110 zu vergleichen.
So gesehen hast Du recht.
Ich hocke hier aber noch mit einer 260GTX und einem 420W-Netzteil rum, das Netzteil würde ich gerne behalten.
Deswegen interessiert mich:
Erreicht H1/2014-Maxwell in Games die Geschwindigkeit der 780Ti? Oder kann H1/2014-Maxwell in Games die 780Ti sogar schlagen (wenn auch knapp)? Und mit welchem Stromverbrauch?

In welchem Prozess wird GM104 gefertigt? 28HP - 28HPM? Was taugt 28HPM? Deine Frage ist ohne diese Info nicht zu beantworten.

[Gaestle]

Sehe ich anders, denn einerseits hat Ail gute Quellen und andererseits versucht er Einigen hier seit geraumer Zeit begreiflich zu machen, dass der Prozess nur einer von mehreren Bausteinen ist und dass der beste Prozess gar nix nutzt, wenn das Design schlecht ist und andersrum ein gutes Design sehr viel mehr bringen kann, als ein Prozessprung.

Ail wusste AFAIR bereits sehr früh, wie schnell GK104 ungefähr werden wird, noch bevor andere Details bekannt waren.

Darüber hinaus gibt es generelle Zieldefinitionen, in welchem Leistungs- und TDP-Bereich ein Chip landen soll, noch bevor auch nur das kleinste Fitzelchen Metall von diesem Chip existiert. Dieses Zielfenster wird in der Regel auch mehr oder minder getroffen, wenn sich nicht gerade die Specs zu spät ändern, die dann in einem Laubgebläse enden. Wenn man gute Quellen hat, hat man vielleicht auch Infos, wo die anvisierten Leistungs- und TDP-Fenster liegen.

Und wenn nix schief gegangen ist, hat (wenn mich die Erinnerung nicht trügt) der Mainstram-Folgechip eines neuen Designs immer im Bereich des HighEnds vom vorangegangenen Design gelegen, aber eben oft mit kleinerem DIE und weniger Verbauch.

[Dawn on Titan]

Nur hatte man da für den Mainstreamchip eben immer einen neuen Fertigungsprozess.

[Timbaloo]

Nur werden die Probleme mit neuen Fertigungsprozessen eben auch immer größer.

[Duplex]

Nur werden die Probleme mit neuen Fertigungsprozessen eben auch immer größer.
So ein Schwachsinn, welche Probleme sollen das sein?
Wieso sieht Intel bei 10, 7 & 5nm keine Probleme?

[Timbaloo]

Wieso sieht Intel bei 10, 7 & 5nm keine Probleme?
Ich nehme an intel konzentriert sich darauf die Probleme bei 14nm zu sehen...

[Godmode]

So ein Schwachsinn, welche Probleme sollen das sein?
Wieso sieht Intel bei 10, 7 & 5nm keine Probleme?

Und was hat das jetzt genau mit NV zu tun? Fertig NV bei Intel? Nein!

Wenn es keine Probleme gäbe, dann wäre 20nm schon längst am Markt. Glaubst du TSMC verzögert das aus Spaß, oder was? :rolleyes:

[Duplex]

Neue Prozesse brauchen immer eine bestimmte Anlaufzeit, das war in der Vergangenheit nicht anders, sowas aber mit Problemen in Verbindung zu setzen halte ich für die falsche Aussage.
Man kann weiterhin alle 2 Jahre mit einem neuen Prozess rechnen, da wird sich nichts ändern und von Probleme ist aus offizieller Seite nichts zu sehen.

[Ailuros]

Und ich bezog mich nur auf das Potential dieser Chips. GK104 war ja sogar auf einem neuen Prozess im Vergleich zur 580 eher mau. GM104 zu GK104 auf dem selben Prozess könnte noch öder werden.

GK104 ist 294mm2 gross unter 28HP; bleiben sie beim gleichen Prozess koennen sie theoretisch maximal gleich doppelt so viel die area verschwenden bis es zum eingentlichen Rand des Prozesses kommt. So weit werden sie offensichtlich nicht gehen, aber da es manchen hier schwer faellt zu verstehen Tahiti und Hawaii wurden auch auf dem gleichen Prozess hergestellt und trotzdem ist der letzte um gute 30% schneller als der erste. Ja Hawaii benutzt mehr die area und?

Sonst ist GK104 heute um glatte 2x Mal so schnell als ein GF114 und das liegt innerhalb genau der Erwartungen einer neuen Generation.

Laut dem von dir gefundenen Spekulations-Heureka (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9946140&postcount=557) wäre es sogar nur 4:1. Zwei FP64 ALUs pro SMX für 2:1?

Kein Kommentar :freak::freak::freak:

So ein Schwachsinn, welche Probleme sollen das sein?
Wieso sieht Intel bei 10, 7 & 5nm keine Probleme?

Ich muss langsam doch annehmen dass Du nicht auf Mutter Erde stationiert bist. Und nein ich dreh jetzt die Debatte nicht in die Richtung, google selber nach was mit Herstellungsprozessen in letzter Zeit los ist, wieso die Zeitspannen und Herstellungskosten konstant wachsen.

Neue Prozesse brauchen immer eine bestimmte Anlaufzeit, das war in der Vergangenheit nicht anders, sowas aber mit Problemen in Verbindung zu setzen halte ich für die falsche Aussage.
Man kann weiterhin alle 2 Jahre mit einem neuen Prozess rechnen, da wird sich nichts ändern und von Probleme ist aus offizieller Seite nichts zu sehen.

Wenn NV die gleiche Masche anlegt mit top dog Maxwell wie GK110 ist der Abstand zwischen den beiden groesser als 2 Jahre und es wird auch zunehmend laenger werden. AMD hat vor einiger Zeit angekuendigt dass sie dank zunehmender Prozess-Problematik laenger auf dem gleichen Prozess herstellen werden. Ist aber alles nur ein Zufall ja?

[Timbaloo]

Kein Kommentar :freak::freak::freak:
Ist das so schwachsinnig?