News Nvidia enthüllt GeForce GTX Titan X mit 12 GByte VRAM

[Nai]

Das ist genau nicht der Fall. SFR und eine API, die dem Entwickler genug Kontrolle über den Speicher gibt, ermöglichen es, effektiv mehr Speicher zu nutzen, indem die Daten verteilt werden. So müssen nicht zwingend alle Geometrie- und Texturdaten redundant in beiden Speichern vorliegen, wie das bei AFR zwingend der Fall ist. Inwieweit sich das mit Vulkan, Mantle und DX12 ausreizen lässt, wird sich noch zeigen müssen.

Geht doch auch schon jetzt mit DX oder OpenGL. Macht man nur nicht, da das Problem nur schwer gut lösbar ist und zudem zu umständlich und zu programmieren ist.

 

[MADman_One]

Ein GDDR5 Chip hat 32 Bit, im Clamshell Modus wird er aber mit 16 Bit angebunden, um die doppelte Speichermenge zu ermöglichen. Du widersprichst dir hier auch selbst: 384/32=12. Lt. deiner Aussage hätten also 12 8Gb-Chips verwendet werden müssen, es sind aber 24 4Gb Chips auf dem Board (je 12 auf einer Seite). Davon abgesehen sind 8 Gbps das Maximum, was derzeit zu haben ist – sowohl mit 8 Gb als auch mit 4 Gb, es stimmt also auch nicht, dass größere Speicher langsamer seien.

Richtig, bei den Speicherchips habe ich einen Fehler gemacht, es sind in der Tat 24 Stück bei der Titan X. Und ich habe völlig vergessen, daß nicht größere Chips sondern doppelte Anzahl verwendet werden. Danke für die Korrektur.
Aber ich sagte nicht, daß größere Chips langsamer sind, sondern nur das sie langsamer sein können. Bei PC-Arbeitsspeicher hat man es oft, daß sich größere Module schlechter Takten lassen oder langsamere Timings benötigen. Aber der ganze Punkt ist eh hinfällig, weil er ein Folgefehler meiner ersten Fehlannahme die Speicherchips betreffend ist.

Das ist genau nicht der Fall. SFR und eine API, die dem Entwickler genug Kontrolle über den Speicher gibt, ermöglichen es, effektiv mehr Speicher zu nutzen, indem die Daten verteilt werden. So müssen nicht zwingend alle Geometrie- und Texturdaten redundant in beiden Speichern vorliegen, wie das bei AFR zwingend der Fall ist. Inwieweit sich das mit Vulkan, Mantle und DX12 ausreizen lässt, wird sich noch zeigen müssen.

Das mag in der Theorie so sein, in der Praxis ist mir dazu aber nichts bekannt. Wenn ich derzeit SFR erzwinge bin ich ziemlich sicher, daß keine derartigen Optimierungen angewendet werden. Und ich würde mein SLI nicht anhand von möglicherweise realisierbaren Features planen sondern nur anhand von definitven oder zumindest wahrscheinlichen. Solange sich nVidia also nicht definitiv vom AFR-Modus verabschiedet, werde ich immer ein SLI so konzipieren, daß es auch damit hervorragend funktioniert als darauf zu spekulieren, daß irgendwann man Optimierungen verfügbar sind. Und in dem Fall gilt meines Wissens nach wie vor was ich geschrieben habe.

Aber dennoch ist das Thema interessant, Du hast da sicher Quellen zur Vertiefung für mich ?

 

[moshkopp]

Eine GTX 680 konnte man aber ebenfalls recht gut übertakten, sodass 30-40% schon hinkommen werden zur Titan.

Ich erwarte mir eine ähnliche Leistungssteigerung von GTX 980 zur TitanX.

Die R9 390x kann ich überhaupt nicht einschätzen wegen des HBM Speichers, aber ich vermute zu große Wunder dürfen wegen es selben Fertigungsprozesses auch nicht erwartet werden. Hier würde ich 50% Mehrleistung zur R9 290x erwarten, was wiederum auch 30-40% zur GTX 980 bedeutet.

Dann bliebe natürlich nur noch der größere Speicher und ein evtl. höheres Overclockingpotential auf der Habenseite für die TitanX.
Wenn man dann überlegt, dass die Radeon sicher deutlich günstiger ist, bleibt für die TitanX nur noch eine relativ dünne Käuferschicht. Eben jene die sich sowieso immer wieder ne Titan kaufen würden. ^^

