nVidia - Pascal - GP100 - 2016 - 3D-Memory HBM, NVLINK, Mixed Precision [Archiv] - Seite 23

Sunrise

2016-05-13, 15:55:59

...Deshalb sind die connections von NVIDIA zu Projekten auch so extrem wichtig.
Und man muss bei Ausschreibungen immer möglichst ans Limit gehen, damit man Klotzen statt Kleckern kann, was NV jetzt mit GP100/P100 ja gemacht hat. Ein Chip für alles wäre nicht so performant geworden, zudem wären die Features ohne NVLink usw. undenkbar, da die Konkurrenz zuviele Vorteile gehabt hätte.

Wenn NV das aber wusste, dann müssen sie meiner Meinung nach mit einem Chip über GP104 geplant haben. Dass die Erwartungshaltung von NV ist, dass AMD mit Vega keine höhere Performance liefern kann, finde ich etwas eigenartig, denn wir reden von einem 300mm² Die.

Das ist auch der Grund, warum ich an GP102 nach wie vor glaube, aber lediglich ein Treibereintrag sagt uns erstmal nicht sehr viel.

Es sei denn NV ist wirklich so aggressiv, dass GV104 schon nächstes Jahr kommt, auch wieder nur 300mm². Andere Erklärungen finde ich nicht.

Hübie

2016-05-13, 15:58:49

Na es ist zugeben schon sehr subjektiv beeinflusst wer mit wem etc. Wenn ein renommierter Prof wechselt gehen Auftraggeber oft mit. =) Aber genug der insights Thema ist Pascal.

Godmode

2016-05-14, 07:18:18

1080/1070 Beiträge habe ich in die entsprechenden Threads verschoben:

GTX 1070 (P)Review Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11029022)
GTX 1080 (P)Review Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=572958)

Nakai

2016-05-14, 16:45:15

scully1234

2016-05-14, 17:15:05

Tom darf also nach dem Debakel weitere Live Streams betreten alles gut Lederjacke hat ihn nicht gefeuert :biggrin:

Jetzt sitzt Jensen hinter der Buehne und versaut die Slides:P

http://www.pcper.com/news/General-Tech/PCPer-Live-GeForce-GTX-1080-Live-Stream-Tom-Petersen

Ich hoffe das gehoert hier hin Goodmode oder alles prinzipiell in den 1080er Thread?

AnarchX

2016-05-14, 17:33:56

https://compubench.com/device.jsp?benchmark=compu15d&os=Windows&api=cl&D=NVIDIA+GeForce+GTX+1080&testgroup=info

CL_DEVICE_MAX_COMPUTE_UNITS 20

128 SPs pro SM

Das sind eher Maxwell-SMs. Nur GP100 wird solche Compute-artigen SMs besitzen, um mehr Cache und Register zu liefern. ;)
Mal sehen ob Mixed-Precision noch an Board ist.

Vielleicht ist GP106 mit seinen 256-Bit auch für den Profi-Markt designt, wenn er Half-Rate-DP hätte, könnte er mit >2 TFLOPs hier so manche GK110/210-Karte ersetzen.

Nakai

2016-05-14, 18:29:36

Mal sehen ob Mixed-Precision noch an Board ist.

Vielleicht ist GP106 mit seinen 256-Bit auch für den Profi-Markt designt, wenn er Half-Rate-DP hätte, könnte er mit >2 TFLOPs hier so manche GK110/210-Karte ersetzen.

Hat GP106 wirklich ein 256Bit SI? Ja, das MXM-Modul in diesem Formfaktor gibt das eigentlich vor, aber es könnte ja ein 128 => 256Bit sein.

Ansonsten eher ein 256Bit SI nur GDDR5 und LowClocks. Dann erreicht man auch größere Speichervolumen.

scully1234

2016-05-14, 21:05:39

Hat GP106 wirklich ein 256Bit SI? .

Was spart denn in Relation gesehen mehr Strom ein, das kleinere SI,oder relativ niedrig taktender Vram?

Oder geht's sich das aus, und man erhoeht nur Kosten durch das groessere SI?

Hübie

2016-05-14, 21:23:19

Wenn du nur Verbrauch meinst dann natürlich ein kleines SI. Was nicht da ist kann nix verbrauchen. In Relation zur Performance ist es dann wieder schwieriger zu beziffern. Spannung geht quadratisch ein und Takt linear. Wenn man den Takt also soweit senkt dass die Performance weniger einbricht als Spannung dann ist das natürlich ein Traum. :D

scully1234

2016-05-14, 22:41:28

Wenn du nur Verbrauch meinst dann natürlich ein kleines SI. :D

Also gäbe aus Ersparnisgründen im Notebook ,keinen ersichtlichen Grund breiter zu bauen, dafuer aber den Speichertakt drastisch zu senken :smile:

Hübie

2016-05-14, 23:15:07

Würde ich pauschal so sagen, ja. Man muss nur im Hinterkopf behalten, daß alles einen Preis hat. Damit meine ich natürlich nicht nur monetär.

Undertaker

2016-05-15, 09:46:53

Also gäbe aus Ersparnisgründen im Notebook ,keinen ersichtlichen Grund breiter zu bauen, dafuer aber den Speichertakt drastisch zu senken :smile:

Imo geht diese Rechnung sogar so eindeutig für das breitere SI aus. Wenn eine 256 Bit Variante vielleicht 20 - 25 Prozent weniger Speicher- und Chiptakt* für die gleiche Performance wie das 128 Bit Modell braucht, macht das auch dank niedrigerer Spannungen mit hoher Wahrscheinlichkeit den Mehrverbrauch durch das SI mehr als wett. Letztlich sprechen ausschließlich die Herstellungskosten dagegen.

* Es gibt diverse Mobile-Modelle, wo AMD und Nvidia eine sehr viel geringere Bandbreite (meist durch DDR3 statt GDDR5) durch einen höheren Chiptakt zu kompensieren versuchen. Davon abgeschätzt die genannten Prozentangaben.

HOT

2016-05-15, 10:04:12

Selbst wenn es ein paar weniger ALUs waeren, GP100 laeuft nur mit <1500 und kratzt schon an den 300 Watt. GP102 koennte mit hoeherem Takt die paar ALUs ausgleichen und rankommen. Diese Aufstellung ergibt so fuer mich keinen Sinn
Das ist ein guter Punkt. Wenn man etwas hin und herrechnet, kommt man auf den Stromverbrauch als limitierenden Faktor, nicht die Chipgröße. Nehmen wir GP104, der verbrät 180W bei 1,7GHz. GP102 soll sicherlich in ähnliche Gefielde reichen, dann würde man wohl kaum über 270W TDP hinausgehen wollen, also genau 50% mehr. Also würde man NVs Stelle wohl einen Chip bauen, der die Taktraten ebenfalls schafft (aber wohl nicht über 250W hinausgeht) und genau 50% auf GP104 draufknallen, also genau wie schon bei Maxwell passiert. Also hat GP102 mit tödlicher Sicherheit die gleiche Shaderzahl wie GP100, 3840 Shader, um das thermische Budget nicht zu spengen. Nimmt man die 22,7 Mio Transistoren pro mm² des GP104 als Referenz (also diesmal mit 384Bit GDDR5X), dann würde man bei 10,8 Mia Transistoren landen und 475mm². Dafür lohnt sich defintiv ein eigener Chip mAn, das sind schlappe 125mm² weniger als GP100 hat, bei besserer Taktbarkeit. Damit hätte GP102 exakt 50% mehr Power als GP104.

scully1234

2016-05-15, 10:44:32

macht das auch dank niedrigerer Spannungen mit hoher Wahrscheinlichkeit den Mehrverbrauch durch das SI mehr als wett. Letztlich sprechen ausschließlich die Herstellungskosten dagegen.

.

Mmh jetzt haben wir hier zwei gegenlaeufige Meinungen, in deinem Szenario wuerde es noch Sinn ergeben, falls Nvidia den Fokus auf Effizenz legt ,das SI bei GP106 so aufzupumpen wie vermutet wird

In Huebies Szenario waeren beide Faelle unguenstig:smile:

Undertaker

2016-05-15, 10:58:58

Das ist ein guter Punkt. Wenn man etwas hin und herrechnet, kommt man auf den Stromverbrauch als limitierenden Faktor, nicht die Chipgröße. Nehmen wir GP104, der verbrät 180W bei 1,7GHz. GP102 soll sicherlich in ähnliche Gefielde reichen, dann würde man wohl kaum über 270W TDP hinausgehen wollen, also genau 50% mehr. Also würde man NVs Stelle wohl einen Chip bauen, der die Taktraten ebenfalls schafft (aber wohl nicht über 250W hinausgeht) und genau 50% auf GP104 draufknallen, also genau wie schon bei Maxwell passiert. Also hat GP102 mit tödlicher Sicherheit die gleiche Shaderzahl wie GP100, 3840 Shader, um das thermische Budget nicht zu spengen. Nimmt man die 22,7 Mio Transistoren pro mm² des GP104 als Referenz (also diesmal mit 384Bit GDDR5X), dann würde man bei 10,8 Mia Transistoren landen und 475mm². Dafür lohnt sich defintiv ein eigener Chip mAn, das sind schlappe 125mm² weniger als GP100 hat, bei besserer Taktbarkeit. Damit hätte GP102 exakt 50% mehr Power als GP104.

Speziell die TDP kann man definitiv nicht so abschätzen, da kommen viel zu hohe Werte heraus. Schauen wir mal auf Maxwell: Die GTX 960 / GM206 ist fast exakt eine halbe GTX 980 / GM204, sogar die Referenztaktraten sind äußerst ähnlich. Und wie verhalten sich da TDP und Chipdaten?

TDP: 120 vs. 165W (+37,5%)
Fläche: 227 vs. 398 mm² (+75%)
Transistoren: 2,94 vs. 5,2 Mrd. (+77%)

Edit: GM206 hat physisch keine 192 Bit, gesichert?

Ich sehe einen GP102 mit 3.840 ALUs und 384 Bit GDDR5X bei <450 mm² und <230 Watt bei Taktraten auf GP104 Niveau, ohne das ich das genauere Werte vorhersagen wöllte. Vom Verbrauch würden in einem Rahmen bis 250 Watt sogar noch einige ALUs mehr hinein passen.

fondness

2016-05-15, 11:10:04

Wieder mal sehr einseitiger Vergleich, der wesentlich passendere wäre wohl GM204 vs. GM200:

TDP: 165 vs. 250W (+51,5%)
Fläche: 398 vs. 601 mm² (+51%)
Transistoren: 5,2 vs. 8,1 Mrd. (+55,8%)

Und dabei sind die Taktraten bei GM200 sogar niedriger.

Undertaker

2016-05-15, 11:43:56

scully1234

2016-05-15, 11:47:43

(kann GM200 eigentlich ECC?) .

M6000 sicherlich

Godmode

2016-05-15, 12:22:18

iuno

2016-05-15, 12:43:58

Ein Chip für alles wäre nicht so performant geworden, zudem wären die Features ohne NVLink usw. undenkbar, da die Konkurrenz zuviele Vorteile gehabt hätte.
Und weil GP100 zusaetzliche Features in einer Richtung bekommen hat (z.B. NVLinks) ist er ploetzlich kein Chip mehr "fuer alles"?
Wie erklaerst du dir dann, dass der ganze "Ballast" fuer 3D nicht aus GP100 rausgeflogen ist?
Also hat GP102 mit tödlicher Sicherheit die gleiche Shaderzahl wie GP100, 3840 Shader, um das thermische Budget nicht zu spengen. Nimmt man die 22,7 Mio Transistoren pro mm² des GP104 als Referenz (also diesmal mit 384Bit GDDR5X), dann würde man bei 10,8 Mia Transistoren landen und 475mm².
Ich bin da immer noch skeptisch, wenn GP102 so kommt, wuerde er theoretisch auch fuer machine learning deutlich mehr Leistung bringen, worauf GP100 ja schon komplett abzielt. Freilich ohne NVLinks und die Moeglichkeit, derartige Meshes zu bauen aber etwas komisch bleibt das schon.
384 Bit G5X waeren imho auch eine traurige "Einsparung" ggue. 4096 Bit HBM. Bei AMD war ein 1024 Bit HBM MC nur minimal groesser als ein 64 Bit GDDR5 MC. Unter der Annahme, Nvidias MCs seien etwas groesser, da sie immer deutlich hoehere Takte machen (und 5X noch dazu kommt) und ein HBM MC fuer >1 Gbps sei nicht oder nur minimal groesser, da pad-limitiert, wuerde das G5X SI sogar 50% mehr Platz brauchen.
Zumal man dann auf der Titan wieder nur 12 GiB verbauen kann, wenn man nicht gleich wieder auf 24 verdoppeln will.

Hübie

2016-05-15, 12:58:23

Es ist ja nicht so dass GP100 nie Grafik berechnen müsste ;) Man braucht natürlich für compute keine TMU, ROPs oder alle shaderstages, aber man macht nicht immer nur Berechnungen rein numerischer Natur (Ausgabe) sondern auch grafische Simulationen.

fondness

2016-05-15, 13:28:55

Es ist eine gute Frage, warum GM200 auch ohne FP64 gegenüber GM204 so "fett" geworden ist, wo doch eine ALU-Verdopplung von GM206 ausgehend gerade einmal 75% mehr Transistoren und 38% mehr TDP benötigt. Bei einem reinen Gaming Top-Dog a'la GP102 ohne jedweden Ballast (kann GM200 eigentlich ECC?) ist die Relation GM206<->GM204 wohl die realistischere.

Es ist eher eine gute Frage, warum GM206 so fett ist, der stark verbesserte Videoprozessor ist da sicher eine mögliche Erklärung. Und ein, 38% mehr TDP ist mit Sicherheit NICHT realistisch für eine Verdoppelung, aber das weißt du hoffentlich auch selbst wenn du deine grüne Brille absetzt. ECC kann im übrigen natürlich auch GM204, wird ja auch bei diverse Tesla-Produkten verbaut.

AnarchX

2016-05-15, 13:39:20

Bei GM206 weiß man nicht ob da nicht ein ungenutztes 192-bit SI ist.

victore99

2016-05-15, 13:51:37

Bei GM206 weiß man nicht ob da nicht ein ungenutztes 192-bit SI ist.

Wird nicht sein. Allein schon wegen der Logik:
Es ist sehr viel einfacher und effizienter, einen Grundchip zu designen und danach den mit nur minimalen Veränderungen zu verdoppeln, als jeden Chip einzeln mit dem Baukasten zusammenzupuzzeln.
Desweiteren sagt die TDP nichts aus. Keine Fury x unter vollast braucht nur 275W, keine vernünftige 980Ti (z.b. Palit Super Jet) hält sich an die TDP. Selbiges bei den 980ern.
Da die 960er aber vom Boost leben MUSS (um gegen die bei Veröffentlichung schon leicht schnellere 280X wenigstens bei der HD-Performance nicht komplett abzukratzen), braucht sie ergo eine leicht überhöhte TDP, damit der GPU-Boost da mitspielt.
Und ja, natürlich haben die Multimediaeinheiten eine Gewisse Chipfläche etc zu verantwoten, die aber meist Brachliegt und nicht genutzt wird.

Undertaker

2016-05-15, 13:52:52

Es ist eher eine gute Frage, warum GM206 so fett ist, der stark verbesserte Videoprozessor ist da sicher eine mögliche Erklärung. Und ein, 38% mehr TDP ist mit Sicherheit NICHT realistisch für eine Verdoppelung, aber das weißt du hoffentlich auch selbst wenn du deine grüne Brille absetzt. ECC kann im übrigen natürlich auch GM204, wird ja auch bei diverse Tesla-Produkten verbaut.

Das >50% mehr TDP/Transistoren/Fläche für einen ansonsten unveränderten Chip mit 50% mehr ALUs/SI ebenso unrealistisch sind, erkennst du sicher unter deiner roten Brille. :) Insofern sind entsprechende Prognosen wenig zielführend.

fondness

2016-05-15, 13:59:16

Das >50% mehr TDP/Transistoren/Fläche für einen ansonsten unveränderten Chip mit 50% mehr ALUs/SI ebenso unrealistisch sind, erkennst du sicher unter deiner roten Brille. :) Insofern sind entsprechende Prognosen wenig zielführend.

Es sind fast exakt 50%. Die minimal mehr kann man sicher mit diversen Kleinigkeiten wie mehr Threads/Interconnections/Redundanz/etc erklären. Im übrigen warst du es, der ernsthaft GM206 vs. GM204 als Beispiel nannte für GP104 vs. GP102. Ich habe das andere Beispiel nur gebracht, um deine offensichtlich unzureichende Argumentation aufzuzeigen.

Undertaker

2016-05-15, 14:08:08

HOT

2016-05-15, 14:11:14

Speziell die TDP kann man definitiv nicht so abschätzen, da kommen viel zu hohe Werte heraus. Schauen wir mal auf Maxwell: Die GTX 960 / GM206 ist fast exakt eine halbe GTX 980 / GM204, sogar die Referenztaktraten sind äußerst ähnlich. Und wie verhalten sich da TDP und Chipdaten?

TDP: 120 vs. 165W (+37,5%)
Fläche: 227 vs. 398 mm² (+75%)
Transistoren: 2,94 vs. 5,2 Mrd. (+77%)

Und da hat GM206 sogar die mächtigere Videoeinheit.

Ich sehe einen GP102 mit 3.840 ALUs und 384 Bit GDDR5X bei <450 mm² und <230 Watt bei Taktraten auf GP104 Niveau, ohne das ich das genauere Werte vorhersagen wöllte. Vom Verbrauch würden in einem Rahmen bis 250 Watt sogar noch einige ALUs mehr hinein passen.

GM206 kann man nicht vergleichen, das ist totaler Unsinn. a.) ist der Chip etwas moderner und bringt mehr Funktionen als GM204 und GM200, b.) hast du dir mal ne GM206-Karte angeschaut? der Chip an sich hat gar kein 128Bit Interface, 64Bit sind anscheinend nur nicht verdrahtet. Beispielbild:
http://www.bit-tech.net/hardware/graphics/2015/01/22/nvidia-geforce-gtx-960-review-feat-asus/3
Wär gut, wenn jemand mal einen Die-Plot finden würde, da könnte man das endlich mal nachweisen.
Und je kleiner der Chip ist, desto mehr fallen Dinge ins Gewicht, die sowieso jeder Grafikchip mitbringt.

GM204
400mm²
5,2Mia Transistoren
256Bit 7Gbps
TDP 165W bei ca. 1,2GHz

GM200
600mm² (fast exakt 50% mehr)
8Mia Transistoren (fast exakt 50% mehr)
384Bit 7Gbps (exakt 50% mehr)
TDP 250 bei 1,07GHz sind auch 50% mehr

Die kann man vergleichen und da ist es absolut klar.

Undertaker

2016-05-15, 14:13:07

GM206 kann man nicht vergleichen.

Natürlich kann man das. Bei GM200 könnte ich mir noch erhöhte Redundanzen für das überproportionale Wachstum vorstellen. Aber das sollte im Maxwell-Thread weiter erörtert werden.

Wer mag Wetten für GP102 abgeben, was Größen- zu ALU-Wachstum angeht? ;)

Hübie

2016-05-15, 14:21:13

Ich wette den gibt's gar nicht bzw. der wirds nie auf den Markt schaffen. :D

fondness

2016-05-15, 16:08:19

Unzureichend ist deine Andeutung, die von Werten >50% sprach. Über ein ">" oder "=" brauchen wir uns nicht streiten, bei einem ansonsten unveränderten Chip wird aufgrund nicht in gleichem Maße mitwachsender Teile immer ein "<" herauskommen.

GM200 vs. GM204 ist der offensichtliche Beweis, dass das nicht immer so sein muss. Insofern ist deine Aussage schon widerlegt. Gründe dafür habe ich genannt, das mit der Redundanz hast du ja schon übernommen. Der "2D-Teil" wird in Relation zum restlichen Chip auch immer kleiner, daher hat man zwar keine exakt lineare Skalierung, man nähert sich dieser aber mit jedem Shrink immer weiter an. Gerade bei sehr großen Chips kann man da schon grob von annähernd linearer Skalierung sprechen, wenn wirklich alle Einheiten wie ALUs/TMUs/ROPs/SI/etc linear skaliert werden. Bei Lowend-Chips sieht das natürlich anders aus.

Hübie

2016-05-15, 16:18:18

Solang wir über eine Gen reden stimmt das. Mit Iterationen stimmt es begrenzt und mit neuer Arch ists dann wiederum unstimmig. Aber wovon redet ihr zwei seit gefühlt zwei Seiten eigentlich? :|

MorPheuZ

2016-05-15, 21:18:21

Ich wette den gibt's gar nicht bzw. der wirds nie auf den Markt schaffen. :D

Oder gar nicht nötig...

Locuza

2016-05-15, 21:58:42

Die Slides sind geleaked:
http://videocardz.com/59962/nvidia-geforce-gtx-1080-final-specifications-and-launch-presentation

Einer der interessantesten Punkte:
1. Tatsächlich 128 ALUs per Cluster wie bei Maxwell und nicht 64 wie beim großen GP100.
2. Graphics-Preemption auf Pixel-Level und Compute Preemption auf Instruction-Level + Dynamic Load Balancing, womit die idle-times extrem verkürzt werden.
3. 4th Generation Memory-Compression, je nach Spiel 11-28% effizienter als noch bei Maxwell.

Hut ab Nvidia, für einen Zwischenschieber gibt es reichlich Verbesserungen.

fondness

2016-05-15, 22:03:30

Warum Zwischenschieber? NV bringt eigentlich relativ regelmäßig alle zwei Jahre eine mehr oder weniger neue Arch. Seit Maxwell sind es sogar etwas mehr als zwei Jahre.

Troyan

2016-05-15, 22:06:54

