Nach langem Warten stellt nVidia heute mit der GeForce GTX 680 und dem zugrundeliegendem GK104-Chip das erste Produkt der Kepler-Architektur vor, mittels welcher nVidia – ähnlich wie AMD bei der GCN-Architektur der Radeon HD 7000 Serie – einen gewissen Stilbruch in der Grafikchip-Architektur vornimmt. Hinzu kommt die spezielle Situation, daß der GK104-Chip eigentlich einmal als Lösung für das Performance-Segment geplant war, nun aber seitens nVidia mittels höherer Taktraten sogar zum Kontrahenten von AMDs bester SingleChip-Lösung Radeon HD 7970 auserkoren wurde und im Zuge dieses Wandels sowohl in der Namenswahl als auch beim Preispunkt kräftig zulegte.
Denn im eigentlichen ist der GK104-Chip der Nachfolger des GF114-Chips der GeForce GTX 560 /Ti und nicht der Nachfolger des GF110-Chips der GeForce GTX 570 & 580 – jener GF110-Chip wird mit dem GK110-Chip im Spätsommer seinen eigenen Nachfolger bekommen. Daß der GK104-Chip trotzdem "mit den Großen mitspielen kann", verdankt dieser Chip maßgeblich zwei Punkten: Erstens einmal hat AMD bei seiner kompletten Radeon HD 7000 Serie doch nur eher maßvoll die Performance-Möglichkeiten der 28nm-Fertigung ausgespielt – und zweitens konnte sich nVidia beim GK104-Chip viel von dem für GPGPU benötigten Einheiten und Transistoren sparen, welche AMD beim R1000/Tahiti und nVidia beim GK110 verbauen müssen.
Fertigung | Chipfläche | Transistoren | |
---|---|---|---|
AMD RV940/Barts -> Pitcairn | 40nm -> 28nm | 255mm² -> 212mm² | 1,7 Mrd. -> 2,8 Mrd. |
AMD RV970/Cayman -> R1000/Tahiti | 40nm -> 28nm | 389mm² -> 365mm² | 2,64 Mrd. -> 4,313 Mrd. |
nVidia GF114 -> GK104 | 40nm -> 28nm | 358mm² -> 294mm² | 1,95 Mrd. -> 3,54 Mrd. |
nVidia GF110 -> GK110 | 40nm -> 28nm | 520mm² -> ~550mm² | 3 Mrd. -> ~6 Mrd. |
So kommt es zu der eigentlich irritierenden Situation, daß der GK104-Chip mit einer klar kleineren Chipfläche von nur 294mm² gegen den R1000/Tahiti-Chip von AMD mit einer Chipfläche von 365mm² antritt – und trotzdem bezüglich der Spiele-Performance absolut auf Augenhöhe operiert. Einfach ausgedrückt steht hier seitens AMD ein Spiele/GPGPU-Mehrzweckchip gegen einen seitens nVidia maßgeblich nur auf den Spieleeinsatz ausgerichteten Chip. Daneben hat nVidia die Vorteile der Fermi-Architektur beim Frontend der Grafikchip-Architektur nach Kepler transferiert, bietet also die weiterhin höhere Rasterpower – was besonders bei solcherart HighEnd-Chips mit vielen Recheneinheiten wichtig ist, um diese auch sinnvoll auslasten zu können (ein deutliches Problem von R1000/Tahiti).
Radeon HD 7950 | Radeon HD 7970 | GeForce GTX 580 | GeForce GTX 680 | |
---|---|---|---|---|
Chipbasis | AMD R1000/Tahiti, 4,3 Milliarden Transistoren in 28nm auf 365mm² Chip-Fläche | nVidia GF110, 3 Milliarden Transistoren in 40nm auf ca. 520mm² Chip-Fläche | nVidia GK104, 3,54 Milliarden Transistoren in 28mn auf 294mm² Chip-Fläche | |
Technik | DirectX 11.1, 2 Raster Engines, 1792 (1D) Shader-Einheiten, 112 TMUs, 32 ROPs, 384 Bit DDR Interface | DirectX 11.1, 2 Raster Engines, 2048 (1D) Shader-Einheiten, 128 TMUs, 32 ROPs, 384 Bit DDR Interface | DirectX 11, 4 Raster Engines, 512 (1D) Shader-Einheiten, 64 TMUs, 48 ROPs, 384 Bit DDR Interface | DirectX 11.1, 4 Raster Engines, 1536 (1D) Shader-Einheiten, 128 TMUs, 32 ROPs, 256 Bit DDR Interface |
Taktraten | 800/2500 MHz | 925/2750 MHz | 772/1544/2000 MHz | 1006/3000 MHz (GPU-Boost Ø 1058 MHz, max. 1124 MHz) |
Speicherausbau | 1536 oder 3072 MB GDDR5 | 3072 MB GDDR5 | 1536 oder 3072 MB GDDR5 | 2048 MB GDDR5 |
PCI Express | PCI Express 1.x/2.0/3.0 | PCI Express 1.x/2.0/3.0 | PCI Express 1.x/2.0 | PCI Express 1.x/2.0/3.0 |
Layout | SingleSlot & DualSlot | DualSlot | DualSlot | DualSlot |
Kartenlänge | 281mm | 281mm | 267mm | 26cm |
Stromanschlüsse | 2x 6pol. | 1x 6pol. + 1x 8pol. | 1x 6pol. + 1x 8pol. | 2x 6pol. |
TDP/MGCP | 200W | 250W | 244W | 195W |
Idle-Verbrauch | 16W | 14W | 31W | ~15W |
Spieleverbrauch | 154W | 211W | 238W | ~190W |
Perform.index | 290% | 330% | 280% | 360% |
Preislage | 380-410 Euro | 450-480 Euro | 340-380 Euro | 480-520 Euro |
Demzufolge ist es am Ende nicht ganz verwunderlich, wenn nVidia die gleiche Spiele-Performance aus der etwas geringeren Anzahl an Shader-Einheiten herausholt, welche sich nunmehr zwischen AMD- und nVidia seit langer Zeit mal wieder ganz gut vergleichen lassen. Hier liegt dann auch der hauptsächliche Unterschied zwischen Fermi und Kepler: nVidia verabschiedet sich mit Kepler von den Shader-Einheiten mit Hotclocks und geht wie bei AMD zu sehen auf einfacher umzusetzende Shader-Einheiten mit regulärem Chiptakt – von denen man dann eben auch viel mehr verbauen kann. Dabei erhöht nVidia im Vergleich der Grafikchips GK114 zu GK104 die Anzahl der Shader-Einheiten aber nicht nur um den Faktor 2 (um den Wegfall der Hotclocks auszugleichen), sondern gleich um den Faktor 4 – kommt also noch ohne Berücksichtigung der gestiegenen Taktraten schon auf die verdoppelte Shader-Leistung.
Hinzu kommt dann noch der auf 1006 MHz gestiegende Chiptakt, welcher ein wenig den Vorteil von AMDs höherer Anzahl an Shader-Einheiten abknabbert. Dieser Unterschied wird weiter reduziert durch das GPU-Boost Feature, welches eine dynamische Übertaktung des Chips vornimmt, bis ein im BIOS der Grafikkarte festgesetzter TDP-Wert erreicht wird. Der von nVidia diesbezüglich angegebene Boost-Takt von 1058 MHz bei der GeForce GTX 680 stellt aber nur einen Mittelwert dar, welchen nVidia garantieren will – sofern die Karte aber mehr Spielraum feststellt, taktet sie sich auch höher. In verschiedenen Tests wurden hierbei Höchst-Taktraten zwischen 1110 und 1124 MHz festgestellt – gegenüber der default-Taktrate sind dies beachtbare 10 bis 12 Prozent, gegenüber dem "garantierten" Boost-Takt von 1058 MHz dann 5 bis 6 Prozent.
Letzterer Wert ist jener, um welchen Benchmark-Werte zu GeForce GTX 680 Karten in theoretischen Konstruktionen aufgrund GPU-Boost voneinander abweichen können – denn die 1058 MHz Boost-Takt garantiert nVidia schließlich. In der Praxis dürfte es aber zum einen kaum Situationen geben, wo die eine Karte nicht über diese 1058 MHz hinauskommt und die nächste dann locker 1124 MHz schafft. Hinzu kommt, daß der GPU-Boost in aller Regel nur Teile eines Benchmark-Durchlaufs beschleunigt – logischerweise zumeist diese Teile, wo die Grafikkarte weniger als üblich zu tun hat und daher (ohne GPU-Boost) unterhalb ihres TDP-Limits liegt. In der Praxis kann GPU-Boost damit selbst unter wirklich schlechten Bedingungen für vielleicht bis zu 3 Prozent Performance-Different stehen, im Normalfall dürften es ein bis zwei Prozent sein, was nahe der allgemeinen Meßungenauigkeit liegt.
Allerdings besteht bei GPU-Boost die Befürchtung, daß das Feature für die Spiele-Praxis möglicherweise unnütz ist und faktisch nur Benchmark beschleunigt – vulgo Balken-Länge produziert. Denn hochgetaktet wird schließlich nur dann, wenn der Grafikchip durch das Spiel nicht vollens ausgelastet ist. Wenn der Grafikchip aber beispielsweise nur in den sowieso schnellen Szenen hochtaktet, dann werden aus 100 fps eben 110 fps, was zwar zwar gut für einen Benchmark erscheint, in der Spiele-Praxis aber ohne Belang ist – dort interessiert eher die Beschleunigung der langsamen Szenen von unter 50 fps. Diesbezüglich gibt es nun die Befürchtung, daß GPU-Boost in diesen langsamen Szenen nicht oder nur unterdurchschnittlich hochtaktet, weil der Grafikchip gemäß allgemeiner Theorie in den eher langsamen Spiele-Szenen ja schon voll ausgelastet ist und daher keine (oder weniger) TDP-Reserven haben sollte.
Diese Erläuterung hört sich erst einmal plausibel an – und trifft aber wahrscheinlich nicht auf die Realität des Wirkens eines Grafikchips zu. Wenn ein Grafikchip mal eine wirklich schwere Spiel-Szene zu bewältigen hat, wo die Framerate also wirklich heruntergeht, dann ist der Grafikchip zwar in der Tat schwer am Arbeiten – aber höchstwahrscheinlich limitiert gerade bei einer sehr niedrigen Framerate zuerst ausschließlich eine einzelne Ausführungseinheit (Rasterizer, Tesselation Shader-Einheiten, Texturen-Einheiten, Special Function Units, ROPs, etc.) und die anderen Ausführungseinheiten drehen Däumchen bzw. warten auf neue Daten. In dieser Situation dürfte der Grafikchip gerade sehr viele TDP-Reserven haben, weil halt der gesamte Arbeitsfluß an nur einer Kategorie von Ausführungseinheiten hängt und der Rest der Ausführungseinheiten demzufolge teilweise stark unterausgelastet ist.
Trifft diese Theorie zu (und mehr als eine Theorie ist sie derzeit nicht), dann würde GPU-Boost vermutlich gerade dann das Spiel beschleunigen, wenn die Framerate durch irgendeinen Effekt mal deutlich nach unten fällt. Einfaches Beispiel: Die allseits beliebte Rauchgranate, welche die Framerate für ein paar Sekunden herb nach unten drückt. In dieser Zeitspanne dürfte kaum der ganze Grafikchip nur an dem Raucheffekt und davon ausgelösten Seiteneffekten arbeiten, sondern vermutlich limitiert nur eine einzelne Ausführungseinheit die ganze Arbeit im Chip. Die restlichen Einheiten langweilen sich also, verbrauchen daher weniger Strom und mehr Platz unter der TDP entsteht – der GPU-Boost geht unter Umständen auf sein Maximum und beschleunigt diese Szene durch den höheren Chiptakt um immerhin 10 Prozent.
Sofern es solcherart funktioniert, wäre GPU-Boost nicht nur ein Feature für die Balkenlänge in Benchmarks (welche natürlich trotzdem immer das erste Hersteller-Augenmerk genießen), sondern auch ein herzlich willkommenes Feature im Spiele-Einsatz. Allerdings gibt es bislang keinerlei Bestätigung über das konkrete Detailwirken von GPU-Boost sowie viel zu wenig Erfahrungswerte mit diesem Feature, um diese Auslegung der Dinge schon beschreien zu können. Genauso gut kann auch die vorherige Theorie zutreffen, daß GPU-Boost nur dann beschleunigt, wenn es sowieso eine ausreichend hohe Framerate gibt und somit maßgeblich nur größere Balkenlängen, aber weniger Praxiseffekt erzielt. Man wird diese Thematik weiter beobachten müssen, um hier später einmal zu einem Urteil zu gelangen.
Im übrigen besitzt GPU-Boost auch eine Untertaktfunktion, welche bis auf 640 MHz Chip-Taktrate herunterführt und dafür gedacht ist, den Chip bei zu großer Belastung zu entlasten, um letztlich die gesetzte TDP einhalten zu können. In diesem Augenblick funktioniert nVidias GPU-Boost dann wie AMDs PowerTune, wo das Abriegeln einer zu großen Last im Vordergrund steht. Allerdings sollte diese Untertaktfunktion im Normalfall beiderseits nicht greifen, diese ist vielmehr für (die Grafikchips untypisch hoch auslastenden) "Powerviren" wie den FurMark gedacht. Beim Übertakten der GeForce GTX 680 ist dann jedoch an diese Abriegel-Funktionalität zu denken und somit ebenfalls das TDP-Limit der zu übertakteten Grafikkarte zu erhöhen (möglich mit bis zu 30 Prozent Zuschlag) – ansonsten rennt sich die Übertaktung nämlich schlicht am regulären TDP-Limit von 195 Watt fest, was schon bei einer geringen Übertaktung der Fall sein dürfte.
Daneben hat nVidia der Kepler-Architektur noch weitere interessante Features spendiert: "Adaptive Vsync" schaltet Vsync dynamisch aus, wenn die 60-fps-Marke sowieso nicht erreicht wird und nimmt damit zwar Tearing unterhalb dieser fps-Marke in Kauf, vermindert aber die auffallenden und damit störenden Frameraten-Sprünge zwischen glatt 15, 30 und 60 fps bei aktivem Vsync. In der Praxis scheint das Feature gut zu funktionieren und der Tausch von etwas Tearing gegenüber einer "weicheren" Frameausgaben den Hardware-Testern zu gefallen. Desweiteren unterstützt nVidia nunmehr auch Surround-Gaming mit nur einer Grafikkarte, bisher waren hierfür immer mindestens zwei nVidia-Beschleuniger notwendig. Insgesamt können mit einer einzelnen GeForce GTX 680 nunmehr bis zu vier Monitore angesteuert werden.
Im Bereich der Anti-Aliasing-Modi bietet nVidia zum einen das verbesserten FXAA 4.0 an, welches – ähnlich AMDs MLAA – ein Blurfilter ist, der per Shader-Programm Kanten zu erkennen und diese zu glätten versucht, dies aber mit einem gewissen zusätzlichen Unschärfegrad auf das ganze Bild bezahlt. Die Unschärfewirkung ist dabei geringer als bei AMDs MLAA, aber dennoch vorhanden, so daß bei Vorhandensein einer Alternative zu MLAA und FXAA regelmäßig diese empfohlen wird. Ansonsten hat FXAA (wie MLAA) aber (theoretisch) den Vorteil, in jedem Spiel (und ohne Support des Spieleherstellers) funktionieren zu können – ironischerweise traft dies ausgerechnet beim FXAA 4.0 der GeForce GTX 680 im Testbericht der ComputerBase nicht zu, hier liefen einige bekannte Spiele unerwarteterweise nicht unter FXAA 4.0.
Das zweite neue Anti-Aliasing-Verfahren hört auf den Namen TXAA und bietet eine Zusammenführung von normalem Multisampling Anti-Aliasing mit FXAA an. Dabei wird unter TXAA1 schlicht 2x Multisampling Anti-Aliasing mit FXAA kombiniert und unter TXAA2 dann 4x Multisampling Anti-Aliasing mit FXAA. Allerdings gibt es beim hier eingemischten Multisampling Anti-Aliasing eine Besonderheit – die AA-Samples beziehen auch Informationen vom Nebenpixel mit ein und können damit eine bessere Kantenglättungswirkung erreichen. In der Summe sieht nVidia TXAA1 in der Qualität noch vor regulärem 8x Multisampling Anti-Aliasing, aber nur auf den Performance-Anforderungen von 2x Multisampling Anti-Aliasing – dies wäre in der Tat hochinteressant. Da TXAA aber in jedem Fall vom Spielehersteller unterstützt werden muß, gibt es derzeit noch keine praktischen Erfahrungen mit diesem Feature und muß daher dessen Beurteilung in die Zukunft verschoben werden.
Und letztlich kann man bei der über externe Tools wie dem EVGA Precision verfügbaren Option "Frame Rate Targets" ein freies fps-Limit angeben, für welche die Grafikkarte auch nur mit dieser Taktrate (und diesen Spannungen) operiert, die für das Erreichen diese Framerate ausreichend ist. Damit ist es möglich, eher sinnlose Frameraten oberhalb von 60 fps gar nicht erst zu produzieren, was nicht nur Strom spart, sondern die Grafikkarte auch (dauerhaft) weniger heiß arbeiten läßt, was Lüfterdrehzahlen und das Ausfallrisiko der Hardware senkt. Wie der Praxixtest der ComputerBase zu diesem Feature zeigt, funktioniert jene Option absolut hervorragend und kann teilweise deutliche Gewinne bei Stromverbrauch, Chip-Temperatur und Lüfter-Lautstärke hinlegen.