Aber mal schauen, wir können ja eh nur alle spekulieren, auch wenn das eigentlich immer am lustigsten ist

 

[Zuckerwatte]

Was hatten das eigene Kfz mit der Hardware zu tun?
Dann fahren also alle AMD-Boys ne dicke Karre da beim Hardwarepreis so viel gespart wird? Ergo fahren alle Intel + Nvidia Boys, Fahrrad?

Gewagte These ;-)

HAHA mir gefällt die These, da sie gleichzeitig die Idiotie dahinter zeigt.

Persönlich ist das einzige was mich an einer Titan interessieren würde, der wirkliche Mehrnutzen den ich erhalte.

Leider wirkt das hier oft wie "Mein Geschlechtsorgan > dein Geschlechtsorgan" - fürs große Auto, um tiefergelegt mit 120km/h auf der Bahn zu fahren hat es nicht mehr gereicht was?

Scherz bei seite, jeder soll doch bitte sein Geld verbrennen wo er will. Wofür geht man schließlich arbeiten (Sorry alle Schulhofkumpels - ihr seid nur Schnorrer bei euren Eltern )

Was auf Dauer nervt sind nicht die Diskussionen über Leistungsdaten, Leistungsunterschiede, falsch verstandene Sachverhalte oder ähnliches, sondern so "tnoay -Kommentare" (hat bei mir mittlerweile einen Eigennamen)

Für alle wirklich fachlichen Auseinandersetzungen Danke! (tnoay würde ich nicht nehmen. Hab gehört der läuft zu heiß und redet dann immer alte Marketingfloskeln nach - und dabei verbraucht er viel zu viel Nahrung für die wiedergegebene Leistung )

 

[Nai]

Das mag in der Theorie so sein, in der Praxis ist mir dazu aber nichts bekannt. Wenn ich derzeit SFR erzwinge bin ich ziemlich sicher, daß keine derartigen Optimierungen angewendet werden. Und ich würde mein SLI nicht anhand von möglicherweise realisierbaren Features planen sondern nur anhand von definitven oder zumindest wahrscheinlichen. Solange sich nVidia also nicht definitiv vom AFR-Modus verabschiedet, werde ich immer ein SLI so konzipieren, daß es auch damit hervorragend funktioniert als darauf zu spekulieren, daß irgendwann man Optimierungen verfügbar sind. Und in dem Fall gilt meines Wissens nach wie vor was ich geschrieben habe.

AFR ist ein Treiberhack, den die GPU-Hersteller mehr oder weniger unabhängig vom Spiel realisieren können. SFR muss im Programm explizit eingebaut werden, damit es gut funktioniert. Dann funktioniert es allerdings weitestgehend "unabhängig" vom GPU-Hersteller ohne SLI, crossfire oder ähnlichem.

 

[MADman_One]

Und daher verwendet nVidia AFR wahrscheinlich auch so gerne, weil so SLI unabhängig(er) vom eigentlichen Spiel angeboten werden kann.
Da SLI ja ein Enthusiastenwerkzeug ist, sähe es mir der Unterstützung wohl sehr mau aus, wenn man sich dazu vollständig auf die Spielehersteller verlassen müsste. Daher wird es den AFR-Modus wahrscheinlich auch noch lange geben. Wenn sich Spielehersteller Mühe mit SFR machen nehme ich das natürlich auch gerne, aber ich werde mich nicht darauf verlassen.
Es ist schon einige Jahre her, daß ich zuletzt eine einzelne Karte im Rechner hatte. Auch die Titan X wird bei mir entweder wieder im Duo auflaufen oder gar nicht. Das entscheide ich aber erst wenn die finalen Daten und Tests verfügbar sind.

 

[Nai]

Ich denke nicht, dass jemals SFR weit kommen wird, da es einfach zu komplex ist. Denn für ein effizientes SFR muss der Programmierer den Zeichenprozess der Szene auf mehrere GPUs so verteilen, dass:
-Jede GPU die gleiche Rechenlast hat
-Möglichst wenig Rechenoperationen mehrfach auf unterschiedlichen GPUs ausgeführt werden
-Möglichst kein GPU-Speicher überläuft und im Falle eines Überlaufs möglichst wenig Daten selbst bei bewegter Kamera und Lastbalancierung geswappt werden müssen
-Das Kopieren bzw Synchroniseren der Daten Zwischen der GPUs während die GPUs rechnen stattfindet

Ich habe so ein Multi-GPU-Rendering (nicht direkt SFR sondern Compositing) schon einmal für eine sehr einfache Visualisierung implementiert. Das war im Vergleich zu einer Single-GPU-Lösung alles andere als einfach.

 