Einer der interessantesten Punkte:
1. Tatsächlich 128 ALUs per Cluster wie bei Maxwell und nicht 64 wie beim großen GP100.

Ich habe beide Slides verglichen - also GP104 und GP100. Ich sehe ehrlich kein Unterschied...

Sunrise

2016-05-15, 22:08:35

Die Slides sind geleaked:
http://videocardz.com/59962/nvidia-geforce-gtx-1080-final-specifications-and-launch-presentation
Beeindruckend, der VP wurde nun sogar um 12bit HEVC-Decode erweitert, ebenso 8K-Support bis 30Hz. Maximale Bitrate liegt jetzt bei 320Mbps! in Echtzeit. Damit übertrifft NV teilweise sogar professionelle Broadcast-Decoder.

Es ist eher eine gute Frage, warum GM206 so fett ist, der stark verbesserte Videoprozessor ist da sicher eine mögliche Erklärung...
Nein, ganz sicher nicht, da die VP-IP schon immer winzig war, das sind maximal 2-5mm^2 auf 28nm. Das spielt bei den anderen Größen bei einer GPU wie GM206 überhaupt keine Rolle. Erst recht, weil durch die Jahre genau dieser Teil (weil er statisch ist) extrem gut mit den besseren Prozessen shrinkbar ist. Die durchgehende 10bit-Fähigkeit, inkl. HEVC und HDCP 2.2 sind selbst in Winzig-China-SoCs mittlerweile vorhanden und spielen da noch weniger eine Rolle. Und da der VP nur leicht erweitert wurde, ergibt das noch weniger Sinn.

GPUs sind einfach so groß wie sie sind, weil entweder das Design, das Layout oder hohe Taktziele das erfordern. Und das sind nur ein paar Beispiele von vielen.

reaperrr

2016-05-15, 22:22:37

Es ist eher eine gute Frage, warum GM206 so fett ist, der stark verbesserte Videoprozessor ist da sicher eine mögliche Erklärung.
Warum fett? ist doch nur 28mm² größer als ein exakt halbierter GM204. In den 28mm² steckt halt alles, was nicht halbiert werden kann (PCIe-Anbindungen, Display-Controller, eben Video-Engine, wahrscheinlich auch Nvidia's Gegenstück zum Command Processor).

Cape Verde war auch 123mm² zu Pitcairn's 212mm², und das lag auch nicht nur am gleich-großen L2.

Locuza

2016-05-15, 22:26:40

Ich habe beide Slides verglichen - also GP104 und GP100. Ich sehe ehrlich kein Unterschied...
GP104:
http://cdn.videocardz.com/1/2016/05/NVIDIA-GeForce-GTX-1080-Simultaneous-Multi-Projection.jpg

GP100:
http://www.techpowerup.com/img/16-04-12/30b.jpg

Das Register-File ist wie bei Maxwell nur noch halb so groß pro SM.

Hier die ganze Overview:
GP100:
http://media.gamersnexus.net/images/media/2016/features/pascal/gp100-pascal-block-diagram.jpg

GP104:
http://cdn.videocardz.com/1/2016/05/NVIDIA-GP104-Block-Diagram.jpg

Hier muss man auf die hellblauen Striche bei den Clustern achten die, die Caches darstellen.
Beim GP100 gibt es immer diese blaue Milchschnitte, wo die L1/Texture Caches über den dunkelblauen Tex eingezeichnet werden und der 64KB große shared-memory immer darunter.

Beim GP104 gibt es diese Milchschnitte nur einmal, nämlich bei den unteren Clustern. Das heißt einfach das sich die 128 ALUs den shared-memory teilen müssen und nicht jeder Cluster seinen eigenen hat.
Es ist einfach wie bei Maxwell aufgebaut, wobei Maxwell v2 einen 96KB großen shared-memory hatte an der Stelle.
Keine Ahnung welche Größe der shared-memory beim GP104 hat.

Edit: Noch offensichtlicher sieht man das natürlich oben am Instruction-Cache. Den gibt es beim GP104 nur einmal pro 128-ALUs, beim GP100 zwei mal neben dem oben genannten shared-memory + doppelte Register-Größte pro SM.

Troyan

2016-05-15, 22:32:13

Ah, ich sehe es jetzt. Danke.

Locuza

2016-05-15, 22:39:13

Warum Zwischenschieber? NV bringt eigentlich relativ regelmäßig alle zwei Jahre eine mehr oder weniger neue Arch. Seit Maxwell sind es sogar etwas mehr als zwei Jahre.
Anfangs gab es auf den Roadmaps gar kein Pascal, nach Maxwell wurde direkt Volta eingezeichnet.

Beeindruckend, der VP wurde nun sogar um 12bit HEVC-Decode erweitert, ebenso 8K-Support bis 30Hz. Maximale Bitrate liegt jetzt bei 320Mbps! in Echtzeit. Damit übertrifft NV teilweise sogar professionelle Broadcast-Decoder.

Das fand ich auch beeindruckend, HEVC 10-Bit Encode und sogar 12-Bit Decode.
VP9 wird auch decodiert.
Ich glaube hier wird AMD mit Polaris schwächer dastehen, die haben glaube ich bisher noch gar keine Schaltungen bezüglich des VP-Standards und beim HEVC stand nur 10-Bit Decode, bei Encode hat man die Bits nicht hingeschrieben, was ich mal sparsam als 8-Bit Support deute.
http://cdn.wccftech.com/wp-content/uploads/2016/01/AMD-Polaris-5.jpg

AMD kann natürlich noch positiv überraschen, aber bei AMD bin ich genau gegenteiliges gewohnt...

illidan

2016-05-15, 22:45:10

Das fand ich auch beeindruckend, HEVC 10-Bit Encode und sogar 12-Bit Decode.

In wie weit man 12 Bit jemals antreffen wird, muss sich erst noch zeigen.
UHD BD ist 10 Bit und bei Streaming scheint HEVC keine Zukunft zu haben, bis März soll AV1 fertig sein.

VP9 wird auch decodiert.

Konnte auch schon die 960.

Ich glaube hier wird AMD mit Polaris schwächer dastehen, die haben glaube ich bisher noch gar keine Schaltungen bezüglich des VP-Standards

Hoffen wir mal, dass das bisher nur nicht kommuniziert wurde. Wirkliche Anhaltspunkte dafür oder dagegen gibt es nicht.

edit: *snip*

herp_derp

2016-05-15, 23:05:44

Hm, zu Asynchronous Compute steht nicht viel aufschlussreiches drin.

illidan

2016-05-15, 23:07:52

Ist denn nicht eh nur interessant, wie sich die Leistung mit an/aus bei Ashes verändert? :D

scully1234

2016-05-15, 23:15:59

Hm, zu Asynchronous Compute steht nicht viel aufschlussreiches drin.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11033543&postcount=5534 :wink:

Ist doch voellig Hupe wie es umgesetzt wird ,wenns funktioniert dann funktionierts

Das ist der Ansatz den Nvidia gewaehlt hat

Sunrise

2016-05-15, 23:45:52

In wie weit man 12 Bit jemals antreffen wird, muss sich erst noch zeigen.
UHD BD ist 10 Bit und bei Streaming scheint HEVC keine Zukunft zu haben, bis März soll AV1 fertig sein.
Es schadet ja nicht, weil HEVC wird so schnell nicht wegzudenken sein. Es ist zwar schön, dass es bald eine Alternative geben wird, aber das ist ja noch Zukunftsmusik und aktuell lassen sich eben bereits sowohl professionelle Offline-Transcoder mit 12bit 4:4:4 Chroma Subsampling-Fähigkeit kaufen, und auch x265 hat diese Option, d.h. NV kann diese bereits jetzt dekodieren. Nach Pascal wird NV sicher auch AV1 berücksichtigen, aber dafür ist es noch viel zu früh.

Pascal ist schon ziemlich gut, für das was erwartet wurde. Nochmal eine deutliche Aufwertung auf Maxwell, selbst GM206 wird mit GP104 geschlagen, in der Vergangenheit hatte immer der G***6er Chip die bessere Video-IP, das scheint nun der Vergangenheit anzugehören

Bei AMD ist man da ins Hintertreffen geraten und NV bemüht sich, weiter an der Spitze zu bleiben. Bei AMD wird man wohl auch mit Polaris wieder einen Schritt hintendrin sein, nach allem was AMD bisher zu den Video-Fähigkeiten preisgab.

illidan

2016-05-16, 00:02:16

und aktuell lassen sich eben bereits sowohl professionelle Offline-Transcoder mit 12bit 4:4:4 Chroma Subsampling-Fähigkeit kaufen, und auch x265 hat diese Option, d.h. NV kann diese bereits jetzt dekodieren.

Es ist aber trotzdem nur ein Checklistenfeature auf dem Papier, wenn es keinen Content gibt.
Kein Chroma Subsampling wär schön für Spiele-Aufzeichnungen, davon ist aber nichts gesagt worden.

selbst GM206 wird mit GP104 geschlagen, in der Vergangenheit hatte immer der G***6er Chip die bessere Video-IP, das scheint nun der Vergangenheit anzugehören

Das ist schon länger nicht mehr so. Alle Keplers hatten afaik die gleiche VPU, ein Update gabs erst mit Maxwell 1.0.

Bei AMD ist man da ins Hintertreffen geraten und NV bemüht sich, weiter an der Spitze zu bleiben. Bei AMD wird man wohl auch mit Polaris wieder einen Schritt hintendrin sein, nach allem was AMD bisher zu den Video-Fähigkeiten preisgab.
Wenn es so wäre, wär es bitter (und peinlich).

Sunrise

2016-05-16, 00:22:19

Es ist aber trotzdem nur ein Checklistenfeature auf dem Papier, wenn es keinen Content gibt.
Kein Chroma Subsampling wär schön für Spiele-Aufzeichnungen, davon ist aber nichts gesagt worden.
Nochmal: Es gibt Hardware-Transcoder (z.B. von BBright) dafür, also benötigt man einen Decoder. x265 kann es auch, das bedeutet, dass ich jetzt etwas in 12bit 4:4:4 encoden kann, und mit GP104 kann ich es decoden. Es interessiert weder mich noch NV, ob es dafür Consumer-Content gibt, denn es gibt im professionellen Bereich schon länger 12bit 4:4:4, weil das auch Masteringstudios (inkl. Dolby Visions Referenzmonitor) nutzen. Im Semi-professionellen Bereich gibt es x265, den kann ich auch nutzen. Wichtig ist, dass NV dieses unterstützt und hier ein Vorreiter ist, der Kunden diese Möglichkeit gibt. Es ist also kein Checklistenfeature, sondern nutzbar. Ebenso der 10bit Encoder, der ist auch nutzbar und sinnvoll.

Das ist schon länger nicht mehr so. Alle Keplers hatten afaik die gleiche VPU, ein Update gabs erst mit Maxwell 1.0.
GM206 hatte den besseren. ;)

Wenn es so wäre, wär es bitter (und peinlich).
Ach plötzlich! Ich dachte es sind nur Checklistenfeatures? ;)

illidan

2016-05-16, 00:31:56

Nochmal: Es gibt Hardware-Transcoder (z.B. von BBright) dafür, also benötigt man einen Decoder. x265 kann es auch, das bedeutet, dass ich jetzt etwas in 12bit 4:4:4 encoden kann, und mit GP104 kann ich es decoden. Es interessiert weder mich noch NV, ob es dafür Consumer-Content gibt, denn es gibt im professionellen Bereich schon länger 12bit 4:4:4, weil das auch Masteringstudios (inkl. Dolby Visions Referenzmonitor) nutzen.

Wieso sollte der professionelle Bereich an FF Encodern mit zweifelhafter Flexibilität interessiert sein?
Was will man in 12 Bit mit lossy Konvertierungen?
Edit: Dass 12 Bit lossless Decoding Support gegeben ist, ist auch gar nicht gesagt.

Ebenso der 10bit Encoder, der ist auch nutzbar und sinnvoll.

Das hab ich auch nicht bestritten...

Doch, das ist schon länger so. GK106 hatte den besseren, GM206 hatte den besseren. ;)

Wo steht das? Laut Wiki liegst du falsch und ich richtig:
https://en.wikipedia.org/wiki/Nvidia_PureVideo#The_fifth_generation_PureVideo_HD

Ach plötzlich! Ich dachte es sind nur Checklistenfeatures? ;)
12 Bit Support ist ein Checklistenfeature, VP9-Support nicht.

Kartenlehrling

2016-05-16, 00:38:07

Für Dolby Visions muss aber auch ein dongle-chip beim Monitor/TV und beim Mainboard/Grafikkarte verbaut sein, glaube nicht das einer beim gtx1080 dabei ist.
Die Film und Medienindustrie macht sich jetzt schon in der Hose, das ihr Kopierschutz geknackt ist bevor die Geräte im Laden stehen.

Sunrise

2016-05-16, 00:59:01

Wieso sollte der professionelle Bereich an FF Encodern mit zweifelhafter Flexibilität interessiert sein?
Was will man in 12 Bit mit lossy Konvertierungen?
Seit wann arbeitet man im professionellen Bereich immer mit lossless-Daten? Die CinemaCraft-Encoder, Apple ProRes oder diverse andere Master-Formate sind alle nicht verlustfrei. Cineform kann 12bit, wenn du das Live transkodierst in HEVC 12bit 4:4:4 brauchst du einen Decoder. x265 kann 12bit lossless 4:4:4 enkodieren, zudem gibt es die entsprechenden 12bit Hardware-Encoder, dafür brauchst du immer auch einen 12bit Decoder.

Und seit wann arbeitet man im professionellen Bereich immer mit Flexibilität bei den Encodern? Da werden einfach oft Presets genutzt und fertig ist die Sache. Nicht jeder optimiert Szene für Szene, sowas geht vielleicht wenn du Zeit hast, aber nicht wenn du schnell ein gutes Ergebnis willst.

Wo steht das? Laut Wiki liegst du falsch und ich richtig:
https://en.wikipedia.org/wiki/Nvidia_PureVideo#The_fifth_generation_PureVideo_HD
Siehe meinen Edit, es gab aber auch bei den maximalen Bitraten vorher Unterschiede, die Wikipedia nicht aufführt, trotz scheinbar identischem VP. Ich weiß das, weil Doom9 das regelmäßig und zuverlässig testet. Du kannst dir das auch gerne im entsprechenden Forum durchlesen, ist kein Geheimnis. Da nur den VP bei Wiki anzugeben, ist Quatsch, da fehlt die Hälfte.

12 Bit Support ist ein Checklistenfeature, VP9-Support nicht.
Dann haben wir wohl unterschiedliche Betrachtungsweisen von Checklistenfeatures. Checklistenfeatures sind bei mir Features, die sowieso jeder einbaut, eben für die Checkliste, weil das dazugehört. Ich sehe aber weit und breit niemanden, der 10bit Live-Encoder im PC-Bereich anbietet, 12bit Decoder und auch noch 8K-Decoding. Und ich wette mit dir, dass AMD das auch nicht bieten wird.

4K ist bei deiner Definition auch ein Checklistenfeature oder? Wird doch nur auf der Ultra HD Blu-ray genutzt. Auch DX12 wäre nach deiner Definition ein Checklistenfeature, es nutzt ja kaum einer! Ja, jetzt vielleicht, aber wenn du die Möglichkeit nicht anbietest, dann wird es auch nie jemand nutzen, du verstehst das Problem?

illidan

2016-05-16, 01:19:44

Seit wann arbeitet man im professionellen Bereich immer mit lossless-Daten?

12 Bit ist kein Endkundenformat. Das nutzt man wenn dann, wenn man Qualitätsverluste bei Bearbeitung minimieren will. Und dann wird man wohl kaum einen lossy Codec verwenden, sondern bleibt gleich bei x265 lossless.
Ob Pascal x265 lossless dekodieren kann, ist zudem gar nicht bekannt.
Und du schreibst schon wieder von 4:4:4, obwohl davon bei den bisherigen Leaks nicht die Rede war.

Siehe meinen Edit, es gab aber auch bei den maximalen Bitraten vorher Unterschiede, die Wikipedia nicht aufführt, trotz scheinbar identischem VP. Ich weiß das, weil Doom9 das regelmäßig und zuverlässig testet. Du kannst dir das auch gerne im entsprechenden Forum durchlesen, ist kein Geheimnis. Da nur den VP bei Wiki anzugeben, ist Quatsch, da fehlt die Hälfte.

Eine etwas konkretere Quelle wär schon nice. Am besten irgendein Screenshot des DXVA Checkers.
Ansonsten finde ich nirgendwo einen Hinweis, der deine These stützen würde.

4K ist bei deiner Definition auch ein Checklistenfeature oder? Wird doch nur auf der Ultra HD Blu-ray genutzt. Auch DX12 wäre nach deiner Definition ein Checklistenfeature, es nutzt ja kaum einer! Ja, jetzt vielleicht, aber wenn du die Möglichkeit nicht anbietest, dann wird es auch nie jemand nutzen, du verstehst das Problem?
Ich finde das jetzt etwas albern...

BigKid

2016-05-16, 07:54:45

Es ist aber trotzdem nur ein Checklistenfeature auf dem Papier, wenn es keinen Content gibt.
Kein Chroma Subsampling wär schön für Spiele-Aufzeichnungen, davon ist aber nichts gesagt worden.

Das ist schon länger nicht mehr so. Alle Keplers hatten afaik die gleiche VPU, ein Update gabs erst mit Maxwell 1.0.

p
Wenn es so wäre, wär es bitter (und peinlich).
Dass es keinen Kontent gibt ist a) nicht ganz richtig und b) ein Henne/Ei Problem. Ohne passende Dekoder kommt kein Kontent... Ich für meinen Teil habe schon angefangen meine TV Aufzeichnungen in 720p x265 abzulegen... Mehr als 720p packen meine Media PCs nämlich leider nicht. Hardwarebeschleunigung von h265 ist kein Checklistenfeature für mich...
12 Bit ist mir allerdings aktuell hupe...

TheGood

2016-05-16, 08:36:48

Dass es keinen Kontent gibt ist a) nicht ganz richtig und b) ein Henne/Ei Problem. Ohne passende Dekoder kommt kein Kontent... Ich für meinen Teil habe schon angefangen meine TV Aufzeichnungen in 720p x265 abzulegen... Mehr als 720p packen meine Media PCs nämlich leider nicht. Hardwarebeschleunigung von h265 ist kein Checklistenfeature für mich...
12 Bit ist mir allerdings aktuell hupe...
Und für mich ist es ein weil ich das schlicht nicht brauche.

Die Frage ist auf wieviele Graka Käufer das zutrifft und da ist wohl zu sagen auf die Mehrheit....
Fuer den Massenmarkt ist Streaming das klar definierte Ziel und nicht alles selbst aufzuzeichnen... ISt beim akutellen Angebot auch nicht notwendig. Damit bleiben dann noch die Leute die Selbst Videos aufnehmen und schneiden... was eben die klare Minderheit ist...

fondness

2016-05-16, 09:25:56

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11033543&postcount=5534 :wink:

Ist doch voellig Hupe wie es umgesetzt wird ,wenns funktioniert dann funktionierts

Das ist der Ansatz den Nvidia gewaehlt hat

Es ist eben nicht völlig Hupe wie es umgesetzt wurde, denn unterstützen tut es Nvidia natürlich auch schon mit Maxwell, sonst wäre man nämlich gar nicht dx12 kompatibel. Aber wie es schon eigentlich bekannt war, haben sie eben jetzt einen deutlich schnelleren context Switch aber wohl kein paralleles ausführen wie AMD. Wie sich die Performance in der Praxis verhält muss man schlicht abwarten.

Troyan

2016-05-16, 09:33:54

Es ist eben nicht völlig Hupe wie es umgesetzt wurde, denn unterstützen tut es Nvidia natürlich auch schon mit Maxwell, sonst wäre man nämlich gar nicht dx12 kompatibel. Aber wie es schon eigentlich bekannt war, haben sie eben jetzt einen deutlich schnelleren context Switch aber wohl kein paralleles ausführen wie AMD. Wie sich die Performance in der Praxis verhält muss man schlicht abwarten.

:rolleyes:

http://cdn.videocardz.com/1/2016/05/NVIDIA-GeForce-GTX-1080-Pascal-Dynamic-Load-Balancing-900x426.jpg

AnarchX

2016-05-16, 09:54:43

Zumal man dann auf der Titan wieder nur 12 GiB verbauen kann, wenn man nicht gleich wieder auf 24 verdoppeln will.
Wenn Micron die versprochenen 12Gbit Module liefert, könnte ein 384-Bit GP102 auch mit 18GiB kommen, ohne das die Bandbreite leidet.

Interessant ist jedenfalls auch, dass NV bei GP104 8 Speicherkontroller im Blockbild zeigt: http://cdn.videocardz.com/1/2016/05/NVIDIA-GP104-Block-Diagram.jpg - Fehler oder hat sich da etwas geändert?

Troyan

2016-05-16, 10:03:19

Es sind 8x 32bit Controller wie auch bei Maxwell oder Kepler.

HOT

2016-05-16, 10:24:30

:rolleyes:

http://cdn.videocardz.com/1/2016/05/NVIDIA-GeForce-GTX-1080-Pascal-Dynamic-Load-Balancing-900x426.jpg
Ähm, das IST AsyncCompute. Erstes Bild ist Maxwell, zweites Pascal. Das ist die Bestätigung, dass Pascal AsyncCompute wie GCN gen1 kann. Nur eben nicht Latenzarm mit Priorisierung wie ab GCN gen.2.

Undertaker

2016-05-16, 10:31:30

Troyan

2016-05-16, 10:37:41

Es geht ihm um AMDs "Quick Response Queue". Was für nVidia vollkommen egal ist, da sie mit Preemption und Pascal das gleiche erledigen.

Complicated

2016-05-16, 11:01:35

Nur ist das eben völlig was anderes. AMD startet Compute Tasks bevor die Graphics Tasks beendet sind.
Aus dieser Grafik wird ersichtlich warum Nvidia bei seiner Darstellung so "glatte Blöcke" genutzt hat:
http://www.pcgameshardware.de/screenshots/662x/2016/03/AMD-Asynchronous-Compute-Quick-Response-Queues-pcgh.png

Hier sieht man wie Preemption wirkt.
Man sieht dass Asynchronous Compute die freien Ressourcen nutzt ohne die Graphics Pipeline zu behindern.
Man sieht wie Quick Response die Graphics Pipeline zugunsten von Compute verlangsamen darf.

Troyan

2016-05-16, 11:33:10

Da hat jemand die Folien nicht verstanden...

ATW ist ein reiner Compute-Workload der zum spätmöglichsten Zeitpunkt vor dem Refresh ausgeführt werden muss. Mit Pascal kann nVidia nun deutlich später die Arbeit unterbrechen und die komplette GPU für diesen Compute-Workload verwenden.

Ailuros

2016-05-16, 11:43:34

Jetzt bringst du mich aber auf eine Idee:

GP102 für die 1080 Ti mit kleinerem Die und GDDR5X, um 700-800 USD.
GP100 für die Pascal Titan um 1500-2000 USD. Man will schließlich sehen, wie locker das Geld bei den Enthusiasts sitzt.

Es gab intern so manche Meinungsverschiedenheiten mit dem Gedanken ob man einen Titan mit vollen DP Faehigkeiten ueberhaupt verkaufen sollte. Selbst wenn sie den MSRP fuer einen P100/Titan bei $2k anlegen wuerden, haben sie immer noch ziemlich grosse Gewinn-Verlueste im Vergleich zu einer GP100 Tesla oder noch schlimmer Quadro. Wieso ein Tier mit =/>5.3 TFLOPs DP um "nur" $2000 verkaufen wenn man fuer eine Tesla =/> $3k bekommen kann bzw. fuer eine Quadro um die 5k?

Fall es einen 102 wirklich geben sollte, besteht zwar die Moeglichkeit von irgend einem Titan-Brummer aber wohl eher als treuer GM200/Titan Nachfolger und sonst nichts. Anders: in dem Fall sehe ich nur einen GP102/Titan und wenn sie den Preis laecherlich hoch anlegen moechten klatscht man eventuell dann auch 24GB Speicher drauf und gut ist es.

Complicated

2016-05-16, 11:45:18

Es geht ihm um AMDs "Quick Response Queue". Was für nVidia vollkommen egal ist, da sie mit Preemption und Pascal das gleiche erledigen.Genug um zu wissen dass diese Aussage unwahr ist. Und um dies zu belegen sind die Folien ja wohl eindeutig geeignet.

Von ATW habe ich überhaupt nichts geschrieben, da dies nur ein Anwendungsfall für VR ist. AMD kann die Compute Task höher priorisieren als schon laufende Graphics Tasks und das kann Nvidia mit Peemption eben nicht. Es ist nicht das gleiche.

Du hast wohl die Folien eher nicht verstanden. Es geht um Compute Leistung die im aktuellen Frames genutzt werden muss und somit kleinere Latenzen ermöglicht.

AnarchX

2016-05-16, 11:52:23

Troyan

2016-05-16, 11:56:41

Genug um zu wissen dass diese Aussage unwahr ist. Und um dies zu belegen sind die Folien ja wohl eindeutig geeignet.

Von ATW habe ich überhaupt nichts geschrieben, da dies nur ein Anwendungsfall für VR ist. AMD kann die Compute Task höher priorisieren als schon laufende Graphics Tasks und das kann Nvidia mit Peemption eben nicht. Es ist nicht das gleiche.

Du hast wohl die Folien eher nicht verstanden. Es geht um Compute Leistung die im aktuellen Frames genutzt werden muss und somit kleinere Latenzen ermöglicht.

Bitte, verstehe einfach den Kontext von Antworten.
"Quick Response Queue" ist nichts anderes wie das Priorisieren der GPU für einen Workload. Genau das macht nVidia mit Preemption. Und mit Pascal können sie wesentlich feiner und schneller den Wechsel vollführen und die komplette GPU für den Workload verwenden.

fondness

2016-05-16, 12:03:38

Preemption ist nichts anderes wie ein Context Switch. Es muss der gesamte, aktuelle Context weggesichert werden und der neue geladen, das ist sicher die aufwändigste Art und das macht man auch nur, wenn es anders nicht geht. Es wird viel von der genauen Implementierung abhängen, wenn Nvidia einen ähnlich schnellen Context Switch wie AMD/Intel ermöglicht, kann das für viele Fälle ausreichend sein. Deshalb gilt es die Entwicklung abzuwarten. Um leicht sarkastisch zu sein: Für die nächsten zwei Jahre könnte das wohl schon halbwegs reichen und länger will nvidia wohl eh nicht, dass die Hardware hält^^

Kriton

2016-05-16, 12:07:41

Wenn es so wäre, wär es bitter (und peinlich).

Zumal es mir bei kleineren Karten wichtiger erscheint.

Complicated

2016-05-16, 12:09:18

Nur kann Nvidia mit Preemption nicht den selben schnellen Context-Switch durchführen. Daher ist Preemption in Latenz kritischen Szenarien unterlegen und eben nicht das selbe wie AMDs "Quick Response Queue". In Verbindung mit der Priorisierung muss man eben auch beachten wann diese Priorisierung zum tragen kommt.

Bitte verstehe auch den Kontext der Antworten die ich dir gebe.
Preemption!=QRQ
Folie=Beleg für unterschiedliches Verhalten bei der Priorisierung (auch wenn beide Priorisierungen vornehmen)
Quick response Queue ist eben doch viel mehr anderes als nur Priorisieren der GPU für einen Workload.

Nach deiner Argumentation könnte ich noch eine Ebene höher gehen und sagen DX11 und DX12 sind das selbe, es kommt überall ein Bild zum Spielen dabei heraus. Auch da würdest du Widerspruch ernten, selbst wenn die grundlegende Feststellung erst mal stimmt, allerdings nicht als Parameter taugt Unterschiede darzustellen oder zu negieren zwischen DX11 und DX12.

Auch wenn Lachse und Haie Fische sind, sind sie nicht das selbe.

fondness

2016-05-16, 12:23:10

Im Grunde hat es ein Dev bei AnandTech eh schon vor einiger Zeit gesagt:

I can't say to much on this topic, but Pascal will be an improvement over Maxwell especially at this feature. But no, it won't have GCN-like capabilities. It will be close to GCN 1.0, but nothing more.

http://forums.anandtech.com/showpost.php?p=38121238&postcount=36

Klare Verbesserung keine Frage, aber nicht mal ganz GCN1.0-like - und der kam Anfang 2012.

Troyan

2016-05-16, 12:30:53

Nur kann Nvidia mit Preemption nicht den selben schnellen Context-Switch durchführen. Daher ist Preemption in Latenz kritischen Szenarien unterlegen und eben nicht das selbe wie AMDs "Quick Response Queue". In Verbindung mit der Priorisierung muss man eben auch beachten wann diese Priorisierung zum tragen kommt.

Und AMD muss Ressourcen der GPU für die weiterlaufende Grafikarbeit aufbringen. Die können die Arbeit nicht wegspeichern.
Selbst in AMDs Showbild benötigt "QRQ" länger als Asynchronous Shaders - initialisierung des Computeworkloads und das neu schedulen vom Graphicsworkload kostet ebenfalls Zeit.

Bitte verstehe auch den Kontext der Antworten die ich dir gebe.
Preemption!=QRQ
Folie=Beleg für unterschiedliches Verhalten bei der Priorisierung (auch wenn beide Priorisierungen vornehmen)
Quick response Queue ist eben doch viel mehr anderes als nur Priorisieren der GPU für einen Workload.

:freak:

Darum ging es nie. Aber dies ist eben das große Problem, wenn Leute nicht verstehen, was andere schreiben.
"Das gleiche erledigen" steht für "Priorisierung von Computeworkload". Darauf habe ich mich auf Hot bezogen.

iuno

2016-05-16, 12:50:50

Wo steht da irgendetwas zu Latenzen oder Priorisierung? Das Bild zeigt:

- das paralleles Ausführen schon bei Maxwell ging
- bei Pascal nicht auf die Beendigung beider Tasks gewartet werden muss, wenn die Ausführungsressourcen neu verteilt werden sollen -> kein Leerlauf mehr

Letzteres war übrigens auch der Grund, warum bei Maxwell teils Performance bei Aktivierung von Asynchronous Compute verloren ging.

Ohne den Kontext zum Bild zu kennen steht da ueberhaupt nichts von Maxwell.
Es wird zwischen statischer und dynamischer Verteilung verglichen, nicht zwischen Architekturen.
Maxwell konnte nicht mal das was im ersten Diagramm gezeigt wurde. Da ging nur entweder oder und beim Wechsel zwischen den beiden bliebt die ganze Maschine quasi erstmal stehen. DAS war der Grund, "warum bei Maxwell teils Performance bei Aktivierung von Asynchronous Compute verloren ging"

Nakai

2016-05-16, 12:58:19

Pascal Dynamic Load Balancing:
Hat nichts mit Async zu tun. Wenn ein Kernel/Call auf einer SM beendet ist, ist es logisch die freien Ressourcen für andere Kernels/Calls frei zu geben. Was meint NV damit? Wird damit gemeint, dass Warps eines Calls die SMs wechseln? Das würde nur per Workgroup oder Block funktionieren.

Pre-Emption:
Bei Pascal kann Graphics Compute pre-emption und vice versa. Das ist wichtig. Dabei scheint es aber, dass eine SM nur Graphics oder Compute gleichtzeitig ausführen kann. Wäre das nicht der Fall, wäre Pascal so ziemlich Async-fähig. Das ist aber nicht der Fall. Das ist auch der größte Unterschied zu AMD.

AMDs CUs interessiert es nicht, ob die Warps/Wavefronts von COmpute oder Graphics kommen. NV macht da noch einen Unterschied.

Darum ging es nie. Aber dies ist eben das große Problem, wenn Leute nicht verstehen, was andere schreiben.
"Das gleiche erledigen" steht für "Priorisierung von Computeworkload". Darauf habe ich mich auf Hot bezogen.

Also, wenn ich einen Nagel mit meiner Faust in die Wand schlagen kann, dann ist meine Faust gleichwertig mit einem Hammer?

iuno

2016-05-16, 13:03:27

Bitte, verstehe einfach den Kontext von Antworten.
"Quick Response Queue" ist nichts anderes wie das Priorisieren der GPU für einen Workload. Genau das macht nVidia mit Preemption. Und mit Pascal können sie wesentlich feiner und schneller den Wechsel vollführen und die komplette GPU für den Workload verwenden.
Nein das ist Unsinn. QRQ ist das Priorisieren eines Compute Tasks, der reingeschmissen wird, waehrend ein gfx Task schon laeuft. Preemption gibt es bei AMD auch. Das ist keine neue Errungenschaft von Pascal sondern uralt und nicht der Rede wert. Allerdings bin ich die ganze Zeit schon davon ausgegangen, dass NV den context switch mit Pascal schneller hinbekommt, insofern ist es natuerlich eine Verbesserung in dem Bereich, hat mit einer Neuerung aber rein gar nichts zu tun.

Und AMD muss Ressourcen der GPU für die weiterlaufende Grafikarbeit aufbringen. Die können die Arbeit nicht wegspeichern.
Entschuldige aber was fuer ein BS :crazy: Selbstverstaendlich kann AMD Preemption, uebrigens mit viel schnellerem context switching - sofern das da ueberhaupt noetig ist, wenn ME und MEC eingesetzt werden, so wie das heute gemacht wird. Wenn die Compute Queue der ME genutzt wird, mag das noch problematisch sein, da bin ich mir aber momentan nicht sicher.

Selbst in AMDs Showbild benötigt "QRQ" länger als Asynchronous Shaders - initialisierung des Computeworkloads und das neu schedulen vom Graphicsworkload kostet ebenfalls Zeit.
Das ist ja auch der Sinn der Sache. Damit der Compute Task schneller fertig wird wird Zeit geopfert, ist trotzdem noch viel schneller als alles seriell auszufuehren und einen context switch zu machen.

"Das gleiche erledigen" steht für "Priorisierung von Computeworkload". Darauf habe ich mich auf Hot bezogen.
Ja, es priorisiert. Schneller wird es dadurch aber nicht, im Gegenteil. Und QRQs verkleinern diese Verlangsamung signifikant

Nakai

2016-05-16, 13:09:49

Entschuldige aber was fuer ein BS :crazy: Selbstverstaendlich kann AMD Preemption, uebrigens mit viel schnellerem context switching - sofern das da ueberhaupt noetig ist, wenn ME und MEC eingesetzt werden, so wie das heute gemacht wird. Wenn die Compute Queue der ME genutzt wird, mag das noch problematisch sein, da bin ich mir aber momentan nicht sicher.

Man muss hierbei sagen, dass NV mit Pascal endlich Echtzeit-fähig geworden ist. Während man bei Maxwell immer noch den Call bzw. den Kernel abwarten musste, kann diese Pascal auf Instruktion-Ebene. Kurz, man weiß genau, wie lang ein Context-Switch benötigt bzw. eine Pre-Emption benötigt. Ging bei Maxwell nicht, weswegen Maxwell absolut untauglich für VR ist.

fondness

2016-05-16, 13:11:29

scully1234

2016-05-16, 13:14:28

Wie sich die Performance in der Praxis verhält muss man schlicht abwarten.

Eigentlich nicht da es die Bestaetigung dazu schon gibt in AMDs Haus und Hof Benchmark:smile:

iuno

2016-05-16, 13:15:36

Man muss hierbei sagen, dass NV mit Pascal endlich Echtzeit-fähig geworden ist. Während man bei Maxwell immer noch den Call bzw. den Kernel abwarten musste, kann diese Pascal auf Instruktion-Ebene. Kurz, man weiß genau, wie lang ein Context-Switch benötigt bzw. eine Pre-Emption benötigt. Ging bei Maxwell nicht, weswegen Maxwell absolut untauglich für VR ist.
Naja genauso "komplett untauglich" wie die verkrueppelte 970 im normalen Betrieb eben.
Komplett untauglich ist es natuerlich nicht und man kann viel kaschieren oder es faellt einfach nicht so sehr ins Gewicht, obwohl es auf den ersten Blick wie eine Katastrophe scheint.
Ich erkenne ja an, dass es hier Verbesserungen gegeben hat, ich schrieb ja auch dass ich das fuer Pascal erwartet hatte. Man muss hier ja auch sehen, dass Devs quasi mehr Freiheiten haben, wenn sie nicht auf den sterbend langsamen Context Switch "Ruecksicht nehmen" muessen, den eben fast alle Karten am Markt hatten. Fuer Kepler/Maxwell koennte das aber wiederum problematisch werden.
Troyan tut aber schon wieder so als waere das die absolute Offenbarung, obwohl Nvidia da nur eben am aufholen ist, ich bin mir ja nicht mal sicher, ob sie damit Intels GPUs ueberholen was das Thema angeht.

fondness

2016-05-16, 13:18:12

Eigentlich nicht da es die Bestaetigung dazu schon gibt in AMDs Haus und Hof Benchmark:smile:

AsyncCompute steht erst am Anfang, die Quick Response Queue bsw. hat AMD erst seit wenigen Treiberversionen integriert, hier ist noch viel mehr möglich als aktuell in den ersten Spielen experimentell umgesetzt wurde. Deshalb meine Aussage man muss hier die Entwickelung abwarten.

Troyan

2016-05-16, 13:18:14

Also, wenn ich einen Nagel mit meiner Faust in die Wand schlagen kann, dann ist meine Faust gleichwertig mit einem Hammer?

Da wir hier nicht über Asynchronous Shaders (Async Compute) reden, machen solche Vergleiche einfach keinen Sinn. Genauigkeit ist wichtig.

AS und QRQ sind für zwei vollkommen unterschiedliche Gebiete gedacht. Das eine will ein Frame so schnell wie möglich abarbeiten, das andere will einen bestimmten Workload am schnellsten erledigen.

Deswegen benötigt QRQ für beide Queues auch länger als AS.

iuno

2016-05-16, 13:20:25

Verstehe die Aussage nicht. QRQ ist nur eine Untermenge von den Moeglichkeiten, AS zu implementieren.
Selbstverstaendlich zielt das auf dasselbe Anwendungsgebiet ab, nur dass in einem Modus eben einzelne Tasks priorisiert werden koennen und im anderen die gfx queue immer bevorzugt wird.

Nakai

2016-05-16, 13:46:56

Da wir hier nicht über Asynchronous Shaders (Async Compute) reden, machen solche Vergleiche einfach keinen Sinn. Genauigkeit ist wichtig.

AS und QRQ sind für zwei vollkommen unterschiedliche Gebiete gedacht. Das eine will ein Frame so schnell wie möglich abarbeiten, das andere will einen bestimmten Workload am schnellsten erledigen.

Deswegen benötigt QRQ für beide Queues auch länger als AS.

Das steht "Asynchronous Shaders with Quick Response Queue" und das soll jetzt nicht AS sein?

Das hat auch nichts damit zu tun, dass das Frame so schnell wie möglich abgearbeitet werden soll. Die Berechnung des Frames liegt einfach schon auf die Berechnungseinheiten, weswegen ein neuer Call/Kernel eben nur die Ausführungslücken schließen kann. Wenn zuerst ein Compute-Kernel da gewesen wäre, wäre es genau umgekehrt. Wenn jedoch ein Kernel/Call früher fertig werden muss, dann ist QRQ sehr hilfreich, weil dadurch Ausführungsressourcen zugunsten eines anderen Kernel/Calls umgeschlichtet werden.

€: Der Unterschied zwischen AMD und NV ist Folgender: NV muss bei einem Context-Switch zwingend pre-empten. AMD nicht, wenn die CU noch Wavefornts/Warps aufnehmen kann (und hoffentlich die Register-Usage noch niedrig ist).

Troyan

2016-05-16, 13:47:48

QRQ hat nichts mit AS zu tun. Es ist nur für AMD der schnellste Weg die Anforderungen des Aufgabengebietes umzusetzen.

ATW als Computeworkload hat nichts mit Graphicsworkload zu tun, der läuft bzw. früher als Queue eingestellt wurde. Es ist also belanglos, ob ATW über Preemption oder QRQ gelöst wird. Es ist für QRQ auch nicht vom Belang, ob die bestmöglichste Auslastung der Einheiten möglich ist.

/edit: Wo wir gerade dabei: Wie löst AMD eigentlich ATW mit <GCN 1.2 Hardware? Preemption?

Complicated

2016-05-16, 14:24:48

Selbst in AMDs Showbild benötigt "QRQ" länger als Asynchronous Shaders - initialisierung des Computeworkloads und das neu schedulen vom Graphicsworkload kostet ebenfalls Zeit. Weil QRQ eine Technik ist den latenzfeindlichen Effekten von Preemption entgegen zu wirken.
Es geht ihm um AMDs "Quick Response Queue". Was für nVidia vollkommen egal ist, da sie mit Preemption und Pascal das gleiche erledigen.Ohne Preemption kein AS. Ohne AS kein QRQ. Eines baut auf das andere auf. Nvidia hat nun die erste Stufe gemeistert. Deshalb müssen sie immer noch etwas finden um AS und QRQ ebenbürtig zu werden - darüber ist nichts bekannt bisher.
Man muss hierbei sagen, dass NV mit Pascal endlich Echtzeit-fähig geworden ist. Während man bei Maxwell immer noch den Call bzw. den Kernel abwarten musste, kann diese Pascal auf Instruktion-Ebene. Kurz, man weiß genau, wie lang ein Context-Switch benötigt bzw. eine Pre-Emption benötigt. Ging bei Maxwell nicht, weswegen Maxwell absolut untauglich für VR ist.Auf den Punkt gebracht.

ATW als Computeworkload hat nichts mit Graphicsworkload zu tun, der läuft bzw. früher als Queue eingestellt wurde. Es ist also belanglos, ob ATW über Preemption oder QRQ gelöst wird. Es ist für QRQ auch nicht vom Belang, ob die bestmöglichste Auslastung der Einheiten möglich ist.Was hat denn ATW in dieser Diskussion für einen Stellenwert?

Gipsel

2016-05-16, 14:29:17

QRQ hat nichts mit AS zu tun.Das ist falsch. QRQ beschreibt eine Möglichkeit der Priorisierung von Aufgaben für die asynchrone (und gleichzeitige, konkurrente) Ausführung. Daß das nichts miteinander zu tun hätte, ist ziemlich absurd.
ATW als Computeworkload hat nichts mit Graphicsworkload zu tun, der läuft bzw. früher als Queue eingestellt wurde. Es ist also belanglos, ob ATW über Preemption oder QRQ gelöst wird. Es ist für QRQ auch nicht vom Belang, ob die bestmöglichste Auslastung der Einheiten möglich ist.Ob der asynchrone Timewarp bei VR über Preemption oder QRQ gelöst wird (und auch, wie performant Preemption funktioniert) ist nicht völlig belanglos. Zumindest für die Gesamtperformance. Mit QRQ (also ohne zwischenzeitlichen Leerlauf) kommt eine höhere Gesamtperformance heraus (also mehr fps). Und je schneller die Preemption ist, desto niedriger wird der Rückstand (mit im Extremfall vernachlässigbarem Rückstand).
NV spricht für ihre Preemption-Implementation von Latenzen im Bereich von ein paar Hundert Mikrosekunden. Das ist für den Timewarp bei VR, der einmal pro Frame stattfindet wohl absolut akzeptabel (vorher hat nV den Entwicklern empfohlen, die Ausführungszeit von Drawcalls unter einer Millisekunde zu halten, damit man dann den Timewarp einschieben kann). Man erreicht das jetzt also mindestens genauso gut (besser, weil es eben reproduzierbar und planbar funktioniert), ohne dem Entwickler diese Vorgabe machen zu müssen. Aber was ist mit Szenarien, wenn wild abwechselnd hunderte Compute und Grafikcalls pro Frame (statt nur einer für den ATW) abgesetzt werden? Selbst hundert µs pro Switch sind hundert µs. Wenn das hundert Context Switches pro Frame sind (die der Treiber nicht durch Umordnen umgehen kann), kommen da irgendwann merkliche Zeitbeträge pro Frame heraus. Pascals zusätzlicher Vorteil gegenüber Maxwell in diesem Zusammenhang scheint jetzt zu sein, daß nun jeder SM unabhängig und dynamisch zwischen Compute und Grafik schalten kann, man also diese hundert µs (oder wieviel genau es denn nun wirklich sind) nicht für den Gesamtchip verloren gehen, sondern nur für die Anzahl an SMs, auf denen das dann laufen soll. Wieviel das in der Praxis letztendlich ausmacht, wird man sehen müssen. Ich bin aber zuversichtlich, daß wenn der Entwickler ein wenig acht gibt, der Verlust im überschaubaren Rahmen bleiben dürfte.
/edit: Wo wir gerade dabei: Wie löst AMD eigentlich ATW mit <GCN 1.2 Hardware? Preemption?Ebenfalls über Asynchronous Compute. Prioritäten gibt es da auch schon. Es gibt lediglich weniger Queues und die Prioritäten sind nicht ganz so flexibel setzbar. Aber gehen tut es bereits mit GCN 1.0.