[Faust2011]

AFR ist ein Treiberhack, den die GPU-Hersteller mehr oder weniger unabhängig vom Spiel realisieren können. SFR muss im Programm explizit eingebaut werden, damit es gut funktioniert. Dann funktioniert es allerdings weitestgehend "unabhängig" vom GPU-Hersteller ohne SLI, crossfire oder ähnlichem.

Ja, und SFR wurde auch bereits implementiert über Mantle. Hier spricht ein Entwickler aus dem Nähkästchen: http://www.firaxis.com/?/blog/single/mantle-multi-gpu-for-civilization-beyond-earth

 

[Krautmaster]

Eine GTX 680 konnte man aber ebenfalls recht gut übertakten, sodass 30-40% schon hinkommen werden zur Titan.

Ich erwarte mir eine ähnliche Leistungssteigerung von GTX 980 zur TitanX.

ich erwarte auch etwa 35% im standard wie bereits geschrieben.

Die GTX 680 war 15-16% OC.

Schaut man es in Relation zu dem PCGH Test (37% TITAN) an oder auch zu CBs GTX 780 31% OC dann kommen übers breite Feld durchaus 50% + hin die eine TITAN OC quasi immer vor der GTX 680 liegt, eher mehr.
Im CB Test zur TITAN lies sich meines Wissens noch die Spannung nicht anheben.

Direkt OC @ CB vergleichen kann man nur über BF3.

GTX 680 kommt dabei MAX OC auf 45,6 FPS, TITAN OC auf 65,3 FPS und da das TITAN OC bei CB echt bescheiden is noch die GTX 780, die OC bei 68 FPS landet also ein Plus von 49%. Bei wie gesagt moderatem OC der TITAN.

 

[GEZ-Verweigerer]

Macht ja auch voll Sinn, einer Karte das maximale OC zu entlocken und dann mit einer Karte mit Standard Takt zu vergleichen. Alle Kepler Karten lassen sich übertakten, von gut bis sehr gut. Man rechnet aber mit dem von nvidia ausgegebenen Reffrenztakt und da ist die Titan minimal schneller als eine GTX 780 und ca 30% schneller als eine GTX 680/770, Basta. Ob sie sich besser übertakten lässt als andere Kepler ist eine völlig andere Sache. Davon ab ist eine derart übertaktete GPU nicht gerade unproblematisch, da Wärme und Kühlungsaufwand exponentiell steigen und sich 37%= OC nicht automatisch überall in 37% mehr fps verwandeln.

GTX 680: 15-16% OC ist schon wieder so eine pseudo-wissenschaftliche Zahl, völlger Humbug, genau wie deine sehr konkreten Vorhersagen betreffs der kommenden Titanx. Wie hoch der GK 104 sich übertakten lässt liegt am Sample, der Kühlung, dem aufgespielten Bios, ob man Zugriff auf Spannungen jenseits der 1,175 Volt kriegt etc, da fallen so viel Faktoren ins Gewicht, dass nur ein Schnacker so konkrete Zahlen nennen würde, sorry.

 

[Nai]

Ja, und SFR wurde auch bereits implementiert über Mantle. Hier spricht ein Entwickler aus dem Nähkästchen: http://www.firaxis.com/?/blog/single...n-beyond-earth

Was ist daran so besonders? Es lässt sich doch bereits schon mit OpenGL oder DirectX implementieren und wurde sicherlich bereits schon 100te male implementiert. Mag sein dass einiges nicht ssoo gut geht, wie zum Beispiel das Kopieren wegen fehlenden Queues in DX oder OpenGL. Des Weiteren ist bei OpenGL problematisch, dass es keine GPUs und dementsprechend kein Multi-GPU kennt. Deshalb ist das Multi-GPU-Handling vom Vendor abhängig. Zum Beispiel geht Multi-GPU bei NVIDIA-GPUs unter Windows nur mit Quadros. Bei DX entfällt dieser Nachteil jedoch.

 

[Krautmaster]

@GEZ-Verweigerer

ich wurde zitiert wie ich zu GTX 680 von 50% + bei der TITAN gesprochen habe (vor Release), ausgehend von den Specs - was offensichtlich drin ist. Egal wieviel OC einzelne GTX 680 bieten. Haste von beiden gute Modelle kommen 50%+ locker hin.

Konkrete % Werte bei OC sind wegen Vergleichbarkeit eben CB entnommen oder meinst du ich halte 15-16% als festgemeiselt für alle GTX 680 . Etwas schwer gemittelte Werte über eine Produktpalette zu finden, oder? Es gibt 2 Ghz GTX680 @ LN2 und auch schlechte TITANs/GTX780 die kaum n Ghz @ Luft machten.

Ich sprach nicht zuletzt meist von vollkommen taktbereinigten % Werten.

Abgesehen davon kann man wohl kaum abstreiten dass bei zB der GTX 780 prozentual deutlich mehr Reserven durch OC freizusetzen waren als bei der GTX 680
CB liefert da natürlich nur Einzelwerte. Im Schnitt kommen die aber auch ganz gut hin.

Was meinst du auf was eine TITAN X bezüglich Mehrleistung zur GTX 980 nun kommt? Ich sag Nvidia wirds etwa auf 25-40%@ Standardtakt rauslaufen lassen vs GTX 980 Referenz. Je nach Konkurrenz & wie sehr die 300W limitieren. Das zeigen dir ja schon die Specs allein bei denen alles fix is, außer der Takt.
Mit steigender Auflösung wird der Abstand wachsen.

P.S.: ich bleib bei meiner Aussage. Bei realistischem gemittelten OC bleibt die TITAN / GTX 780 meist gut 50% schneller als eine GTX 680 mit ebenfalls realistischem OC.
Man könnte jetzt sich Karten zu legen um den Erwartungswert empirisch zu ermitteln.

 

[Faust2011]

Was ist daran so besonders? Es lässt sich doch bereits schon mit OpenGL oder DirectX implementieren und wurde sicherlich bereits schon 100te male implementiert.

Nein, es wurde eben nicht mit OpenGL implementiert, weil man sowas mit OpenGL nicht (!) machen kann. Wie das mit DirectX ist, kann ich nicht beurteilen.

Bisher wurde AFR (alternate frame rendering) verwendet, um Multi-GPU-Systeme auszureizen. Das geht an einer Applikation / Spiel vorbei, d.h. es ist eine reine Graka-Teiber-Aufgabe, beide (oder gar noch mehr) Grafikkarten gleichmäßig auszulasten. Der Witz bei Mantle ist nun: "Mantle API is how it exposes explicit control over all GPUs in a machine to the game developer [...] In order to answer this question, we implemented a split-screen (SFR) multi-GPU solution for the Mantle version of the game. Unlike AFR, SFR breaks a single frame into multiple parts, one per GPU, and processes the parts in parallel, gathering them into the final image at the end of the frame."

 

[Nai]

Wieso sollte das *nicht* möglich sein ? Wie gesagt, ich habe soetwas ähnliches doch schon einmal unter OpenGL gemacht