Die "QRQ" ist lediglich ein Label, was einen Aspekt des AC bei GCN griffig beschreiben soll. Im Prinzip kann man wählen, welche Priorität welche Tasks bekommen sollen. Das kann die gleiche für Grafik- und Computeshader sein, oder eben auch eine mehr oder minder starke Bevorzugung von entweder Grafik (Computeshader laufen dann gewissermaßen im Hintergrund und nutzen dann bevorzugt die Pipelinebubbles der Grafikshader) oder eben Compute (was bei QRQ dargestellt wird, Grafik nutzt die Pipelinebubbles der Computeshader). Im Prinzip ist die GCN-Hardware sogar noch flexibler. Man kann nicht nur für jeden Shader/Kernel über die jeweilige Queue eine Priorität setzen, die Hardware kann für jede einzelne Wavefront eines Kernels Prioritäten setzen (individuell im Shadercode, seit GCN 1.0 schon). Das wird aber zugebenerweise wohl bisher praktisch nicht benutzt.

TLDR:
Du kannst iuno und Nakai in der Frage schon glauben. Und Nakais edit im letzten Post faßt den Unterschied ebenfalls gut zusammen.

Ravenhearth

2016-05-16, 14:52:22

Ist die Frage, ob GP102 wirklich kleiner sein wird. Mit GM200 und GK210 hatte man parallel auch zwei ~600mm² GPUs gefertigt.

Eine 15 TFLOPs 64GiB GDDR5X 768GB/s GPU könnte man sicherlich auch in ein paar Profi-Märkten neben GP100 platzieren und für 2017/Anfang 2018 hätte man ein brauchbares Flagschiff.

Ein doppelter GP104 mit 5120 ALUs und 512 bit würde einfach zu viel Strom aufnehmen, selbst bei "nur" 1,5 GHz. Man wäre locker bei knapp 300W, vielleicht sogar mehr.
Aber Nvidia steht gar nicht unter Zugzwang, so ein Monster zu liefern. Ein GP104 +50% ist wesentlich wirtschaftlicher und würde gegen einen Vega11 vermutlich auch genügen.

illidan

2016-05-16, 15:18:39

Oliver_M.D

2016-05-16, 16:44:38

Die Slides sind geleaked:
http://videocardz.com/59962/nvidia-geforce-gtx-1080-final-specifications-and-launch-presentationBin ja kein experte, aber wenn der Video Encoding Support echt so geil ist wie beschrieben freu ich mich jetzt schon extremst drauf.
Hoffen wir mal das die encoding bitrate endlich auch anständig ist und nit so widerlich beschränkt wie ichs in erinnerung habe.

illidan

2016-05-16, 16:47:42

Wär auch nett, wenn ShadowPlay nicht mehr so ein Haufen Schrott wäre, der ständig Probleme hat und viel zu wenig Optionen anbietet.

just4FunTA

2016-05-16, 16:52:43

shadowplay ist doch aktuell konkurrenzlos gut.

Oliver_M.D

2016-05-16, 17:06:46

shadowplay ist doch aktuell konkurrenzlos gut.Kann ich leider nur bestätigen. Funzt bei mir fast immer ohne probleme nud das mit grandioser performance. Und ich bin nur ein first gen (670GTX) nutzer.
Die einzigsten probleme die ich vermelden kann liegen eher an meiner sterbenden 670 selbst und nicht an shadowplay.
und viel zu wenig Optionen anbietet.Das ist der einzigste punkt wo ich dir zustimmen muss. Und das auch nur weil ich bei shadowplay die multi-audio-track option vermisse die ich von OBS (Studio) kenne und liebe.

illidan

2016-05-16, 17:22:00

Lies mal bei Guru3D. Die bauen da Bugs ein, dass jegliche Videoaufnahme z.B. einfach nicht flüssig (Stutter/Judder bei Drehungen wie bei der Windmühle in Unigine Heaven) ist und fixen das dann ewig nicht. Völlig indiskutabel. Gegen ein vernünftig gecapturetes Video von Gamersyde ist das Resultat einfach nur Abfall. Sorry, ist so.
Dieses Raptr-Programm bei AMD ist natürlich völliger Murks², aber hier gehts ja um NV. ;)

just4FunTA

2016-05-16, 17:34:52

welches Programm bietet bessere Ergebnisse bei gleichem oder geringerem performanceverlust?

illidan

2016-05-16, 17:46:58

Ich führe die Diskussion nicht weiter. Wenn ihr Ruckel-Videos als brauchbar erachtet, bitte. Ich tu es nicht.

just4FunTA

2016-05-16, 17:55:30

Ich führe die Diskussion nicht weiter. Wenn ihr Ruckel-Videos als brauchbar erachtet, bitte. Ich tu es nicht.

Was gibt es da zu diskutieren? Entweder es gibt ein besseres Programm oder shadowplay ist aktuell das beste Programm. Da kann man ja nicht groß drüber diskutieren.

weitere Verbesserungen sind natürlich wie bei jedem anderen Programm willkommen.

Ex3cut3r

2016-05-16, 17:59:09

Shadowplay an sich ist toll, nur die Bloatware mit der es kommt, sprich Geforce Experience ist alles andere als Toll, läuft ständig im Hintergrund und frisst dann natürlich Ressourcen, ich habe am liebsten so wenig wie möglich an Prozesse die nicht wirklich brauche.

Wenn Shadowplay separat ohne Experience kommen wurde, wurde ich das sehr begrüßen, wird aber leider so und so nicht passieren.

Ailuros

2016-05-16, 18:58:51

Falls die Kompression schon besprochen wurde bitte loeschen:

http://videocardz.com/59962/nvidia-geforce-gtx-1080-final-specifications-and-launch-presentation

http://cdn.videocardz.com/1/2016/05/NVIDIA-GeForce-GTX-1080-Pascal-Memory-Compression.jpg

Kann da jemand etwas weiter erlaeutern?

Hübie

2016-05-16, 20:14:21

Ja aus allen Farben wird einfach grau gemacht. X-D

Aber im Ernst: das sieht nach drei Stufen aus. RG, GB und B verenden jeweils unterschiedlich starke Kompressionen. Das ginge dann separat auch mit R, G und B 8:1. Wobei das sehr theoretischer Natur ist und nix vom Alpha gesagt wird.

Ailuros

2016-05-16, 20:16:08

Und ich dachte ich hab etwas wesentliches verpasst :P

Oliver_M.D

2016-05-16, 21:06:49

Ich führe die Diskussion nicht weiter. Wenn ihr Ruckel-Videos als brauchbar erachtet, bitte. Ich tu es nicht.Finds schon lustig das du einfach auf bockig machst und "die Diskussion nicht weiter" führen willst weil nichts besseres anzubieten hast ;D
Davon abgesehen weiß ich nicht mal was du mit "Ruckel-Videos" meinst da ich damit persönlich noch keine probleme hatte. Das gegenteil eher.
Gegen ein vernünftig gecapturetes Video von Gamersyde ist das Resultat einfach nur Abfall.Für deren videos wird ja auch sicherlich kein first gen NVENC encoding benutzt sondern eher ein HQ software basierendes mit gescheiter bitrate.
First gen deshalb weil ich nur eine 670 habe und daher noch leider nichts über die quali von HEVC in shadowplay berichten kann.

Was gibt es da zu diskutieren? Entweder es gibt ein besseres Programm oder shadowplay ist aktuell das beste Programm. Da kann man ja nicht groß drüber diskutieren.Eben. Fakt ist das Shadowplay in moment ziemlich überlegen und alleine ohne große konkurrenten in raum steht.
Und ich bezweifle auch stark das sich so schnell etwas dank Maxwell oder Pascal daran ändern wird.

Raptr / PlaysTV kann man zb gleich ganz vergessen weil das noch schlimmere bloatware als Nvidia Exp ist. Und als AMD kunde hat man leider nur das oder den OBS VCE Fork zur verfügung die beide nicht gerade ideal sind.
Und Fraps / OBS (Software) haben ihre eigenen probleme danke speicher und / oder CPU belastung.
Wenn Shadowplay separat ohne Experience kommen wurde, wurde ich das sehr begrüßen, wird aber leider so und so nicht passieren.Habe selbst zwar keine großen problem mit Exp, würde mir aber trotzdem auch gerne ein standalone von Nvidia wünschen.

illidan

2016-05-16, 21:09:31

Finds schon lustig das du einfach auf bockig machst und "die Diskussion nicht weiter" führen willst weil nichts besseres anzubieten hast ;D
Davon abgesehen weiß ich nicht mal was du mit "Ruckel-Videos" meinst da ich damit persönlich noch keine probleme hatte. Das gegenteil eher.

Hab ich dir schon erklärt. Da zeigt sich ja auch die Sinnhaftigkeit, diese Diskussion weiterzuführen...
Einige Leute meinen ja auch, sie würden mit Vsync mit schwankender Framerate kein Ruckeln bemerken. Kann man argumentativ nichts machen...

StefanV

2016-05-16, 21:43:02

AMD kann natürlich noch positiv überraschen, aber bei AMD bin ich genau gegenteiliges gewohnt...
SRYSLY?!

Nachdem nVidia gerade die waren, die in diesem Punkt meilenweit hinterher hinkten?!

illidan

2016-05-16, 22:11:00

Hä, was? ;D

StefanV

2016-05-16, 22:17:42

Ein GP104 +50% ist wesentlich wirtschaftlicher und würde gegen einen Vega11 vermutlich auch genügen.
Und das kannst du jetzt warum genau beurteilen, nachdem man über Polaris/Vega noch rein gar nichts weiß?!

horn 12

2016-05-16, 23:56:30

Ravenhearth

2016-05-17, 01:15:36

Und das kannst du jetzt warum genau beurteilen, nachdem man über Polaris/Vega noch rein gar nichts weiß?!

Dir ist die Bedeutung des Wortes "vermutlich" bekannt? Konkret lautet meine Vermutung so: Polaris10 auf 980-Niveau, Vega10 ist 60% schneller (64 CUs), also etwa auf 1080-Niveau, Vega11 könnte mit 6144SPs genau 50% drauflegen, was einem GP102 als GP104 +50% entspräche. Vermutlich.

Korvaun

2016-05-17, 07:15:24

@Ailuros

Lag es echt nur am Druck seitens NV auf TSMC dass Nvidia Ihre Karten nun früher als AMD bringt und warum ist deren Vorsprung in Sand versiebt?
Weißt dazu nun genaueres oder darfst diesbezüglich nix sagen?

Wilde Spekulation: Apple hat frühzeitig erkannt das sie nicht mehr so viele Chips von TSMC brauchen da das iPhone nicht mehr so gut läuft. TSMC konnte dadurch schneller mehr Kapazitäten für die Grafikchips von Nv benutzten. Nv hatte dann auch Glück das Gddr5X schon in Produktion war und konnten so die Karten schneller launchen...;D

Godmode

2016-05-17, 08:40:33

Es gab intern so manche Meinungsverschiedenheiten mit dem Gedanken ob man einen Titan mit vollen DP Faehigkeiten ueberhaupt verkaufen sollte. Selbst wenn sie den MSRP fuer einen P100/Titan bei $2k anlegen wuerden, haben sie immer noch ziemlich grosse Gewinn-Verlueste im Vergleich zu einer GP100 Tesla oder noch schlimmer Quadro. Wieso ein Tier mit =/>5.3 TFLOPs DP um "nur" $2000 verkaufen wenn man fuer eine Tesla =/> $3k bekommen kann bzw. fuer eine Quadro um die 5k?

Fall es einen 102 wirklich geben sollte, besteht zwar die Moeglichkeit von irgend einem Titan-Brummer aber wohl eher als treuer GM200/Titan Nachfolger und sonst nichts. Anders: in dem Fall sehe ich nur einen GP102/Titan und wenn sie den Preis laecherlich hoch anlegen moechten klatscht man eventuell dann auch 24GB Speicher drauf und gut ist es.

Sie könnten DP beim billigen GP100 einfach per BIOS oder Treiber einschränken, dann hätten sie auch kein Problem, GP100 für Spieler etwas günstiger zu verkaufen.

Sunrise

2016-05-17, 08:55:44

SRYSLY?!

Nachdem nVidia gerade die waren, die in diesem Punkt meilenweit hinterher hinkten?!
Du steckst gedanklich scheinbar weiterhin im letzten Jahrzehnt fest, anders kann man deine Beiträge wirklich nicht verstehen. Dass AMD bzgl. der Video-Fähigkeiten mal vor NV war ist schon seit ATI Allin-Wonder-Zeiten (dem Verkauf des Video-Teams inkl. weiterer GPU-Engineers an Qualcomm) und dem ArtX-Kauf nichtmehr so. PureVideo-IP hat jetzt seit Jahren immer Vorteile vor AMD.

Das wäre dir aber auch sofort klar, würdest du nur mal 1 Minute selbst recherchieren, scheinbar bist du hier nur noch angemeldet um deine Stammtisch-Sprüche abzulassen.

iuno

2016-05-17, 09:01:42

;D es ist halt wirklich so, dass Apple die Fertigung ihrer Geraete heruntergefahren hat ;D

Und die Beschraenkung der DP Leistung ist doch nun wirklich nichts neues.

Botcruscher

2016-05-17, 09:07:41

Sie könnten DP beim billigen GP100 einfach per BIOS oder Treiber einschränken, dann hätten sie auch kein Problem, GP100 für Spieler etwas günstiger zu verkaufen.
Biosflash oder Treiberhack und das Problem ist wieder da.

Godmode

2016-05-17, 11:13:33

Biosflash oder Treiberhack und das Problem ist wieder da.

Ich denke das es da schon Lösungen gäbe, die das verhindern. Naja egal, wir werden es noch bald genug erfahren, ob nun GP102 oder GP100 kommen wird.

Sunrise

2016-05-17, 11:32:20

Eine etwas konkretere Quelle wär schon nice. Am besten irgendein Screenshot des DXVA Checkers.
Ansonsten finde ich nirgendwo einen Hinweis, der deine These stützen würde.
Deine Quelle bei Wikipedia schreibt es doch schon, hast du dir die überhaupt angeschaut? Zudem steht das alles im Netz (auch bei Doom9) auch. Wenn du keine Lust hast zu recherchieren oder selbst etwas zu suchen, dann lass bitte das Rumdiskutieren. Mehr Fakten von dir wären schön.

Es steht doch ganz klar im Wikipedia-Purevideo-Link von dir drin:

1) Beispiel 1 - Tesla
GT200 VP2
GT21x VP4

2) Beispiel 2 - Fermi
GF100/104/106/108 VP4
GF119 (z.B. die GT520) VP5 (der erste VP mit 4K Hardware-Decoding)

3) Beispiel 3 - Maxwell
GM107/108/200/204 VP6
GM206 VP7 (der erste VP mit 10bit 4K HEVC 60fps-Decoding)

Es war also bei Fermi und auch vorher bei Tesla so, bei Kepler gab es dies nicht, Maxwell war wieder GM206 besser. Meine Aussage bleibt also bestehen, dass bei NV innerhalb der Chip-Familie bessere VPs auf einzelnen Chips verbaut wurden. Ja, es war vorher schon so. Und jetzt bitte mit Fakten Gegenteiliges von dir.

Ich finde das jetzt etwas albern...
Und statt darauf einzugehen und mal zu erklären, was für dich ein Checklistenfeature ist, machst du auf bockig?

Ich habe es aber selbst schon verstanden, für dich sind Checklistenfeatures Features die "kaum jemand nutzt". Das ist aber sicher keine Allgemeindefinition, denn ein "check list item/feature" ist einfach etwas, was sowieso jeder hat und deswegen macht man da mal einen Haken auf der Checkliste dran. NV liefert aber Features, die KEINER im PC-Bereich hat, genauso wie sie die ersten mit einem voll-kompatiblen HEVC 10bit 4K@60fps Decoder im X1 und in der GTX960 (GM206) waren. Und genau das distanziert NV vor der Konkurrenz. Nichtmal Intel, die mit ihrem extrem schnellen und ultra-low Power VP permanent Salamitaktik betreiben um Iterationen ihrer VP-Engine zu verkaufen, hat dies und Intel ist Marktführer und Multi-Milliarden schwer.

Man kann sich jetzt natürlich drüber streiten, wieviele das tatsächlich nutzen, aber darum ging es mir nicht. Mir ging es darum, dass es ohne HW-Support auch schlecht eine Infrastruktur geben kann und NV hier anführt.

Das VP-Team bei NV ist also immer schon einen Schritt weiter als "der aktuelle Standard" und das ist eine Leistung, die man nicht runterspielen muss. Aber auch die Display-IP ist absolute Spitze, mit bereits allen Features die für DP 1.4 nötig sind, da kommt die Industrie nichtmal hinterher (Monitore, zertifizierte Ausgabegeräte), NV ist schon weiter.

fondness

2016-05-17, 13:02:48

PureVideo-IP hat jetzt seit Jahren immer Vorteile vor AMD.

Das darfst du gerne näher ausführen, AMDs UVD/VCE-Einheiten waren nach dem was ich aus dem Kopf weiß selten im Nachteil vor Maxwell.

iuno

2016-05-17, 13:16:24

Ist aus dem Kopf auch schwer zu sagen, es gibt leider (afaik) auch keine uebersichtliche Tabelle (weder bei AMD noch NV), die einfach mal die Features und Unterschiede der verschiedenen de- und encoder auflistet. Bei AMD fehlt aber imho vor allem der Softwaresupport. Shadowplay ist wohl besser als der raptr Kram den AMD mit dem Treiber mitliefert, das gehoert laengst rausgeschmissen und abgeschafft.
OBS funktioniert zwar recht gut mit der VCE, das ist aber irgendwie kaum bekannt.

Imho sollte man sich da auch einfach mal eine eineitliche Schnittstelle einigen, gegen die Video Apps dann bauen koennen.
Es gibt ungefaehr zigtausend Videokonvertierer und Kram , ich kenne aber keinen, der die de- und encoder von Intel, AMD und Nvidia unterstuetzt.

Sunrise

2016-05-17, 13:24:27

Das darfst du gerne näher ausführen, AMDs UVD/VCE-Einheiten waren nach dem was ich aus dem Kopf weiß selten im Nachteil vor Maxwell.
Das darfst du gerne selbst recherchieren. :rolleyes::wink:

Es fängt wie iuno schon sagt schon an mit dem Software-API-Support bei PureVideo. Und hört auf mit den besseren HW-Fähigkeiten. Im Grunde ist die ganze Kette nicht nur weitaus mächtiger, sondern auch noch einfacher für Software-Entwickler zu nutzen.

Der NVEnc(oder) ist (nicht nur für Shadowplay, das auch auf den VP Zugriff hat und deshalb kein Performance-Verlust da ist) genauso wie NVs Implementation in DXVA(2) oder der NVCUDA-Decoder weitaus mächtiger als alles was AMD aktuell anbietet. Und das ist jetzt schon mehrere Jahre so. Erst Polaris wird zumindest die HW-Fähigkeiten wieder auf Standard bringen.

Was wie iuno auch geschrieben hat ein großes Manko ist, dass es einfach keinen Standard (von MS oder wie auch immer) für den Zugriff auf die VPs gibt, sodass man als Software-Entwickler die Encoder allesamt flexible auswählen kann. Das ist jedesmal eine Unmenge an Arbeit und Zeit, die hier reinfliest und deshalb gibt es hier fast nur noch Intel QuickSync- und NVEnc-Support. AMD bleibt sehr oft ganz außen vor.

iuno

2016-05-17, 13:33:40

Sunrise

2016-05-17, 13:44:57

Wie gesagt, ich sehe auch nicht, wo NVENC/PureVideo bei aehnlich altne Karten jeweils Welten vor VCE/UVD liegen, aber eine Uebersicht waere auch mir hoechst willkommen ;p Ich meine jetzt die Hardwarefeatures
Wenn ich Zeit hätte, würde ich gerne die Wikipedia-Artikel mal auf einen neuen Stand bringen, aber nur kurz (aus AMDs UVD-Wikipedia (https://en.wikipedia.org/wiki/Unified_Video_Decoder)):

Erst AMDs UVD 6.1: Codename "STONEY" wird zumindest was HEVC betrifft auf einem Level mit Maxwell sein, also inkl. 10bit Farbtiefe für HEVC-Main10-Support (Ultra HD Blu-Ray).

Aber AMD kann weiterhin kein VP9 per Hardware beschleunigen, während NV mit Pascal jetzt sogar Dual-Stream 4K@120fps-Support bei 320Mbps Bitrate! nachgezogen hat. Mal den 10bit Encoder nicht vergessen.

http://fs5.directupload.net/images/160515/o9qx4kyv.png
http://i.imgur.com/zAXoCHT.jpg

Sogar HDR-Support inkl. DP1.4 wurde nachgezogen, was AMD voraussichtlich zumindest teilweise aber auch liefern wird (wurde bereits in den Folien beschrieben).

Unicous

2016-05-17, 13:56:05

Ach Sunrise weiß schon wieder was AMD alles nicht oder nur teilweise mit Polaris bringen wird, Hut ab.:rolleyes:

Da 1.4 wohl lediglich ein "Software-Update" sein wird und AMD HDR schon seit Ende letzten Jahres hyped behaupte ich jetzt auch einfach mal, dass der Support nicht in Frage gestellt sein dürfte.

Und generell hat Intel auch deutlich nachgezogen und z.T. Support für neue codecs u.ä. deutlich vor AMD und Nvidia.

Dass Release-Zeiträume und Entwicklungsphasen mal wieder vollkommen ausgeklammert werden ist mal wieder typisch. Man sollte eben nicht zu viel nachdenken wenn man polemisiert. :uup:

fondness

2016-05-17, 14:00:54

Das darfst du gerne selbst recherchieren. :rolleyes::wink:

Ich habe jedenfalls keine Behauptung in den Raum gestellt. Wenn man dann nachfragt zu hören das darf man selbst recherchieren klingt jedenfalls nicht sehr überzeugend. Gerade wo du geschrieben hast, dass das schon seit Jahren so sein soll. NV hat hier in letzter Zeit mächtig Dampf gemacht, das ist richtig, aber das war auch lange Zeit umgekehrt und da hat es schlicht keinen Interessiert.

Sunrise

2016-05-17, 14:06:05

Ich habe jedenfalls keine Behauptung in den Raum gestellt. Wenn man dann nachfragt zu hören das darf man selbst recherchieren klingt jedenfalls nicht sehr überzeugend. Gerade wo du geschrieben hast, dass das schon seit Jahren so sein soll. NV hat hier in letzter Zeit mächtig Dampf gemacht, das ist richtig, aber das war auch lange Zeit umgekehrt und da hat es schlicht keinen Interessiert.
Steht doch drunter, wenn du des Lesens mächtig bist. Scheinbar hast du auch keine Lust, dir mal 5 Minuten Zeit zu nehmen, um das selbst zu recherchieren. Warum muss man dir immer alles vor die Füße werfen? Bist du selbst fähig Google zu benutzen?

Und nein, es ist schon länger so, dass AMD hinterherhinkt, die Führung hat AMD damals mit dem Verlassen ihres Core-VP-Teams abgegeben. Das weiß auch jeder, wenn man die entsprechende Software nutzt. Die GTX960 war und ist in HTPCs nicht umsonst so beliebt. Pascal wird dies fortführen.

Nochmal für dich:

Erst der UVD (6.1 oder größer) in Polaris wird das unterstützen, was NV seit Maxwell unterstützt, aber wohl voraussichtlich (wurde von AMD in den Slides nicht genannt) weder 10bit Encoder-Support, noch 12bit Decoder-Support bieten, und die Dual-Stream 4K@120fps-Fähigkeit bei bis zu 320Mbps Bitrate und sogar 8K-Support. Auch über VP9-Support wurde soweit ich weiß nichts gesagt. Ich lasse mich gerne überraschen.

illidan

2016-05-17, 14:08:02

Deine Quelle bei Wikipedia schreibt es doch schon, hast du dir die überhaupt angeschaut? Zudem steht das alles im Netz (auch bei Doom9) auch. Wenn du keine Lust hast zu recherchieren oder selbst etwas zu suchen, dann lass bitte das Rumdiskutieren. Mehr Fakten von dir wären schön.

Es ging um deine ursprüngliche Aussage, dass GK106 eine bessere VPU gehabt hätte. Wo hab ich denn Fermi erwähnt? Vielleicht solltest du selber erstmal genauer lesen...

Es war also bei Fermi und auch vorher bei Tesla so

Dass das irgendwann mal der Fall war, hab ich überhaupt nicht abgestritten.

Davon ab: Ja, NV ist AMD da schon lange voraus. Selbst der Dekoder auf Hawaii war noch absoluter Schrott und kann nicht mal 4k H.264.

Sunrise

2016-05-17, 14:10:22

Ja, NV ist AMD da schon lange voraus. Selbst der Dekoder auf Hawaii war noch absoluter Schrott und kann nicht mal 4k H.264.
Exakt. Und ich denke damit sollten wir die Diskussion auch beenden. Denn wer wirklich Interesse zu dem Thema hat, der liest sich ein Bisschen durchs Web. Ein paar Seiten hatte ich schon genannt, Wikipedia, Doom9 oder man probiert einfach mal diverse Software aus, die den NVEnc (die Dekoder sind größtenteils mit allen Features voll über DXVA verfügbar, lediglich bei 12bit-Support wird wohl noch ein Patch folgen müssen) unterstützen, da gibt es mittlerweile einiges, bei AMD ist kaum Entwickler-Interesse vorhanden, da läuft alles über DXVA und wenn das nicht reicht, dann hat man bei AMD Pech gehabt.

PS: GK106 hatte ich nachträglich editiert, deine Antwort kam einfach zu schnell. Das war zugegebenermaßen ein eher schlechtes Beispiel. ;)

fondness

2016-05-17, 15:49:41

Steht doch drunter, wenn du des Lesens mächtig bist. Scheinbar hast du auch keine Lust, dir mal 5 Minuten Zeit zu nehmen, um das selbst zu recherchieren. Warum muss man dir immer alles vor die Füße werfen? Bist du selbst fähig Google zu benutzen?

Schaffst du es eigentlich auch nur einen Beitrag zu schreiben ohne persönlich zu werden? Nein, ich bin zu dumm um Google zu benutzt, weiß du. Ernsthaft: Was soll der Blödsinn? Und ich habe zu Beginn nicht ohne Grund vor Maxwell geschrieben, weshalb der Beitrag darunter eben nicht auf meine Aussage passte. Aber wie auch immer, ich dachte eben du hättest da etwas mehr Infos wenn du schon eine solche Aussage raus lässt - sorry fürs nachfragen.^^

Undertaker

2016-05-17, 15:52:03

Noch gar keine Äußerungen zu den nunmehr bestätigten Daten der GTX 1070?

http://www.computerbase.de/2016-05/geforce-gtx-1070-1.920-shader-1.6-ghz-150-watt/

150 Watt TDP :up:

[...]
Die GTX 1070 sehe ich bei einer TDP von 140 bis 150 Watt wieder sehr sparsam werden.[...]

Das will ich sehen. Das teildeaktivieren bringt kaum Ersparnis, der Takt und damit die Spannung wird wohl ähnlich hoch liegen wie bei der GTX1080. Der GDDR5X ist sparsamer als GDDR5 (1,35 vs. 1.5V). Und du erwartest mindestens dieselbe Effizienz wie bei der GTX1080.

Vielleicht wenn NV bei der GTX1070 fast eine vollen Chip bringt und mit den Takt deutlich runter geht, aber das glaube ich nicht. Ansonsten würde mich alles unter 160W stark wundern.

Edit: Ah ja, gibt ja schon einen Review Thread.

illidan

2016-05-17, 15:54:30

Die TDP kann man mittels PT einstellen wie man lustig ist. Über den realen Verbrauch mit ungedrosselten Chips bei gleichem Takt sagt das wenig aus.

Godmode

2016-05-17, 15:55:00

Wir haben einen extra Thread für die 1070:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=572959&page=2

fondness

2016-05-17, 15:56:35

Noch gar keine Äußerungen zu den nunmehr bestätigten Daten der GTX 1070?

http://www.computerbase.de/2016-05/geforce-gtx-1070-1.920-shader-1.6-ghz-150-watt/

150 Watt TDP :up:

Edit: Ah ja, gibt ja schon einen Review Thread.

Ja du hattest Recht und ich unrecht, wenn auch am oberen Ende deiner Schätztung. Mir fällt kein Zacken aus der Krone das zuzugeben.

Undertaker

2016-05-17, 16:10:15

Die TDP kann man mittels PT einstellen wie man lustig ist. Über den realen Verbrauch mit ungedrosselten Chips bei gleichem Takt sagt das wenig aus.

Sinnvollerweise dürfte die TDP ab Werk natürlich so ausgelegt sein, dass die möglichen Boost-Taktraten mehr oder weniger stabil gehalten werden können. Insofern sehe ich da durchaus Aussagekraft dahinter. :)

StefanV

2016-05-17, 16:44:56

Das darfst du gerne selbst recherchieren. :rolleyes::wink:

DU hast es behauptet, also ist es auch DEINE Aufgabe, deine Behauptung zu belegen, nicht unsere.
WIR haben nur nachgefragt, wie du darauf kommst und jetzt drückst du dich vor deiner Pflicht.

Und somit kann man deine Beitrage schlicht als Glauben, ohne technische Basis behandeln - oder du lieferst endlich mal Beweise.

Zur API:

Schon mal was von DXVA gehört?!
DAS ist die Standardisierte Schnittstelle für Videobeschleunigung...
WARUM soll/muss man für jeden Mist irgendwas proprietäres ausführen?! Das als Vorteil zu verkaufen, ist allein schon daneben....

Ganz ab davon:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#UVD_6
Da siehst, dass Tonga z.B: 4kp60 unterstützt...

Und da sehe ich jetzt nicht, dass nVIdia so viel toller und besser wäre...

StefanV

2016-05-17, 16:47:17

Noch gar keine Äußerungen zu den nunmehr bestätigten Daten der GTX 1070?

http://www.computerbase.de/2016-05/geforce-gtx-1070-1.920-shader-1.6-ghz-150-watt/

150 Watt TDP :up:
Genau wie die 145W TDP der GTX970, die in der Praxis eher auf 250W eingestellt wird...

Kurz:
Behaupten kann man viel, wie das in der Praxis ausschaut zählt...
Und nur weil nVidia sagt, dass das 150W TDP sein soll, heißt das nicht, dass die Partner das auch implementieren...

illidan

2016-05-17, 16:48:23

Genau wie die 145W TDP der GTX970, die in der Praxis eher auf 250W eingestellt wird...

Willst du hier nicht mal etwas anderes als Unfug erzählen?

Sunrise

2016-05-17, 16:51:10

Ganz ab davon:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#UVD_6
Da siehst, dass Tonga z.B: 4kp60 unterstützt...

Und da sehe ich jetzt nicht, dass nVIdia so viel toller und besser wäre...
Ich hab dein restliches Blabla mal entfernt.

Der X1 hat 10bit 4K HEVC@60fps und VP9-HW-Decoding-Support, ebenso hat diesen VP GM206 erhalten, und beides kann AMD weiterhin nicht bieten.

AMD hat aktuell keinen Ultra HD Blu-Ray fähigen HW-Decoder.

AMDs VP-Features sind einfach immer mindestens einen Schritt hinterher.

Mehr Details gibts im Netz. Auch du darfst gerne mal Google bemühen...:wink:

dildo4u

2016-05-17, 16:55:27

Genau wie die 145W TDP der GTX970, die in der Praxis eher auf 250W eingestellt wird...

Kurz:
Behaupten kann man viel, wie das in der Praxis ausschaut zählt...
Und nur weil nVidia sagt, dass das 150W TDP sein soll, heißt das nicht, dass die Partner das auch implementieren...
Die Option die 150W Karte zu kaufen entfällt mit dem Launch der Custom Karten nicht.Und natürlich kann man auch jede Custom Karte per Software runter Regeln wenn man es möchte.

PCGH: Karten auf Basis des Referenzdesigns wurden ja sonst nach einigen Wochen von Partnerdesigns abgelöst. Warum ist das dieses Mal anders?

Lars Weinand: Bisher haben wir unsere Designs erstellt, um die Verfügbarkeit zum Launch sicherzustellen und damit die Lücke bis zu dem Tag zu schließen, an dem die Partnerdesigns verfügbar sind. Allerdings haben sich viele unserer Kunden, die das Premium Design und die einzigartigen thermischen Konstruktionen zu schätzen wussten, gewünscht, dass die Designs auch über die ganze Produktlebenszeit verfügbar sind. Deshalb haben wir die Founders Edition entwickelt. Sie ist ein Premium-Design und um sicherzustellen, dass sie über den kompletten Produkt-Lebenszyklus verfügbar ist, mussten wir einen Aufschlag gegenüber dem empfohlenen Retailpreis (MSRP) vornehmen

http://www.pcgameshardware.de/Nvidia-Pascal-Hardware-261713/Specials/Founders-Edition-Geforce-GTX-1080-1195206/

iuno

2016-05-17, 16:57:49

Zur API:

Schon mal was von DXVA gehört?!
DAS ist die Standardisierte Schnittstelle für Videobeschleunigung...
WARUM soll/muss man für jeden Mist irgendwas proprietäres ausführen?! Das als Vorteil zu verkaufen, ist allein schon daneben....

Bin mir jetzt gerade nicht sicher, ob ich damit gemeint bin, aber ich habe das Thema in die Diskussion gebracht, also antworte ich trotzdem mal.
DXVA ist afaik nur fuers decoding, nicht encoding und selbstverstaendlich nur unter Windows verfuegbar. Sofern ich nichts verpasst habe, ist dxva auch proprietaer. Eine multiplattform API analog zu OpenGL waere da imho angebracht, OpenMAX geht ja schon in die Richtung. Aber da gibt es ja nicht mal in der Linux Welt Einigung, wie soll man da auch noch Windows mit unter einen Hut bringen...

So muss halt jede Anwendung, die fuer mehrere Plattformen entwickelt wird auch noch ein eigenes high level Interface haben, das dann an DXVA oder entsprechend VDPAU usw. andockt.
Aber da sollten sich einfach mal alle an einen Tisch setzen, genauso wie bei Vulkan. Von mobil bis Desktop eine saubere gemeinsame API, mit der alle einverstanden sind und gut ist. Das ist doch so kein Zustand :rolleyes:

StefanV

2016-05-17, 16:59:46

Willst du hier nicht mal etwas anderes als Unfug erzählen?
http://www.tomshardware.de/geforce-gtx-970-power-target-boost-analysis,testberichte-241652-2.html
http://www.tomshardware.de/nvidia-geforce-gtx-970-gtx-980-roundup-vergleichstest,testberichte-241658.html

Die meisten 970er in dem Test sind auf 200W eingestellt, manche auch auf 250W.

dildo4u

2016-05-17, 17:02:05

Es zwingt dich niemand eine Karte mit so einem OC Potenzial zu kaufen.

Gigabyte baut auch sowas:

https://geizhals.de/gigabyte-geforce-gtx-970-mini-gv-n970ix-4gd-a1390330.html?hloc=at&hloc=de

illidan

2016-05-17, 17:05:07

Wenn die MSI 980 mit 1,3Ghz maximal 200W zieht, braucht die 970 garantiert keine 250W für irgendwelche realistischen OC-Werte.

AnarchX

2016-05-17, 17:44:15

Entweder GP106 ist doch etwas anders als GP104 oder man hat bei GeForce GP104 den FP16 deaktiviert, damit man kein P100-Käufer verliert.

Nakai

2016-05-17, 17:51:04

Ich gehe davon aus, dass GP104/6 keine MixedPrecision hat. Braucht man nicht und bläht alles auf. GP100 ist für DeepLearning gedacht.

Godmode

2016-05-17, 17:59:25

Ich gehe davon aus, dass GP104/6 keine MixedPrecision hat. Braucht man nicht und bläht alles auf. GP100 ist für DeepLearning gedacht.

Für GP104 ist das in den Reviews zu lesen, somit wird es auch beim 6er so sein.

AnarchX

2016-05-17, 18:06:34

Ich gehe davon aus, dass GP104/6 keine MixedPrecision hat. Braucht man nicht und bläht alles auf. GP100 ist für DeepLearning gedacht.

Woher soll aber PX2 seine 24 DL TOPS sonst her haben? Immerhin hatte der GM20A in Tegra X1 ja auch schon gepackte FP16-OPs.
Da es für Spieler wohl möglich nicht so viel bringt, könnte man es deaktiviert haben. Eine Tesla P50 hat dann wohl ihre 16 TFLOPs FP16.

Schnoesel

2016-05-17, 18:10:27

Mal was anderes. Wenn schon die 1080 mit der Bandbreite Probleme hat ist die Vermutung GP102 + GDDRX5 wohl dahin?! Ah das Interface vergessen ich doof ...

AnarchX

2016-05-17, 18:11:51

GDDR5X hat noch 60% Taktpotential und bis 2017 hat man da wohl durchaus die 12Gbps erreicht.

Digidi

2016-05-18, 01:05:05

Das ist falsch. QRQ beschreibt eine Möglichkeit der Priorisierung von Aufgaben für die asynchrone (und gleichzeitige, konkurrente) Ausführung. Daß das nichts miteinander zu tun hätte, ist ziemlich absurd.
Ob der asynchrone Timewarp bei VR über Preemption oder QRQ gelöst wird (und auch, wie performant Preemption funktioniert) ist nicht völlig belanglos. Zumindest für die Gesamtperformance. Mit QRQ (also ohne zwischenzeitlichen Leerlauf) kommt eine höhere Gesamtperformance heraus (also mehr fps). Und je schneller die Preemption ist, desto niedriger wird der Rückstand (mit im Extremfall vernachlässigbarem Rückstand).
NV spricht für ihre Preemption-Implementation von Latenzen im Bereich von ein paar Hundert Mikrosekunden. Das ist für den Timewarp bei VR, der einmal pro Frame stattfindet wohl absolut akzeptabel (vorher hat nV den Entwicklern empfohlen, die Ausführungszeit von Drawcalls unter einer Millisekunde zu halten, damit man dann den Timewarp einschieben kann). Man erreicht das jetzt also mindestens genauso gut (besser, weil es eben reproduzierbar und planbar funktioniert), ohne dem Entwickler diese Vorgabe machen zu müssen. Aber was ist mit Szenarien, wenn wild abwechselnd hunderte Compute und Grafikcalls pro Frame (statt nur einer für den ATW) abgesetzt werden? Selbst hundert µs pro Switch sind hundert µs. Wenn das hundert Context Switches pro Frame sind (die der Treiber nicht durch Umordnen umgehen kann), kommen da irgendwann merkliche Zeitbeträge pro Frame heraus. Pascals zusätzlicher Vorteil gegenüber Maxwell in diesem Zusammenhang scheint jetzt zu sein, daß nun jeder SM unabhängig und dynamisch zwischen Compute und Grafik schalten kann, man also diese hundert µs (oder wieviel genau es denn nun wirklich sind) nicht für den Gesamtchip verloren gehen, sondern nur für die Anzahl an SMs, auf denen das dann laufen soll. Wieviel das in der Praxis letztendlich ausmacht, wird man sehen müssen. Ich bin aber zuversichtlich, daß wenn der Entwickler ein wenig acht gibt, der Verlust im überschaubaren Rahmen bleiben dürfte.
Ebenfalls über Asynchronous Compute. Prioritäten gibt es da auch schon. Es gibt lediglich weniger Queues und die Prioritäten sind nicht ganz so flexibel setzbar. Aber gehen tut es bereits mit GCN 1.0.

Die "QRQ" ist lediglich ein Label, was einen Aspekt des AC bei GCN griffig beschreiben soll. Im Prinzip kann man wählen, welche Priorität welche Tasks bekommen sollen. Das kann die gleiche für Grafik- und Computeshader sein, oder eben auch eine mehr oder minder starke Bevorzugung von entweder Grafik (Computeshader laufen dann gewissermaßen im Hintergrund und nutzen dann bevorzugt die Pipelinebubbles der Grafikshader) oder eben Compute (was bei QRQ dargestellt wird, Grafik nutzt die Pipelinebubbles der Computeshader). Im Prinzip ist die GCN-Hardware sogar noch flexibler. Man kann nicht nur für jeden Shader/Kernel über die jeweilige Queue eine Priorität setzen, die Hardware kann für jede einzelne Wavefront eines Kernels Prioritäten setzen (individuell im Shadercode, seit GCN 1.0 schon). Das wird aber zugebenerweise wohl bisher praktisch nicht benutzt.

@Gipsel
Hat AMD eigentlich auch Graphic und Compute preemption?
Nach Nvidias Aussage ist Nvidia die einzige Firma die auch Graphic preemption kann.

BlacKi

2016-05-18, 01:15:00

Die meisten 970er in dem Test sind auf 200W eingestellt, manche auch auf 250W.
meine 970 steht auf 150w, dieser gebe ich 20%(180w) damit sie 4000mhz und 1450mhz laufen kann. aus der dose zieht der ganze pc knapp unter 300w in spielen, mit furmark und prime zieht die kiste(ja die boost raten sind dann niedriger tdp aber gleich) keine 350w. wo soll die 970 denn 200w+ ziehen wenn der proz. alleine schon 140w zieht? die tdp angaben passen +-5% genau.

illidan

2016-05-18, 01:19:11

Die fällt in extrem stromfressenden Spielen aber sicher unter 1,4Ghz, wahrscheinlich sogar auf 1350.

Nightspider

2016-05-18, 07:04:17

Ich kopiers mal aus dem GTX1080 Thread rein:

VR-Benchmarks ohne Simultaneous Multi-Projection:

http://www.pcper.com/files/imagecache/article_max_width/review/2016-05-14/VR-overhead.png

http://www.pcper.com/reviews/Graphics-Cards/GeForce-GTX-1080-8GB-Founders-Edition-Review-GP104-Brings-Pascal-Gamers/VR-Te