Vorgehensweise im Falle eines einfachen Forward-Renderings:
-Man sorgt irgendwie, dass man mit OpenGL multiple GPUs ansteuern kann. (Linux kein Problem; unter Windows nimmt man die Vendor-spezifischen Extensions)
-Man setzt den Stencilbuffer (http://de.wikipedia.org/wiki/Stencilbuffer) so dass die 1. GPU nur den einen Teil des Bildes rendert, während die 2. GPU den anderen Teil des Bildes rendert. Da der Stencilbuffer hierarchisch aufgebaut ist, kann die GPU bei der Rasterisierung einen Großteil der Fragmente früh aussortieren. Dadurch muss sie im Endeffekt nur die Fragmente zeichnen, die sich im gesetzten Teil des Stencilbuffers befinden. In der Regel eignet sich ein Schachbrettmuster für den Stencil-Buffer besonders gut. Wenn man lustig ist, kann man noch zusätzlich die Vertexlast reduzieren, indem man noch für jedes zu zeichnende Objekt prüft, ob sich das Objekt überhaupt mit den Frustrums der Schachbrettfelder der gegebenen GPU schneidet. Wenn nicht so braucht man es auf der entsprechenden GPU nicht zu zeichnen.
-Man kombiniert die Bilder der beiden GPUs zum Endergebnis und gibt sie aus.

Alternativ kann man statts dem Stencilbuffer zu verwenden auch selbst ein Clipping im Geometry-Shader an den Frustrums der Schachbrettfelder implementieren. Du siehst es ist problemlos möglich, wenn man etwas Phantasie hat . Deshalb weiß ich auch nicht, wieso das mit Mantle bzw. Vulkan so hoch gelobt wird. Evtl sind es die Queues die das ganze etwas effizienter möglich machen?

 

[SirBerserk]

Milchmädchen-Rechnung, denn es gibt nur eine GPU die Bilder aus, also werden die Bilder der 2. GPU in den Speicher der 1. GPU übertragen, und die muss die 60 Bilder ausgeben.

Na wieviele Monitor-Kabel hast Du denn an Deinem Monitor?
So mal ganz logisch betrachtet.
Da ist ein Kabel, das kommt in einen Anschluss an der Graka.
Und die 2. Graka (beim klassischen SLI/CF)? Die kommt nicht mit an das Kabel.
Also muss doch die eine Graka alle Bilder ausgeben.

also wenn das stimmt, dann hat das zumindest keinerlei auswirkung.

denn wenn alles optimal läuft skalieren sli system bis zu 100%

das wäre unmöglich wenn ein sli system keinen gleichzeitigen zugang zu 762bit speicheranbindung hätte.

desweiteren schätze ich das die Titan X 25-30% langsamer ist als die titan Z schon allein wegen der speicherbandbreite.

 

[MADman_One]

Wie schon gesagt, der Transfer der Ausgabedaten zur ersten Karte ist zu vernachlässigen. Er läuft über den PCIe Flaschenhals, insofern ist die Speicherbandbreite dafür unerheblich. Es handelt sich selbst bei UHD und 60 fps um ca. 1,5 GB/s unkomprimiert. Die Speicherbandbreite hat durch ihren Beitrag zum Speicherdurchsatz nur Bedeutung für den Transfer von Daten zwischen GPU und Speicher, außerhalb spielt er keine Rolle.
Auch bei Dual GPU Karte gilt ähnliches, weil der Speicher dort auch nicht direkt verbunden ist sondern der Austausch über eine Art Brückenchip läuft, wenn ich richtig informiert bin.

Die Titan Z mag schneller bleiben als eine Titan X, aber wenn wird das haupsächlich auf die doppelte GPU-Anzahl zurückzuführen sein und weniger auf die im Ergebnis doppelte Speicherbandbreite. Da die Titan Z GPUs aber mit niedrigerem Takt arbeiten und sich schlecht übertakten lassen, gehe ich davon aus, das eine Titan X incl. OC eine Titan Z überholen können wird.

 

[nurmalkurz]

Mehr Spekulatius http://videocardz.com/55013/nvidia-geforce-gtx-titan-x-3dmark-performance

Wenn das stimmt, wäre es echt etwas ernüchternd. 25-30% mehr Leistung ggü. einer GTX 980. Puh, ob ich den Aufpreis von +500€ mit meinem Gewissen vereinbaren kann?

Ich hoffe, dass sie leise ist. Am besten leiser als eine Referenz GTX 980. Dann würde ich sie mir sogar holen.

 

[MADman_One]

hehe bei mir sähe das anders aus. Sollte das so hinkommen dann wäre sie für mich eine Anschaffung wert, da für mich ja die Differenz zur normalen Titan classic entscheidend ist und nicht zur 980 oder Titan black. Und gegenüber der normalen Titan sind das sehr gute Steigerungen. Wenn sie dann wirklich "nur" um die 1000€ kostet dann wäre das für mich persönlich ok, da müsste ich wahrscheinlich nicht lange überlegen.

Aber ich warte wie gesagt auf die finalen Test und bestätigte Fakten bevor ich irgendeine Entscheidung treffe.

 

[Krautmaster]

Mehr Spekulatius http://videocardz.com/55013/nvidia-geforce-gtx-titan-x-3dmark-performance

Wenn das stimmt, wäre es echt etwas ernüchternd. 25-30% mehr Leistung ggü. einer GTX 980. Puh, ob ich den Aufpreis von +500€ mit meinem Gewissen vereinbaren kann?

andersrum rechnen, nicht die TITAN X sind 100% sondern die GTX 980 wenn man die hier geführte Mehrleistung zur GTX 980 als Basis nimmt.

Wären im 3D Mark Extreme @ TITAN X "standard" - sofern korrekt, ~34-39% im 3D Mark.

Was komisch wäre wäre die TDP die da mit 235W spekuliert wird. Das halte ich für zu wenig.

 

[nurmalkurz]

Was komisch wäre wäre die TDP die da mit 235W spekuliert wird. Das halte ich für zu wenig.

Das halte ich für durchaus möglich. Die 980 hat 165W, jetzt gibt 1024 Shader mehr, dafür aber nur 1GHz. Wir vergleichen ja Referenz vs. Referenz.