In this translation of the data, we can see that for the evaluated scene, the 980 had just over 30% headroom, meaning that it could theoretically render a scene 30% more complex before its scene render rate drops to 45 FPS. The Fury X sat a little closer to the 980 Ti, which had 64% headroom. The 1080 takes a huge jump over all other cards and could maintain 90 FPS renders with a scene more than twice as complex. More importantly to note here is that the 1080 turned in those numbers *without* Simultaneous Multi-Projection (it is not implemented in SteamVR at the time of this testing)

ebenso hat diesen VP GM206 erhalten,

Uhh wow, GM206 kam ja auch erst letztes Jahr und ist Nvidias einziger Chip mit diesen Fähigkeiten. :rolleyes:

und beides kann AMD weiterhin nicht bieten.

Und mit "weiterhin" meinst du die alten Karten, obwohl in 2 Wochen die neuen Karten kommen? :confused: :freak: :rolleyes:

AMDs VP-Features sind einfach immer mindestens einen Schritt hinterher.

Weil AMD einfach viel weniger Chips pro Zeit rausbringt als Nvidia.

Deswegen würde ich hier kein großes Fass aufmachen. :rolleyes:

Selbst Nvidias 1100 Euro Titan X kann nicht das was GM206 kann.

igg

2016-05-18, 08:24:21

Gibt es eigentlich irgendwelche Hinweise auf einen GP102? Wenn P10 unter der GTX1070 landet und Vega11/10 sich um 1070/1080 herum bewegen, gibt es für Nvidia da eigentlich kaum eine Notwendigkeit. Dann einfach eine GTX1080+ mit schnellerem GDDR5X.

Locuza

2016-05-18, 09:11:47

@Gipsel
Hat AMD eigentlich auch Graphic und Compute preemption?
Nach Nvidias Aussage ist Nvidia die einzige Firma die auch Graphic preemption kann.
Es stand jedenfalls mal früher auf der HSA-Roadmap dafür:
http://scr3.golem.de/screenshots/1311/AMD_Kaveri_Vorab/thumb620/AMD-Kaveri-04.jpg

Der Compute-Context-Switch wird auf jeden Fall im ISA-Manual als wichtige Neuerung gelistet:
Compute kernel context switching.
- Compute kernels now can be context-switched on and off the GPU.
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/07/AMD_GCN3_Instruction_Set_Architecture.pdf

Irgendeine Form der Preemption wird auch schon lange unterstützt:
http://cdn.wccftech.com/wp-content/uploads/2015/04/3.png

Ich würde den Brei jetzt nicht zu heiß essen, ohne Micro-Benchmark kommt man sehr wahrscheinlich auf keine seriösen Aussagen darüber, wie gut/schlecht eine GPU den Workload wechseln oder mischen kann.
Bzw. ein grobes Urteil ist möglich, aber auf der Detailebene wird es schwer.

Gibt es eigentlich irgendwelche Hinweise auf einen GP102? Wenn P10 unter der GTX1070 landet und Vega11/10 sich um 1070/1080 herum bewegen, gibt es für Nvidia da eigentlich kaum eine Notwendigkeit. Dann einfach eine GTX1080+ mit schnellerem GDDR5X.
Vega10 wäre aus meiner Sicht ziemlich enttäuschend, wenn er nicht wenigstens als voller Chip ein gutes Stück über der 1080 landet.
Es sind 4096 ALUs mit 512 GB/s HBM2 Durchsatz, dass Ding sollte schon etwas packen wenn AMD nicht gerade bei 1 Ghz takten muss.

Complicated

2016-05-18, 09:59:54

The 1080 takes a huge jump over all other cards and could maintain 90 FPS renders with a scene more than twice as complex. Das ist ja mal völliger Quatsch "twice as complex"als wer?
Laut Folie rendert eine 1080 einen Frame in 90FPS wie alle anderen auch. Dann kommen bei den jeweiligen Karten noch Reserven dazu. 30% bei der 980, 50% bei der Fury und eben etwas über 100% bei der 1080. Das sind 25% mehr Rechenleistung der 1080 gegenüber der Fury in dieser Grafik -> oder 59% mehr "Headroom" für komplexere Renderarbeit, nachdem beide schon die 90 FPS überschritten haben.

Eine clevere Formulierung die eigentlich überhaupt keine Bezuggröße zur realen Leistung hat und dennoch nicht gelogen ist. Der doppelte "Headroom" übersetzt sich in 25% mehr Leistung gegenüber der Fury.

Sunrise

2016-05-18, 10:11:55

Uhh wow, GM206 kam ja auch erst letztes Jahr und ist Nvidias einziger Chip mit diesen Fähigkeiten. :rolleyes:

Nö, der X1 konnte es vorher schon. GM206 bekam dann den identischen VP ab. Pascal setzt noch eine gehörige Schippe drauf, vor allem beim Encoding, DP 1.4/HDR und Dual-Stream bei 4K@120fps mit bis zu 320Mbps. Das Ding wirst du kaum ans Limit treiben können.

Und mit "weiterhin" meinst du die alten Karten, obwohl in 2 Wochen die neuen Karten kommen? :confused: :freak: :rolleyes:
Ja, weiterhin nicht auf dem Stand vom Maxwell VP, z.B. weiterhin kein VP9-Decoder. Pascal hat jetzt sogar 10bit Encoding (für Spiele/Shadowplay mit HDR z.B., oder Transcoding von Videos, um Bitrate zu sparen) usw. AMD wird den 10bit HEVC@4K und HDR-Teil nachziehen, ebenso das 4K-Encoding aber Pascal baut diese Führung eben wieder aus, bzw. hält sie aufrecht.

Weil AMD einfach viel weniger Chips pro Zeit rausbringt als Nvidia
Das ist ein Grund, ja, aber als Endkunde kaufe ich eben das besser ausgestattete Produkt, vor allem wenn ich persönlich Verwendung dafür habe. Und HTPCs usw. sind eben schon seit einer ganzen Weile sehr beliebt.

Deswegen würde ich hier kein großes Fass aufmachen. :rolleyes:
Dafür ist das Forum da, zum Diskutieren und Austauschen, am besten auch mit sinnvollen und nachweisbaren Inhalten.

Selbst Nvidias 1100 Euro Titan X kann nicht das was GM206 kann.
Was mich persönlich schon immer gestört hat. Denn ohne GPU-Last zu verbraten kannst du den VP voll nutzen, daher ist Shadowplay ja eben auch so gut nutzbar.

Gipsel

2016-05-18, 12:01:43

@Gipsel
Hat AMD eigentlich auch Graphic und Compute preemption?
Nach Nvidias Aussage ist Nvidia die einzige Firma die auch Graphic preemption kann.
Vermutlich meinen die da als einzige auf "pixel level" oder so, denn Locuza hat schon recht, daß AMD ebenfalls seit längerem davon spricht, preemption irgendwie zu können. Sie betonen es eben nicht so (es gibt wenig konkrete Angaben dazu, wie z.B. die involvierten Latenzen), und stellen richtigerweise fest, daß Kontext-Switches mitsamt Preemption im Normalfall unnötig werden, wenn man schlicht einen anderen Kontext gleichzeitig ausführen kann (und gegebenenfalls mit höherer Priorität versehen, falls es schnell fertig werden soll). Nach den Beschreibungen kann man stark vermuten, daß die involvierte Latenz für Preemption (also das komplette Runterschmeißen eines Shaders von einer CU und Auslagern des Kontextes in L1/L2/RAM) bei AMD im Normalfall höher ist als für die simultane Ausführung mitsamt QRQ. Und AMD hat auch Recht damit, daß die Gesamtperformance bei einer simultanen Ausführung höher sein sollte als mit Preemption, weil man eben dieses Auslagern und den damit verbundenen Performanceverlust spart.

Um Locuzas Punkt mit einem Zitat aus einem AMD-Whitepaper zu unterstützen:
This architecture is designed to increase utilization and performance by filling gaps in the pipeline, where the GPU would otherwise be forced to wait for certain tasks to complete before working on the next one in sequence. It still supports prioritization and pre-emption when required, but this will often not be necessary if a high priority task is also a relatively lightweight one.

Nightspider

2016-05-18, 12:19:39

Nö, der X1 konnte es vorher schon.

Wen interessiert X1. Mir ging es um Grafikchips. Set top boxen interessieren doch (fast) kein Schwein.
Hier gehts um PC (Gaming/Aufzeichnung) und da ist nun mal GM206 der einzige Grafikchip von NV bisher, der dieses Featureset bietet.

Und wer viel Grafikleistung braucht ist mit einer GTX960 auch mehr als schlecht beraten.

Ailuros

2016-05-18, 12:31:42

Wen interessiert X1.

Nintendo anscheinend (und ja AnarchX Du hattest womoeglich recht....).

robbitop

2016-05-18, 13:09:32

Für NX wäre der X1 aber immernoch irgendwie zu schlapp. Für einen Handheld hingegen sehr nett.

Complicated

2016-05-18, 14:16:20

Vermutlich meinen die da als einzige auf "pixel level" oder so, denn Locuza hat schon recht, daß AMD ebenfalls seit längerem davon spricht, preemption irgendwie zu können. Sie betonen es eben nicht so (es gibt wenig konkrete Angaben dazu, wie z.B. die involvierten Latenzen), und stellen richtigerweise fest, daß Kontext-Switches mitsamt Preemption im Normalfall unnötig werden, wenn man schlicht einen anderen Kontext gleichzeitig ausführen kann (und gegebenenfalls mit höherer Priorität versehen, falls es schnell fertig werden soll). Nach den Beschreibungen kann man stark vermuten, daß die involvierte Latenz für Preemption (also das komplette Runterschmeißen eines Shaders von einer CU und Auslagern des Kontextes in L1/L2/RAM) bei AMD im Normalfall höher ist als für die simultane Ausführung mitsamt QRQ. Und AMD hat auch Recht damit, daß die Gesamtperformance bei einer simultanen Ausführung höher sein sollte als mit Preemption, weil man eben dieses Auslagern und den damit verbundenen Performanceverlust spart.

Hier auch in Grafik aufgearbeitet und von AMD direkt auf deren Seite ausgeführt und deine Vermutung bestätigt:
https://community.amd.com/servlet/JiveServlet/showImage/38-1310-104752/pastedImage_5.png
In order to meet this requirement, time-critical tasks must be given higher priority access to processing resources than other tasks. One way to accomplish this is using pre-emption, which works by temporarily suspending other tasks until a designated task can be completed. However the effectiveness of this approach depends on when and how quickly an in-process task can be interrupted; task switching overhead or other delays can impact responsiveness, and potentially manifest as stuttering or lag in graphics applications.

To address this problem, we have introduced the idea of a quick response queue. Tasks submitted into this special queue get preferential access to GPU resources while running asynchronously, so they can overlap with other workloads. Because the Asynchronous Compute Engines in the GCN architecture are programmable and can manage resource scheduling in hardware, this feature can be enabled on existing GPUs (2nd generation GCN or later) with a driver update (https://community.amd.com/external-link.jspa?url=http%3A%2F%2Fsupport.amd.com%2Fen-us%2Fdownload)Ab Generation GCN2 aktivierbar mit Treiberupdate.

iuno

2016-05-18, 14:28:24

Das ist nicht einfach per Update "aktivierbar", sondern steht dadurch erstmal zur Verfuegung. Es muss dann aber schon auch noch softwareseitig explizit so gemacht werden.

Mich wuerde aber auch mal interessieren, wie AMD die zugeteilten Ressourcen fuer einen laufenden Grafiktask "herunternehmen" kann... @Gipsel to the rescue, im AMD Thread? ;p

Hübie

2016-05-18, 14:57:49

Spekulation meinerseits dazu: Die Instruktion muss ja irgendwie mit 4 weiteren Bits "getagged" sein und ich vermute einfach, dass Graphics die priority bei 2 hat. Kommt nun ein computeshader mit 3 oder 4 (waren doch 5 priorities, oder?) dann wird einfach kein graphics gescheduled, sondern nur die welche größer der restlichen compute mit 0 oder 1 ist.

Beispiel: 5 instructions mit 0000, 0001, 0010, 0011 und 0100. 0010 ist immer graphics. Dann werden 0011 und 0100 resourcen zugewiesen, was übrig bleibt bekommt 0010 und der rest landet entweder in der queue hinter 0011 und 0100 oder werden bei noch freien resourcen ebenfalls gemappt. :biggrin:

Edit: Diese "tags" müssten doch bei der skalar-unit landen oder?

Complicated

2016-05-18, 15:01:35

Echt jetzt...es ist nicht "einfach per Update aktivierbar"? Was muss denn da noch softwareseitig gemacht werden "explizit"?
Und was heisst deiner Meinung nach dieser letzte Satz dann?
Because the Asynchronous Compute Engines in the GCN architecture are programmable and can manage resource scheduling in hardware, this feature can be enabled on existing GPUs (2nd generation GCN or later) with a driver update

iuno

2016-05-18, 15:10:09

Dass die Hardware das scheduling uebernimmt, was sonst?
Die Prioritaeten muessen trotzdem vergeben und die Taks in den passenden Queues mit den neuen APIs verwaltet werden. Es ist ja gerade der Sinn der Sache, es dem Entwickler in die Hand zu geben. Man aktiviert ja nicht auf gut Glueck ueberal QRQ und arbeitet fortan alle Compute Tasks einfach mal mit hoeherer Prioritaet ab, das waere doch voellig absurd.
Der Scheduler vergibt ja nicht die Prioritaeten sondern uebernimmt die Zuweisung der Arbeit auf die Einheiten unter Einbeziehung der gesetzten Prioritaeten, sodass alles moeglichst effizient abgearbeitet wird.

Hübie

2016-05-18, 15:34:11

Zumal Treiber und App das ja auch verstehen bzw. beherrschen müssen. R600 hatte auch einen Tesselator in Hardware. Wurde nie genutzt. QRQ war bisher halt auch nicht aktiv (warum auch immer).

Troyan

2016-05-18, 15:37:20

Es wurde nicht genutzt, weil QRQ nur für bestimmte - hoch priorisierte Aufgaben - sinnvoll ist.

Für normales "Async-Shaders", wo man also eine komplette Auslastung der Einheiten haben will, ist es kontraproduktiv und natürlich langsamer.

nVidias Preemption ist mit Pascal dann auch besser als QRQ, da nVidia schneller und viel gradliniger Arbeit wechseln und beenden kann.

Hübie

2016-05-18, 15:39:44

Ja wir lassen dich jetzt mal in dem Glauben und fertig. :rolleyes:

fondness

2016-05-18, 15:58:39

Es wurde nicht genutzt, weil es bis jetzt nicht zur Verfügung stand. Ansonsten dürfte das in vielen Fällen der beste AsyncCompute-Mode sein.

Dan Baker erwartet sich zB weitere 3-5% mehr Leistung auf GCN mit QRQ:
https://twitter.com/dankbaker/status/714617950288945153

Und AsyncCompute bringt bereits jetzt ordentlich Mehrleistung auf GCN.

Hübie

2016-05-18, 16:11:19

Hä? Die Hardware hatte es doch schon lange. Das ist es ja was ich meine. Man hats erst jetzt "aktiviert". Warum auch immer...

illidan

2016-05-18, 16:14:16

Es war vorher ohne LL-API ja eh nicht nutzbar. Und bei AMD mahlen die Mühlen auf Software- halt schon mal asynchron zur Hardware-Seite. :freak:

Hübie

2016-05-18, 16:29:06

Haha. Der war gut :D
Ich weiß aus dem Kopf gar nicht wie hoch der Gewinn durch AC auf der FuryX war, aber afair nicht mehr als 15%. Andererseits weiß ich auch nicht wie hoch der Aufwand ist. Kann sich also lohnen, muss aber nicht. Grundsätzlich ist es ein nützliches Feature.

Edit: Ups hier is ja der Pascal-Thread X-D

iuno

2016-05-18, 16:36:40

Man haette es schon irgendwie nutzen koennen, mit Mantle oder herstellerspezifischen Erweiterungen. AMD hat aber nicht die Moeglichkeiten, mit Gewalt was durchzudruecken und die Entwickler sind verstaendlicherweise auch nicht bestrebt, das zu tun, wenn es nachher nur von jedem 4. Kunden genutzt werden kann.

fondness

2016-05-18, 16:55:23

Hä? Die Hardware hatte es doch schon lange. Das ist es ja was ich meine. Man hats erst jetzt "aktiviert". Warum auch immer...

Nichts anderes habe ich ja gesagt. Warum es erst jetzt "aktiviert" wurde? Weil man das eben auch erst mal implementieren muss, ist ja nicht so, als wäre DX12 schon Jahre am Markt.

Complicated

2016-05-18, 17:06:43

Man aktiviert ja nicht auf gut Glueck ueberal QRQ und arbeitet fortan alle Compute Tasks einfach mal mit hoeherer Prioritaet ab, das waere doch voellig absurd.
Zumal Treiber und App das ja auch verstehen bzw. beherrschen müssen. R600 hatte auch einen Tesselator in Hardware. Wurde nie genutzt. QRQ war bisher halt auch nicht aktiv (warum auch immer).
Ok lesen wir den Satz nochmal:
Because the Asynchronous Compute Engines in the GCN architecture are programmable and can manage resource scheduling in hardware, this feature can be enabled on existing GPUs (2nd generation GCN or later) with a driver updateAlso Asynchronous Compute Engines können Hardware Scheduling seit der 2. Generation von GCN. Das QCQ Feature kann aktiviert werden mit dem verlinkten Treiber Update. Ich gehe mal davon aus dass dieser Treiber das dann auch "versteht". Erledigt.

Wie kommt man darauf, dass ein Hardware Scheduler nicht in der Lage ist die Priorisierungen vorzunehmen? Welche Software Anpassungen wären denn von Nöten? Gibt es denn irgendeinen Hinweis auf irgendeinen Fetzen Code der benötigt wird um QCQ zu nutzen? Irgendeine Intruktion die sich im Code ändern muss? Das würde mich nun doch interessieren wo softwareseitig QCQ alles Arbeit verursacht.

Gipsel

2016-05-18, 18:49:15

Wie kommt man darauf, dass ein Hardware Scheduler nicht in der Lage ist die Priorisierungen vorzunehmen? Welche Software Anpassungen wären denn von Nöten? Gibt es denn irgendeinen Hinweis auf irgendeinen Fetzen Code der benötigt wird um QCQ zu nutzen? Irgendeine Intruktion die sich im Code ändern muss? Das würde mich nun doch interessieren wo softwareseitig QCQ alles Arbeit verursacht.Man muß auch einem Hardware-Scheduler sagen, was denn nun der Task ist, der möglichst schnell abgearbeitet werden soll, genau wie man auch bei Preemption festlegen muß, welcher Task für welchen anderen unterbrochen werden soll. Dies kann entweder über ein Spielprofil im Treiber erfolgen (was dann aber mit viel Aufwand seitens AMD und nV verbunden ist und dann wieder dazu führt, daß man bei einem neuen Spiel eventuell erstmal auf ein passendes Update warten muß), oder man läßt den Spieleentwickler einfach selber festlegen, welche Tasks er gerne bevorzugt abgearbeitet haben will (egal ob per Preemption oder über die QRQ).

Allerdings existiert z.B. mit DX12 bereits die Möglichkeit, einer Command Queue eine Priorität zuzuweisen (siehe hier (https://msdn.microsoft.com/de-de/library/windows/desktop/dn986723(v=vs.85).aspx)). Das ist zwar relativ limitiert (nur zwei Prioritäten: normal und hoch), aber es ist schon mal besser als nichts. NV und AMD können dies also im Prinzip bereits mit dem existierenden DX12 irgendwie auf die Hardware mappen (z.B. in einer Compute Queue mit hoher Priorität dürfen die Tasks andere Aufgaben preempten bzw. bekommen über QRQ Vorrang eingeräumt). Sicherlich wäre für bestimmte Aufgaben noch ein feiner abgestimmtes Prioritätssystem sinnvoll (bei AMD gibt es z.B. 4 Queue-Prioritäten [also pro Shader bzw. Kernel] + 4 pro Wavefront-Prioritäten [per Shadercode für jede einzelne Wavefront getrennt setzbar]) und wie das bei nV gehandhabt wird, erfahren wir vielleicht noch. Aber für Preemption bzw. allgemein für den asynchronen Timewarp bei VR, über den man in letzter Zeit so viel liest, reichen im Prinzip genau diese beiden Prioritäten: normal preemptet laufende Shader nicht, hoch tut es.

Complicated

2016-05-18, 19:06:17

Danke für die Ausführung. Doch denke ich, dass dies den Sonderfall der ACE Einheiten in der GCN-Architektur nicht beschreibt. Aus dem Whitepaper:
https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf

Each ACE fetches commands from cache or memory and forms task queues, which are the starting point for scheduling. Each task has a priority level for scheduling, ranging from background to real-time. The ACE will check the hardware requirements of the highest priority task and launch that task into the GCN shader array when sufficient resources are available

[...]

While ACEs ordinarily operate in an independent fashion, they can synchronize and communicate using cache, memory or the 64KB Global Data Share. This means that an ACE can actually form a task graph, where individual tasks have dependencies on one another. So in practice, a task in one ACE could depend on tasks on another ACE or part of the graphics pipeline. The ACEs can switch between tasks queue, by stopping a task and selecting the next task from a different queue. For instance, if the currently running task graph is waiting for input from the graphics pipeline due to a dependency, the ACE could switch to a different task queue that is ready to be scheduled. The ACE will flush any workgroups associated with the old task, and then issue workgroups from the new task to the shader arrayDemnach werden die Priorisierungen und switches durch die in der Hardware verbaute Logik erstellt. Dort ist noch etwas detaillierter beschrieben was du auch beschrieben hast ab Seite 11.

Hübie

2016-05-18, 19:20:27

An welcher Stelle genau liest du da jetzt dass die Hardware die priority vergibt? :|

Complicated

2016-05-18, 19:30:32

The ACEs can switch between tasks queue, by stopping a task and selecting the next task from a different queue. For instance, if the currently running task graph is waiting for input from the graphics pipeline due to a dependency, the ACE could switch to a different task queue that is ready to be scheduled.Hier greift die ACE Einheit eigenständig ein wenn Abhängigkeiten erkannt werden und optimiert das Scheduling: es ändert die Prioritäten um die Auslastung zu optimieren. Ich empfehle den gesamten Abschnitt im Whitepaper zu lesen, damit das nicht hier alles zitiert werden muss.

scully1234

2016-05-18, 20:40:18

Was ist das? Die GTX 1070 oder 60

http://ranker.sisoftware.net/show_run.php?q=c2ffcdf4d2b3d2efdce4dde4d5e5c3b18cbc9aff9aa797b1c2ffc7&l=en

Unicous

2016-05-18, 20:42:33

Eine nVidia GPU mit AMD PCI-ID. :uup:

scully1234

2016-05-18, 20:53:51

mit AMD PCI-ID. :uup:

Mir sagt die Codierung nichts als Außenstehender

Nakai

2016-05-18, 21:13:05

Dat is P10 my friend.

Hoffentlich der Kleine.;)

scully1234

2016-05-18, 21:53:47

Hier dann noch ein paar Mutmaßungen ueber GP102

horn 12

2016-05-18, 22:03:15

Sieht erstaunlicherweise recht realistisch aus und würde in etwa gute 40% auf eine GTX 1080 draufpacken, vor Allem und enormer Vorteil: ---->> OHNE Bandbreitenlimitierung
HBM 2 ist dann wohl komplett links liegen lassen worden außer GP100.

Titan "XY" hebt man sich möglicherweise für "Vega 11" auf.

Nakai

2016-05-18, 22:07:40

GP100 braucht HBM2 für Deep Learning Zeug (sehr viel Read).

GP102 ist über 52% größer als GP104 aber mit genau 50% mehr Einheiten durchgängig. Das Ding sollte definitiv fast 50% auf GP104 draufpacken, weil Bandbreite und so.

Godmode

2016-05-18, 22:12:29

Jop, das sieht leider sehr vernünftig aus. Damit ich dann meine Leistungssteigerung bekomme, muss das Ding doch wieder mit 2 GHz laufen. Wozu man 24 GB VRAM braucht, muss mir aber erstmal wer erklären :ulol:

phoenix887

2016-05-18, 22:14:06

Effe

2016-05-18, 22:17:44

Wozu man 24 GB VRAM braucht, muss mir aber erstmal wer erklären :ulol:
2018/19(?) mit Volta kommen dann 48GB?
24GB sind lächerlich viel. Ist mit GDDR5X nicht auch krumme Bestückung möglich? Also 16GB würde für eine Titan doch dicke reichen.

Godmode

2016-05-18, 22:19:38

2018/19(?) mit Volta kommen dann 48GB?
24GB sind lächerlich viel. Ist mit GDDR5X nicht auch krumme Bestückung möglich? Also 16GB würde für eine Titan doch dicke reichen.

Ich wäre auch mit 16 GB mehr als zufrieden, vor allem würde das den Preis der Karte nicht unnötigerweise in die Höhe treiben.

kdvd

2016-05-18, 22:22:57

Wozu man 24 GB VRAM braucht, muss mir aber erstmal wer erklären :ulol:

Die 1080Ti als GP102 Salvage bekommt 12 und die nächste runde Zahl ist dann erst wieder die 24.
Ist doch logisch. ;)

scully1234

2016-05-18, 22:23:20

. Wozu man 24 GB VRAM braucht, muss mir aber erstmal wer erklären :ulol:

Fuer die ''Billigheimer'' die keine Quadro fuer den Workflow nutzten wollen/koennen:tongue:

Sunrise

2016-05-18, 22:37:24

Diese Tabelle hätte ich mit meinen Spekulationen von +50% mehr Einheiten, 50% größerem SI und etwa 450mm^2 kaum besser machen können. Die 250W passen auch. Um die Titan voll auszufahren sollten es aber schon 12Gbps-Module sein.

24GB allerdings...naaaaajaaa... eher nicht.

Dennoch: 4K wir kommen...

Der_Korken

2016-05-18, 22:58:18

Bei 384bit SI können es keine 16GB sein. Es sei denn, man verbaut wieder sowas krummes wie bei der GTX660Ti (?) mit 2GB@192bit SI. Allerdings gab es irgendwann mal eine Meldung, dass auch Speicherchips mit 1,5*[2er-Potenz] Bits kommen sollen. Damit wären 12*1,5GB = 18GB möglich.

Grabhopser

2016-05-18, 23:04:04

GDDR5x erlaubt auch krumme Bestückung, es würde also durchaus gehen.

iuno

2016-05-18, 23:21:19

Die Bestueckung ist normal, es soll aber Chips mit (bis jetzt) ungewoehnlichen Kapazitaeten geben.
Von 4, 6, 8, 12 und 16 Gb war die Rede.
Micron baut 8 Gb, ich denke nicht dass kleinere sich noch lohnen. Fuer "krumme" Bestueckung muessten sie also bis dorthin erstmal 12 Gb Chips bauen. Bei 384 Bit waeren das dann aber dementsprechend 18 GiB, nicht 16.
Die Chips mischen kann man bei so einem High End Produkt ja nicht wollen.

Ravenhearth

2016-05-19, 03:43:10

Die Titan wäre @stock dann 40% schneller als die 1080, die Ti noch 26%. Klingt realistisch.

BigKid

2016-05-19, 08:54:20

Unvermeidliche Frage: Gibts schon was zu den mobile Chips ? 😉

igg

2016-05-19, 09:30:23

Hier dann noch ein paar Mutmaßungen ueber GP102
Gab es eigentlich irgendeinen Hinweis auf Zauba der die GP102 Theorien bestätigt?

Godmode

2016-05-19, 09:32:14

Gab es eigentlich irgendeinen Hinweis auf Zauba der die GP102 Theorien bestätigt?

Die Chip Codenamen gibt es leider nicht mehr auf Zauba, daher ist es recht schwierig GPU102 zu finden. Ich würde mich freuen wenn das Ding doch noch heuer im November erscheinen würde.

Die 1080Ti als GP102 Salvage bekommt 12 und die nächste runde Zahl ist dann erst wieder die 24.
Ist doch logisch. ;)

Mir ist natürlich bekannt, dass die Speichermenge immer von der Größe des Speicherinterfaces abhängt, aber 24 GB erschien mir als zu viel. Andererseits würden die 12 GB für die Ti wirklich gut passen, das wäre eine Verdopplung der 6 GB der 980 Ti. Vielleicht gibt uns NV ja für die Titan ebenfalls nur 12 GB.

Nightspider

2016-05-19, 09:46:37

24GB? Niemals. Selbst mit völlig übertriebenen Settings und Mods bekommt man selten die 12GB voll.
24GB werden wir erst brauchen wenn die nächste Konsolengeneration da ist. Also nicht vor 2019/2020.

12-16GB sollten selbst für die 10nm Karten völlig ausreichen.

iuno

2016-05-19, 09:53:51

Dann bekommt die Neo 16 GiB und was sagst du dann? ;p
Lagst ja in der Vergangenheit schon ordentlich daneben, was diese Konsolen VRAM Vergleiche angeht.
Im Prinzip waeren 24 GiB fuer die Titan der logische Schritt, weiterhin die Haelfte, also 12 fuer die Ti, so gibt es die uebliche Abstufung.

Oben habe ich die Speichergroessen fuer 5X aufgeschrieben. An 384 Bit gingen demnach 6, 8, 12, 18 oder 24 GiB (bzw. jeweils das doppelte im Clamshell Modus).
Warum muessen es aber unbedingt 384 Bit sein? 320 Bit waeren doch z.B. auch denkbar?! Mit 11/12 Gbps Chips hat man dann auch mehr Moeglichkeiten.

Edgecrusher86

2016-05-19, 10:01:38

24 und 12GB klingen logisch, betrachtet man die Generationen seit Kepler. TITAN-Serie immer 3x VRAM Performance Chip und deren Salvage immer +50% VRAM auf diesen drauf. 16GB für die TITAN bei 12GB für die Ti wären dann doch irgendwie billig?! ;)
Naja, sie werden vermutlich mit 5K Surround oder 8K Single werben. :cool: Vll. wird ja dann ja auch offiziell ähnlich hohe DSR-Factors eingeführt, wie mit Orbs Tool. Dann langt zumindest immer der VRAM im 2-way SLI (spielbar mit div. Abstrichen könnte es schon sein). Screenshots schießt man dann mit SGPU. ;D
Gleich Vollausbau für die TITAN wäre natürlich sehr wünschenswert - klingt dann aber auch gleichzeitig so, dass ein Release in 2016 eher nichts mehr wird - dann hat Jensen wieder etwas zum Hochhalten für die nächste US-GTC.

Sollte der Vollausbau nicht real wieder eher "nur" 25-30% auf die 1080er packen wie unter Maxwell mit 50% mehr Einheiten auch?
So um die 100 MHz weniger Takt als die 1080er war für mich aufgrund des PTs wieder zu erwarten und gibt natürlich auch den Boardpartnern wieder mehr Spielraum bei den Custom Ti.

Gut...um die 30% auf die Stock 1080 wären derzeit auch schon eine Ansage und mit OC wäre Big Pascal dann mit wenigen Ausnahmen (etwa The Division min. fps) schon eine sehr gute 4K-Karte. Im 2-way SLI geht es dann Richtung 5K, zumindest sofern auch mal für DX12 der ein oder andere Titel MGPU-Support mit sich bringt; zum jetzigen Stand ist die API für Enthusiasten eine Farce in meinen Augen (zumeist miese Ports tun dann noch ihr übriges). :rolleyes: Bleibt noch zu hoffen, dass man das BIOS für die Referenzkarten wieder modden kann - zumindest das PT.

OT:
Hm...bei 24GB GDDR5X müsste ich mir dann aus psychologischen Gründen auch den System-RAM wieder aufrüsten - sonst sieht das sehr doof aus, auch wenn die 16GB hier am Zocker-Sys noch mehr als ausreichend sind (spiele kein CoD mehr seit MW2 :biggrin:).
Wird dann wohl gleich auf ein 64er Quad-Kit hinaus laufen, dann ist erstmal Ruhe im Karton. Die DDR4-Preise sind ja auch dort heuer schon recht human, vergleicht man sie mit dem Stand Herbst 2014 als 2011-3 released wurde. :freak:

scully1234

2016-05-19, 10:01:51

Gab es eigentlich irgendeinen Hinweis auf Zauba der die GP102 Theorien bestätigt?

Nein zu Zauba sagt er da nix

https://www.chiphell.com/thread-1588175-1-1.html

Edgecrusher86

2016-05-19, 11:14:23

16GB für die TITAN wäre mMn realisitischer, wenn NV erstmal nur Cuts bringen würde - auch inkl. Ti. Das wäre dann wieder die gewinnoptimierte Strategie. Ich nenne es mal die goldene Salamitaktik. :D

TITAN wieder auf DP ausgelegt - GP100 56 SMs (3584 SPs/224 TMUs/96 ROPs) + 16GB HBM2 + P100 FP64-Taktraten. Das dürfte dann locker einen MSRP von $1500 geben. Release vermutlich Ende Q1 2017.
1080 Ti oder besser "1180" würde sich dann zum Beispiel mit GP102 @ 25 SMs anbieten (3200 SPs/200 TMUs/80 ROPs) für $799-849 MSRP, was dann je nachdem, hierzulande inkl. MwSt. einen Preis minimal unterhalb der ersten TITAN ergibt. Release wohl wieder Q2 2017 (Mai)

Dann könnte man Ende 2017 noch die "1180 Ti" (inkl. 12 Gbps GDDR5X) und 2018 die nächste TITAN Black mit Vollausbau (30 bzw. 60 SMs) bringen.
Zusätzlich würde die GTX 1170, der GTX 1080 Refresh, ebenso mit einer homöopathischen GPU-Takterhöhung sowie 12 Gbps GDDR5X daher kommen und hätte zudem etwas mehr PT; GTX 770 lässt grüßen.
Die GTX "1160 Ti" wäre dann zum Beispiel eine GTX 1070 mit 10 Gbps GDDR5X, wenn man den Bogen noch weiter spannt. Release dieser Karten könnte dann wieder Ende Mai/Juni 2017 sein. :freak:

Diese Taktik könnte man sich natürlich nur erlauben, wenn AMD in den meisten Anwendungen mit Vega nur der GTX 1080 gefährlich wird bzw. diese etwas überholt.

Für den NV-Enthusiasten wäre das natürlich absoluter Worstcase, keine Frage.

Complicated

2016-05-19, 11:53:20

1080 Ti oder besser "1180" würde sich dann zum Beispiel mit GP102 @ 25 SMs anbieten (3200 SPs/200 TMUs/80 ROPs) für $799-849 MSRP, Ich bin mir fast sicher du meintest 52 SM ;)

Nightspider

2016-05-19, 12:34:48

Dann bekommt die Neo 16 GiB und was sagst du dann? ;p
Erstmal abwarten. Wenn überhaupt wird die Neo wohl nur eine 4K Variante ohne extra/besseren Content bei den Spielen, um die Community nicht zu spalten.

Lagst ja in der Vergangenheit schon ordentlich daneben, was diese Konsolen VRAM Vergleiche angeht.
Was meinst du?:confused:

Im Prinzip waeren 24 GiB fuer die Titan der logische Schritt, weiterhin die Haelfte, also 12 fuer die Ti, so gibt es die uebliche Abstufung.

24 und 12GB klingen logisch, betrachtet man die Generationen seit Kepler.

Und in 2 Jahren haben wir dann 48GB VRAM? Euer Ernst?:confused:
Wer soll den Content dafür erstellen? ^^

Vergesst mal nicht das wir in der 28nm Generation schon den VRAM zigfach verdoppelt haben.
GTX680 hatte schon 33% mehr VRAM als die GTX580.
Titan hatte 200% mehr als GTX680.
Titan X nochmal 100% mehr als Titan.

Bei Speicher gibts kein andere Moores Law als bei GPU Chips. Irgendwann muss es auch mal eine Pause geben.
Ganz zu schweigen das es irgendwann deutlich weniger sinnvoll ist so eine riesige Menge an VRAM zu verbauen. Der Content muss schließlich auch erstmal produziert werden und wenn es die 10nm Grafikkarten gibt, haben wir immer noch keine NextGen Konsolen.
Womit wollt ihr da 48GB füllen?

woodsdog

2016-05-19, 12:39:23

zumal die zich GB auf der karte auch strom brauchen der nicht mehr der GPU zur Verfügung steht.

Effe

2016-05-19, 13:58:24

@Unicous: falscher Thread? Darum ging es hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11037832#post11037832

Andere Überlegung: Wenn GP102 mit HBM2 kommt, dann sinds 4x4GB=16GB. Im GP100 hat NV doch schon einen HBM-MC konstruiert, da konnen sie den in den Consumerchip auch einbauen.

Mit eine 384Bit MC wirds trotz GDDR5X vielleicht doch zu dünne. Aber wer weiß, GDDR5X ist zur Zeit noch plausibler.

Dural

2016-05-19, 19:11:43

Euch ist schon klar das dass verhältnis bei der bandbreite von gp104 (256) zu gp102 (384) pro sp exakt gleich ist?!?

Wenn gp104 zu wenig hat, wird es gp102 auch haben. Die einzige hoffnung ist das nv schnelleren speicher verbaut, die vergangenheit aber gezeigt das nv überall das selbe innerhalb einer serie verbaut.

robbitop

2016-05-19, 19:16:05

Es ist doch weder klar, ob es einen GP102 gibt noch welches Speicherinterface (und dessen Takt und Breite) er hat.

scully1234

2016-05-19, 19:31:58

Ich wuerde diesen PolyMorph von ChipHell nicht voellig bei Seite wischen, irgendwie hatte ich den noch von vergangenen Releases auf dem Radar, wie diesen Napoleon von der anderen China Seite.

Da traf oftmals einiges zu von dem Gesagten

AnarchX

2016-05-19, 19:44:50

Napoleon war auch Chiphell. Aber er ist wohl nicht mehr dort aktiv oder wurde einkassiert. Generell hat man bei Chiphell durch die Herstellernähe sehr gute Quellen.

GP102 wurde offiziell in einer CUDA-DLL benannt, die erweiterte Debugging-Optionen hatte. Der entsprechende Treiber wurde von Microsoft verteilt.
An gleicher Stelle wurde auch damals GK210 benannt, an welchen keiner glaubte bis er dann Ende 2014 erschien.

Eine entsprechende Nennung deutet auf Entwicklungen an dem entsprechenden Chip hin und wohl auch das Vorhandensein von Silizium.
Trotz allem kann es danach noch zum Projektabbruch kommen: GT212, GT214, GT206, GK180.

scully1234

2016-05-19, 19:51:24

Napoleon war auch Chiphell. .

Ich glaube der hat irgendwo anders auch noch aktiv gepostet, bin mir da aber jetzt nicht mehr ganz sicher

Unicous

2016-05-19, 19:58:19

Wann kam denn überhaupt das letzte Mal etwas 'wirklich Interessantes' von Chiphell. Ist mMn fast schon Jahre her. Mir kommt es eher so vor, als wären die meisten Quellen schon längst versiegt und man muss sich auf Zufallsfunde und sich verplappernde Mitarbeiter verlassen.

Edgecrusher86

2016-05-19, 20:11:57

Ich bin mir fast sicher du meintest 52 SM ;)

Ne, passt schon - 25 x 128 habe ich gemeint (a la 1080). ;)

Zum VRAM: Nicht nur die Auflösungen steigen enorm die nächsten Jahre, sondern vermutlich auch die Texturauflösungen. Gut, natürlich wäre es eher mehr Marketing, nächstes Jahr eine Karte mit 24GB zu bringen, denn die Rohleistung fehlt natürlich als SGPU in den allermeisten Fällen, solche Mengen bei spielbaren fps auszulagern. Wenn später doch benötigt (maxed out), wird so eine Pascal-Karte natürlich gnadenlos hinterher hecheln - das trifft ja auch auf 6GB Kepler-Karten zu - zumindest, wenn man 1440p und 4K mit maximalen Details als Referenz nimmt. Mit SLI sieht es dann aber schon besser aus, wobei halt doch oft eine Ti oder X so ein stock GK110 SLI obsolet machen kann in aktuellen Titeln.

Solange die Speicherhersteller die möglichen Größen alle ein bis zwei Jahre verdoppeln, können die IHVs solche Verdoppelungen zur nächsten Generation anbieten. Ich denke nicht, dass sich dies in naher Zukunft so schnell ändern wird.

Nun ja, ich habe lieber zuviel VRAM, als zu wenig. :D

HOT

2016-05-20, 08:26:33

Für GP102 würde ich 512Bit nicht ausschließen. Dann hätte der 1080ti 8GB und der Titan 16. Passt doch. Und man rennt nicht in Bandbreitenlimits, der Chip muss ja nicht so kosteneffizient sein wie GP104. HBM kann zwar auch sein, ich glaub aber, dass NV das einfach nicht benötigt und deshalb bei GP102 darauf verzichten wird.

Allerdings kann ich mich auch gut mit der Refresh-Idee, allerdings als GTX2k anstatt GTX11xx, anfreunden, also die jetzige 1080 als 2070 mit schnellerem RAM. Darüber als 2080 dann GP102 salvage. Vor allem wenn Vega fix wird und klar ist, dass darüber noch was kommt dürfte so ein Refresh sogar nötig sein. Sieht ja so aus, als würde Vega10 AMDs neuer Tahiti/Hawaii.

Edgecrusher86

2016-05-20, 08:46:06

512-bit GDDR5X würde man als Enthusiast auch sofort unterschreiben - damit könnte man auch richtig viel VRAM fahren (16x 1,5GB anyone :freak:) und selbst mit Anfangs 10 Gbps wären es schon satte 640 GB/s an Bandbreite. Wenn GP102 dann noch gleich im Vollausbau käme, wäre es aus Kundensicht optimal. :D

Godmode

2016-05-20, 08:46:09

iuno

2016-05-20, 08:58:36

Wenn GP102 = GP104 + 50% Einheiten ist, dann braucht er auch nicht mehr.
Das wuerde ich so noch nicht unterschreiben. Das wird zu einem Teil vielleicht auch von der Konkurrenzsituation abhaengen und wo sich Vega positioniert.
Klar, wenn es so laeuft wie jetzt, dass man eh ausser Konkurrenz steht und zudem noch frueher dran ist, kann man das schon machen. Es kann aber auch sein, dass man den Chip mehr ausfahren muss als die Sparflamme die bei GP104 anliegt. Und das betrifft dann vor allem auch die Bandbreite.
Solange man ja auch wirklich noch rein gar nichts weiss wuerde ich auch weiterhin HBM nicht ausschliessen.

Hübie

2016-05-20, 09:14:40

Erstmal abwarten. Wenn überhaupt wird die Neo wohl nur eine 4K Variante ohne extra/besseren Content bei den Spielen, um die Community nicht zu spalten.

Was meinst du?:confused:

Und in 2 Jahren haben wir dann 48GB VRAM? Euer Ernst?:confused:
Wer soll den Content dafür erstellen? ^^

Vergesst mal nicht das wir in der 28nm Generation schon den VRAM zigfach verdoppelt haben.
GTX680 hatte schon 33% mehr VRAM als die GTX580.
Titan hatte 200% mehr als GTX680.
Titan X nochmal 100% mehr als Titan.

Bei Speicher gibts kein andere Moores Law als bei GPU Chips. Irgendwann muss es auch mal eine Pause geben.
Ganz zu schweigen das es irgendwann deutlich weniger sinnvoll ist so eine riesige Menge an VRAM zu verbauen. Der Content muss schließlich auch erstmal produziert werden und wenn es die 10nm Grafikkarten gibt, haben wir immer noch keine NextGen Konsolen.
Womit wollt ihr da 48GB füllen?

Ich denke auch, dass 24 GiB total überflüssig sind und man das Pulver nicht einfach jetzt schon mit einem Intermezzo wie Pascal verschießen wird. 16 GB, mehr wirds nicht.
Aber dass die Neo mehr RAM benötigt liegt auf der Hand, denn mal "eben so" 4-fache Auflösung heißt ja eben auch deutlich mehr Speicherbedarf. Ich hab hier selbst einige ältere Schinken die von 1080p->2160p gleich dreifache Puffermenge brauchen.

Für GP102 würde ich 512Bit nicht ausschließen.

Zu teuer, zu platz-verschwenderisch, zu ineffizient. GP102 wirds wohl nicht geben*. Stattdessen GP100 mit 16 GiB HBM2 VRAM. Außer einem Eintrag gibt es keinerlei Hinweise und egal ob Deutscher, Chinese oder Grieche (;D): Eine Tabelle, die halbwegs plausibel aussieht, kann jeder erstellen. Es ist einfach nicht wirtschaftlich GP100 nur für einen Markt zu konzipieren und wenn ich mir die forecasts von NV ansehe, dann sieht das nicht nach 2-die-strategy (für da oben) aus.
Man muss ja dann mit zwei Chips die Kosten auf beiden Märkten separat abfedern. Das ergibt kalkulatorisch einfach keinen Sinn. Kann ich Zahlen drehen und schubsen wie ich will.

*GP102 könnte ein frühes Testboard für normale PEG-Steckplätze gewesen sein, da man sicher nicht die ganze Zeit diese Module testet (Mehraufwand).

HOT

2016-05-20, 09:31:44

[...]

Zu teuer, zu platz-verschwenderisch, zu ineffizient. GP102 wirds wohl nicht geben*. Stattdessen GP100 mit 16 GiB HBM2 VRAM. Außer einem Eintrag gibt es keinerlei Hinweise und egal ob Deutscher, Chinese oder Grieche (;D): Eine Tabelle, die halbwegs plausibel aussieht, kann jeder erstellen. Es ist einfach nicht wirtschaftlich GP100 nur für einen Markt zu konzipieren und wenn ich mir die forecasts von NV ansehe, dann sieht das nicht nach 2-die-strategy (für da oben) aus.
Man muss ja dann mit zwei Chips die Kosten auf beiden Märkten separat abfedern. Das ergibt kalkulatorisch einfach keinen Sinn. Kann ich Zahlen drehen und schubsen wie ich will.

*GP102 könnte ein frühes Testboard für normale PEG-Steckplätze gewesen sein, da man sicher nicht die ganze Zeit diese Module testet (Mehraufwand).

Du meinst dann also GP100-Refresh als 1080ti mit 8GB als Salvage und Titan mit 16GB ist dann full?

StefanV

2016-05-20, 10:04:51

Vergesst mal nicht das wir in der 28nm Generation schon den VRAM zigfach verdoppelt haben.
GTX680 hatte schon 33% mehr VRAM als die GTX580.
Titan hatte 200% mehr als GTX680.
Titan X nochmal 100% mehr als Titan.
Richtig und in der 600 und 700er Serie waren 2 bzw 3GiB VRAM maximal üblich.

Erst die 900er Serie hat ganze 4GiB gebracht.

Während bei AMD schon in der 200er Serie 4 GiB bei Hawaii üblich waren und es sogar einige 8GiB Versionen gab, die in der 390er Serie zum Standard wurden, 4GiB sind hier auch üblich.

Sorry, aber schau dir bitte 8mal die Praxis an bzw was die Mehrheit für Karten haben.
Und da dümpeln wir bei nVidia bei um die 2-3GiB rum...

Und 2GiB VRAM begleiten uns schon seit dem 40nm Refresh im High End.
Dürften also so um die 4 Jahre gewesen sein, in denen nVidia Nutzer mit nur 2 GiB VRAM rumgurken durften...

Bei AMD hat man mit der 7970 gleich 50% mehr Speicher denn die GTX680 und auch 770 geboten, erst der 28nm Refresh konnte hier aufschließen, während AMD aber schon 4GiB VRAM bot...

BlacKi

2016-05-20, 10:14:02

Und in 2 Jahren haben wir dann 48GB VRAM? Euer Ernst?:confused:
Wer soll den Content dafür erstellen? ^^

mit hbm könnte man auch glatte angepasste zahlen nehmen und einen grund dafür liefern nicht den speicher zu verdoppeln.

aber zunächst muss der gamer big chip erstmal erscheinen nächstes jahr, und dann heute in 3 jahren (big chip lässt sich immer mehr zeit) wird man mit 16gb keine titan mehr verkaufen, also 2019 mit um die 32gb schätze ich.brauchen wird man 2019 davon natürlich nichtmal die hälfte, genau wie bei der titanx zu release.

Hübie

2016-05-20, 10:24:18

Du meinst dann also GP100-Refresh als 1080ti mit 8GB als Salvage und Titan mit 16GB ist dann full?

Wieso denn jetzt auf einmal refresh? Der kommt ganz normal mit 3584 ALUs, 8 GiB HBM2 als 1080Ti und dann als full fat mit 16 GiB als Titan *insertrandomletter*. Mehr wird afaik nicht passieren. Mit Volta ist es durchaus möglich einen Chip nur für HPC zu sehen (also nicht mal Quadro).

Richtig und in der 600 und 700er Serie waren 2 bzw 3GiB VRAM maximal üblich.

Erst die 900er Serie hat ganze 4GiB gebracht.

An sich richtig aber es gab schon mit der 680 einige 4 GB-Modelle und mit der 770 auch recht viele. Ich war bei den beiden 580er damals kurzsichtig und hatte dann bei den 770er auf 4 GB gesetzt. Genützt hat das nix. 2014 war schon Ende der Fahnenstange.

Während bei AMD schon in der 200er Serie 4 GiB bei Hawaii üblich waren und es sogar einige 8GiB Versionen gab, die in der 390er Serie zum Standard wurden, 4GiB sind hier auch üblich.

Die 200er-Reihe hatte ganz andere Imageprobleme als VRAM (leider).

Sorry, aber schau dir bitte 8mal die Praxis an bzw was die Mehrheit für Karten haben.
Und da dümpeln wir bei nVidia bei um die 2-3GiB rum...

Und 2GiB VRAM begleiten uns schon seit dem 40nm Refresh im High End.
Dürften also so um die 4 Jahre gewesen sein, in denen nVidia Nutzer mit nur 2 GiB VRAM rumgurken durften...

Bei AMD hat man mit der 7970 gleich 50% mehr Speicher denn die GTX680 und auch 770 geboten, erst der 28nm Refresh konnte hier aufschließen, während AMD aber schon 4GiB VRAM bot...

Aber warst du nicht auch überrascht als Jensen auf einmal mit der Titan X Box durch den Vorhang kam und die stumpf mit 12 GB präsentierte. Das war ein Schuß vor den Bug an AMD, jede Wette dass er die dabei im Kopf hatte.

NVIDIA gibt "uns" halt nur soviel wie wir brauchen um dann direkt im Folgejahr noch einmal ein drauf zu setzen und die Hand aufzuhalten. Und wir sind auch noch so blöd das zu kaufen? :freak: Jetzt frage ich dich: Hälst du uns alle für zu blöd mit Geld umzugehen oder mit Investitionen zu rechnen? :wink: Es gibt also immer einen Grund der über dem Geld steht, wenn es zu dem Snob-Effekt kommt.

Kartenlehrling

2016-05-20, 10:34:16

Es kommt ja noch hinzu das durch die neuen Rendering Techniken 30-60% Memory eingespart wird, somit wären wir wieder beim Gleichstand.
Das muss halt nur umgesetzt werden, nicht ohne grund wirbt Nvidia mit der vierten Generation von Delta Color Compression.
Vor einem Jahr hat doch auch Nvidia die neusten Anti-Aliasing vorgestellt, da wird auch nochmal von 35-57% Einsparung geschrieben.

Hübie

2016-05-20, 10:41:54

Was genau meinst du jetzt mit neue Render-Techniken? Die Richtung oder einzelne Komponenten oder wie oder was? =) Und meinst du Bandbreiteneinsparung oder wirklich Speicherbedarfsreduzierung?

PHuV

2016-05-20, 10:57:51

Na ja, wenn ich dann die aktuellen Spiele so sehe, die mir dann mal so einfach 8,5-11,5 GB VRam während des Spieles reinknallen, frag ich mich schon, wo die ganzen sparenden Techniken geblieben sind. Mit der Logitech G19 und Aida32 lasse ich mir immer im Display auch die VRam-Auslastung permanent anzeigen, und finde es schon erschreckend, das 4 GB lange nicht mehr genug sind. Ich habe selbst in den Kinder-PC eine 8GB-380er von AMD eingebaut, weil beispielsweise Star Wars Battlefront sich auch mal gerne 6-7 GB gönnt.

Hübie

2016-05-20, 11:01:33

Ich habe selbst in den Kinder-PC eine 8GB-380er von AMD eingebaut

:eek: Seit wann verkauft AMD wieder Karten und wo gibt's ne 380 mit 8 GB? Haben die das für dich gebaut? :biggrin:

Die Frage ist: Wieviel braucht man. Wenn Windows wie bei mir 25.216 MB VRAM meldet, wird der Puffer entsprechend größer angelegt und so nutzen die Spiele auch mehr. Ich schätze dass man mit 8 GiB noch lange dabei ist.

PHuV

2016-05-20, 12:51:30

:eek: Seit wann verkauft AMD wieder Karten und wo gibt's ne 380 mit 8 GB? Haben die das für dich gebaut? :biggrin:
Ja, Du hast recht, es ist eine R9 390. :redface:

Die Frage ist: Wieviel braucht man. Wenn Windows wie bei mir 25.216 MB VRAM meldet, wird der Puffer entsprechend größer angelegt und so nutzen die Spiele auch mehr. Ich schätze dass man mit 8 GiB noch lange dabei ist.
Das kann ich so weder beurteilen noch bestätigen. Da ich leider in der Titan X nicht für Testzwecke mal so den VRam begrenzen kann, kann ich überhaupt nichts darüber aussagen, ab wann es nur preemptives Laden ist, oder ob sich die Auslastung im Falle von zuwenig VRam doch schon bemerkbar machen würde. Das extremsten Beispiele waren bei mir eben CoD AW2 und BO3 mit ca. 11-11,5 GB VRam. Star Wars Battlefront neigt eben auch dazu, das zu nehmen, was da ist. Daher teile ich nicht Deine optimistische Hoffnung, daß 8 GB lange reichen werden. Ganz im Gegenteil, da jetzt die Spielehersteller sehen, daß mehr VRam da ist, wird das auch ganz schnell entsprechend genutzt werden. Da kann ich mir schon vorstellen, daß es schnell Spiele geben wird, die mit 16 GB glücklicher sind, Stichwort 4k/8k, VR, und Spiele damit ruckelfreier laufen.

HOT

2016-05-20, 15:10:27

Wieso denn jetzt auf einmal refresh? Der kommt ganz normal mit 3584 ALUs, 8 GiB HBM2 als 1080Ti und dann als full fat mit 16 GiB als Titan *insertrandomletter*. Mehr wird afaik nicht passieren. Mit Volta ist es durchaus möglich einen Chip nur für HPC zu sehen (also nicht mal Quadro).[...]
Ok, da haste auch wieder recht. Das Ding scheint ja gut zu laufen :D.

Dural

2016-05-20, 16:02:44

Da GP102 so fern er kommt sicher 12GB hat, dürften die 8GB der 1080 sicher länger reichen, zudem derzeit sehr viele Karten mit 4GB im Umlauf sind:
GTX770
GTX960
GTX970
GTX980
290
290X
380
Nano
Fury

victore99

2016-05-20, 16:26:04

Da GP102 so fern er kommt sicher 12GB hat, dürften die 8GB der 1080 sicher länger reichen, zudem derzeit sehr viele Karten mit 4GB im Umlauf sind:
GTX770
GTX960
GTX970
GTX980
290
290X
380
Nano
Fury
GP102 wird 12G haben. Sicher.
Aufjedenfall einen 384er IF.
Und die 8G... Wir werden uns im Nachhinein sicher wundern, wie kurzlebig die paar GB sind :D

Leonidas

2016-05-20, 16:30:25

Woher soll aber PX2 seine 24 DL TOPS sonst her haben? Immerhin hatte der GM20A in Tegra X1 ja auch schon gepackte FP16-OPs.
Da es für Spieler wohl möglich nicht so viel bringt, könnte man es deaktiviert haben. Eine Tesla P50 hat dann wohl ihre 16 TFLOPs FP16.

Unter Umständen hat NV in GP106 ausnahmsweise einige dieser Profi-Features gepackt, weil man wusste, das es für PX2 gebraucht würde. Würde besser die vergleichsweise große Chipfläche erklären.

2018/19(?) mit Volta kommen dann 48GB?
24GB sind lächerlich viel. Ist mit GDDR5X nicht auch krumme Bestückung möglich? Also 16GB würde für eine Titan doch dicke reichen.

Ja, gute Idee. Diese 768-MB-Chip würden sich nutzen lassen, um an einem 384 Bit Interface mit 6x64Bit dann eine Speicherbestückung von 9 GB für die 1080Ti zu fahren (12x768MB). Titan dann mit 12 GB.

Hm...bei 24GB GDDR5X müsste ich mir dann aus psychologischen Gründen auch den System-RAM wieder aufrüsten - sonst sieht das sehr doof aus, auch wenn die 16GB hier am Zocker-Sys noch mehr als ausreichend sind :

Tipp an NV: Wenn die Titan mit 24 GB kommt, vor dem Launch noch schnell Aktien von DRAM-Herstellern kaufen ;)

Euch ist schon klar das dass verhältnis bei der bandbreite von gp104 (256) zu gp102 (384) pro sp exakt gleich ist?!?

Wenn gp104 zu wenig hat, wird es gp102 auch haben. Die einzige hoffnung ist das nv schnelleren speicher verbaut, die vergangenheit aber gezeigt das nv überall das selbe innerhalb einer serie verbaut.

Korrekte Überlegung - bis zum Teil mit dem Speichertakt. Da wurde nur der gleiche verbaut, weil "früher" nicht mehr als 3500 MHz gingen. Bei GP102 wird man dagegen Zugriff auf schnelleren GDDR5X haben, womit man schnell auch mal 80% mehr Speicherbandbreite als 1080 bieten kann.

kdvd

2016-05-20, 17:02:11

Und in 2 Jahren haben wir dann 48GB VRAM? Euer Ernst?:confused:
Wer soll den Content dafür erstellen? ^^

Ich kann mir vorstellen, dass das Megatexture Konzept davon sehr profitieren würde. ;)

Nightspider

2016-05-20, 17:34:38

Alle gut programmierten, modernen Spiele gehen doch super effizient mit VRAM um.
Spiele wie Shadow of Morder sind schlecht programmierte Beispiele.

Da es vorhin genannt wurde: Battlefront geht doch auch sehr effizient um mit dachte ich?
Als ob das 6-7GB benötigen wird. Der VRAM wird einfach belegt weil so viel da ist, nicht weil man zwingend so viel braucht.

Man muss sich nur mal anschauen wie gut aktuelle Frostbite und CryEngine Spiele aussehen, selbst ohne DX12.
Wer sich bei 12-16GB Sorgen macht sollte man über sein Weltbild nachdenken. :ugly:

Die meisten haben noch 4GB, viele sogar noch nur 2GB. Zur Zeit zocke ich auch übergangsweise mit einer 2GB Karte.

illidan

2016-05-20, 17:36:47

Ist halt nett, für Schrott-Technik eine Abfederung zu haben. Als Must Have würd ich es jetzt auch nicht sehen.

Korvaun

2016-05-20, 17:49:47

Solange die Konsolen nicht auf 16GB gehen sind mehr als 8GB bei normalen PC-Grafikkarten (also alles unter Top-Karte ala Titan) aktuell reiner Luxus. Frühestens gegen Ende der "Volta-Generation" (2019?), wenn auch 4K viel breiter im Markt ist, sehe ich eine durchgängige Steigerung des VRAM anstehen. Wer dafür extra zahlen will kann des gerne tun, freut Hernn Jensen sicherlich ;)

HOT

2016-05-20, 19:51:24

Was hat den "schlecht programmiert" mit "klappt nicht gut mit Bandbreitenkompression" zu tun? Das doch totaler Unsinn. Das hat doch eher was mit dem Content zu tun.

Pumpi74

2016-05-21, 12:46:01

Wenn eine 1080 bei 200 Watt schon laut wird, wie soll denn so ein GP102 FE Kärtchen gestaltet sein ? 250 Watt Verbrauch bei 1500Mhz Boost und mindestens so laut wie ref-480-Fermi ?

Und dank des dann voll ausgefahrenen GDDR5X Speichers natürlich mit 2,4Ghz Boost GPU-Takt auf den Customboards, die Bandbreite will ja auch genutzt werden.... (bei 350-400 Watt ?).

Das klingt alles unrealistisch. Müsste aber so, oder so ähnlich kommen, wenn die Speku's hier stimmen.

iuno

2016-05-21, 12:59:26

Man muss imho schon auch die kleinere Flaeche bedenken. Die 200 Watt auf knapp ueber 300 mm² abzufuehren ist schon was anderes als bei den 400 mm² von GM204 oder auch die 250 Watt auf den 600 mm² von GM200

Pumpi74

2016-05-21, 13:15:06

Sicherlich. Nur hat der GP102 dann ja das gleiche Shader/mm² Verhältnis wie die 1080. Da nützen dann 450mm² nicht viel weiter wenn die Heizplatte ähnlich aggressiv ist.

Die einzige Lösung wäre bei einem solchen Chip eine größere FE Edition zu bauen. Also ein 3 Slot Design oder eine höhere Karte mit einem größer durchmessenden Radiallüfter. Oder nVidia bringt gar keine Referenz/FE Edition...

iuno

2016-05-21, 13:17:14

Und wer sagt, dass GP102 genauso dicht gepackt und genauso hoch getaktet wird? Watt/mm² ist doch da noch voellig offen.

Sunrise

2016-05-21, 13:27:08

Wenn eine 1080 bei 200 Watt schon laut wird, wie soll denn so ein GP102 FE Kärtchen gestaltet sein.
Du kannst nicht 300mm^2 mit deutlich größeren GPUs vergleichen. Zudem werden bei 250W TDP wohl Taktraten-Anpassungen nötig.

Daher hatten einige ja mit HBM spekuliert, das spart zusätzlich, aber dann könnte man auch direkt schon fast GP100 nehmen, denn so ein Ding wird es allenfalls als Salvage unter $1000 US geben.

Pumpi74

2016-05-21, 13:35:47

@iuno

Die Taktung ist variabel, klar. Nur die Packdichte zwischen den beiden jeweils größten Chips hat bei nVidia in den letzten 10 Jahren zumindest kaum variiert. Wäre designtechnisch sicher auch nicht ganz ohne....

BlacKi

2016-05-21, 13:52:57

wenn kein hbm2 kommt, dann wird der abstand zwischen 1080 und 1080ti ca genauso große wie 980 und 980ti. 20-25%, ungefähr das was eine 1080 mit oc schafft, nur 1 jahr früher.

Ravenhearth

2016-05-21, 15:01:00

Warum sollte GP102 ohne HBM nur 20-25% schneller sein? Statt HBM nimmt Nvidia dann eben 384 bit GDDR5X mit 12 Gbps und hat 80% mehr Bandbreite. Bei den letztens berichteten Daten von 3840 ALUs für Titan X bei 1621 MHz und 3456 ALUs für die Ti bei der gleichen Frequenz käme man auf 40 bzw. 26% mehr Rechenleistung als bei der 1080, bei gutem OC-Potenzial.

Korvaun

2016-05-21, 15:15:23

iuno

2016-05-21, 15:50:27

Man darf Takt-, Temperatur- und Verbrauchsgrenzen nicht aussen vor lassen. 1080 Customs koennten durchaus zu nahe kommen, womoeglich verbietet NV dann auch den Einsatz von schnellerem Speicher.
Die TX liegt ja im Schnitt in Spielen auch keine 50% vor der 980.
Gerade was den Takt angeht, scheint ja Pascal auch nochmal "kritischer" zu messen sein.

Ravenhearth

2016-05-21, 16:03:40

Milchmädchen rechnet:

Wenn
1080: 2560 Shader an 256bit G5X in 314mm2

Dann
TitanP: 5120 Shader an 512bit G5X in ca. 600mm2
1080ti entsprechend salvage

da sollten leicht 50% mehr speed machbar sein....;D

Es darf aber bezweifelt werden, dass Nvidia gleich auf über 600mm² geht, ist aktuell ja gar nicht nötig. Ein ~470mm²-Chip mit 3840 ALUs ist auch schnell genug um viel Geld zu verlangen und einfacher zu produzieren.

Man darf Takt-, Temperatur- und Verbrauchsgrenzen nicht aussen vor lassen. 1080 Customs koennten durchaus zu nahe kommen, womoeglich verbietet NV dann auch den Einsatz von schnellerem Speicher.
Die TX liegt ja im Schnitt in Spielen auch keine 50% vor der 980.
Gerade was den Takt angeht, scheint ja Pascal auch nochmal "kritischer" zu messen sein.

Bei 980, 980 Ti und Titan X war es ja auch so, dass eine 980 mit Werks-OC schon recht nah an eine Ti @stock heran kam und eine Ti mit OC hat eine TX auch deutlich überholt. Dieses Mal kann es ruhig ähnlich werden, nur mit dem Unterschied, dass eine TX@stock >10% schneller ist eine Ti@stock und nicht nur ein paar Prozent. Verkauft haben sie Ti und TX in der letzten Generation auch, ohne dass die @stock gleich 50% schneller waren.