GK104 - Gamer-Kepler - Architektur-Thread [Archiv]

AnarchX

2012-03-22, 11:35:40

Dieser Thread dient zur Diskussion über die architektonischen Konzepte hinter GK104 und der Analyse spezifischer Workloads.

PCinlife bietet einen guten, ersten Einblick auf Basis vieler direkter Leistungsmessungen (Geometrie, Füllrate, ALU-Leistung):
http://pc.pcinlife.com/Graphics/20120322/GeForce-GTX-680.html#%E5%89%8D%E8%A8%80

Whitepaper von NV:
http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf

Hardware.fr - Pixel und Geometrie:
http://www.hardware.fr/articles/857-9/performances-theoriques-pixels.html
http://www.hardware.fr/articles/857-10/performances-theoriques-geometrie.html

boxleitnerb

2012-03-22, 12:04:12

Die Metrik "Füllrate/ROP*Takt" ist interessant. Hier erreichen AMD-Karten Werte von praktisch 1, Geforces liegen hier deutlich darunter und streuen auch massiv zwischen 2x, 4x und 8xAA. Warum ist das so?

Spasstiger

2012-03-22, 12:09:10

Bei AMD ist die Pixelfüllrate erst durch die ROPs limitiert, bei NV limitieren die SMs.

AnarchX

2012-03-22, 12:10:28

Wobei GK104 4 Pixel pro SM liefern sollte und damit die ROPs voll auslasten
Bei 2xMSAA gibt es einen eigenartigen Knick bei Nvidia unter "FFP PureFillrate".

Bei abhängigen Skalaren (1D) fällt das superskalare Konzept von GK104 ähnlich wie GF104 wieder auf 2/3 des Durchsatzes:
http://www.pcinlife.com/article_photo/gtx_680/results/instruction_02.png
... da bleiben dann nur in etwa der Taktunterschied zwischen GF110 und GK104 übrig. Tahiti setzt sich um ~60% ab.

AnarchX

2012-03-22, 13:33:22

http://www.ixbt.com/video3/images/gk104/scheduling.png
von: http://www.ixbt.com/video3/gk104-part1.shtml

Also wird nicht mehr bei Laufzeit entschieden, welcher Port welche Instruktion freigibt.
Dadurch hat man wohl auch ein paar Transistoren eingespart.

AnarchX

2012-03-22, 13:55:30

Whitepaper:
http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf
via: http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-680

Cache:
L2 Cache

In addition to offering dedicated L1, texture, uniform, and instruction caches, Kepler also features a unified 512KB L2 cache that provides an additional storage buffer for the above-listed units and is shared across the GPU.
To support the increased processing horsepower of the SMX cores, GeForce GTX 680’s L2 cache hit bandwidth has increased by 73%. Atomic operation throughput has also been significantly increased—particularly for atomic operations to a single common address. The following table summarizes GeForce GTX 580 vs. GeForce GTX 680 throughput for L2 operations

Atomic op (shared address) ist 9-mal so schnell wie auf GF110.

Spasstiger

2012-03-22, 14:35:22

Lustig, wie Nvidia das Weglassen von Scheduler-Hardware und die daraus resultierende Abhängigkeit vom Compiler als Vorteil verkauft:

More importantly, the scheduling functions have been redesigned with a focus on power efficiency. For example: Both Kepler and Fermi schedulers contain similar hardware units to handle scheduling functions, including, (a) register scoreboarding for long latency operations (texture and load), (b) inter-warp scheduling decisions (e.g., pick the best warp to go next among eligible candidates), and (c) thread block level scheduling (e.g., the GigaThread engine); however, Fermi’s scheduler also contains a complex hardware stage to prevent data hazards in the math datapath itself. A multi-port register scoreboard keeps track of any registers that are not yet ready with valid data, and a dependency checker block analyzes register usage across a multitude of fully decoded warp instructions against the scoreboard, to determine which are eligible to issue.

For Kepler, we realized that since this information is deterministic (the math pipeline latencies are not variable), it is possible for the compiler to determine up front when instructions will be ready to issue, and provide this information in the instruction itself. This allowed us to replace several complex and power-expensive blocks with a simple hardware block that extracts the pre-determined latency information and uses it to mask out warps from eligibility at the inter-warp scheduler stage.
(Aus dem Whitepaper)

Liest sich so, als ob die komplexe Scheduler-Hardware von Fermi unnötig war. Aber die Ings. hatten sicherlich ihre Gründe.

AnarchX

2012-03-22, 14:51:18

Kann das stimmen oder schreibt Techreport das Unsinn?

The organization of the SMX's execution units isn't truly apparent in the diagram above. Although Nvidia likes to talk about them as individual "cores," the ALUs are actually grouped into execution units of varying widths. In the SMX, there are four 16-ALU-wide vector execution units and four 32-wide units. Each of the four schedulers in the diagram above is associated with one vec16 unit and one vec32 unit.
http://techreport.com/articles.x/22653

Spasstiger

2012-03-22, 15:00:20

Eine Frage aus dem Speku-Thread von mir hat sich nun beantwortet:
Hat NV den Speichercontroller eigentlich komplett neu entwickelt? 50% gesteigerte Datenraten können ja nicht alleine vom Fertigungsprozess des Die kommen.
Im Whitepaper wird die Frage so beantwortet:
For Kepler, the memory team developed a completely new IO design built to push to the theoretical limits of GDDR5 signaling speed. In order to meet this ambitious goal, extensive improvements in circuit and physical design, link training, and signal integrity were made based on in-depth study of our existing silicon. The significant improvement in speed was only made possible by a highly integrated cross-functional effort that enables the co-optimization of these three major areas of improvements. The result was the industry’s first 6Gbps GDDR5 product.
Quelle: Whitepaper, S. 14

Wenn das in der darüber platzierten Grafik ein 6-Gbps-Auge ist, dann ist auch noch Spielraum bis an die Grenzen der GDDR5-Roadmaps (7-8 Gbps) vorhanden.

rudl

2012-03-22, 15:10:37

AHAHHHH OpenCL performance unterirdisch XD
und vor amd schrecke ich leider noch immer zurück wegen linux treiber.

:((( dann wird halt gar nix gekauft und meine alte graka bleibt noch ein wenig im rechner.

AnarchX

2012-03-22, 15:12:28

PCGH hat NV zum LuxMark-Ergebnis befragt:
Die Leistung der Geforce GTX 680 in diesem Benchmark ist mit gerade einmal 12 bis 18 Prozent mehr als bei der GTX 560 Ti erschreckend schwach - Nvidia bestätigte uns allerdings, dass dies ein erwartetes Verhalten sei, da man die GTX 680 stark auf Gaming-Leistung und Energieeffizienz hin optimiert habe. So erreicht sie nur mehr rund 25 Prozent der HD-7970-Leistung in diesem Compute-Benchmark.
http://www.pcgameshardware.de/aid,873907/Test-Geforce-GTX-680-Kepler-GK104/Grafikkarte/Test/?page=17

Ob das wirklich am Design liegt oder ist der Treiber nicht ausgereift bzw. für GeForce limitiert?

rudl

2012-03-22, 15:15:20

der treiber ist schon seit den 280ern schlecht, teilweise halbiert, das sind schon 8 monate!!! ich glaube mittlerweile nvidia ist nicht an guter opencl performance interessiert.
275er ist der letzte gute.

Aber selbst mit doppelter performance wäre die karte jetzt nicht das was ich mir erhofft hätte

AnarchX

2012-03-22, 15:53:12

Nvidia tells us LuxMark isn't a target for driver optimization and may never be.
http://techreport.com/articles.x/22653/7

deekey777

2012-03-22, 17:54:56

http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2
The other change coming from GF114 is the mysterious block #15, the CUDA FP64 block. In order to conserve die space while still offering FP64 capabilities on GF114, NVIDIA only made one of the three CUDA core blocks FP64 capable. In turn that block of CUDA cores could execute FP64 instructions at a rate of ¼ FP32 performance, which gave the SM a total FP64 throughput rate of 1/12th FP32. In GK104 none of the regular CUDA core blocks are FP64 capable; in its place we have what we’re calling the CUDA FP64 block.

The CUDA FP64 block contains 8 special CUDA cores that are not part of the general CUDA core count and are not in any of NVIDIA’s diagrams. These CUDA cores can only do and are only used for FP64 math. What more, the CUDA FP64 block has a very special execution rate: 1/1 FP32. With only 8 CUDA cores in this block it takes NVIDIA 4 cycles to execute a whole warp, but each quarter of the warp is done at full speed as opposed to ½, ¼, or any other fractional speed that previous architectures have operated at. Altogether GK104’s FP64 performance is very low at only 1/24 FP32 (1/6 * ¼), but the mere existence of the CUDA FP64 block is quite interesting because it’s the very first time we’ve seen 1/1 FP32 execution speed. Big Kepler may not end up resembling GK104, but if it does then it may be an extremely potent FP64 processor if it’s built out of CUDA FP64 blocks.

AnarchX

2012-03-22, 18:01:18

Vielleicht haben diese Cores auch PhysX-Funktionen. :ulol:

Laut SiSoft-Sandra liegt die FP64 Leistung bei 1/16 (http://www.tomshardware.de/geforce-gtx-680-test-benchmarks-Kepler-GK104,testberichte-240979-14.html).
Carsten meint wohl 1/12. (http://www.pcgameshardware.de/aid,873907/Test-Geforce-GTX-680-Kepler-GK104/Grafikkarte/Test/?page=2)

deekey777

2012-03-22, 18:09:22

...
Laut SiSoft-Sandra liegt die FP64 Leistung bei 1/16 (http://www.tomshardware.de/geforce-gtx-680-test-benchmarks-Kepler-GK104,testberichte-240979-14.html).
Das FP64-Ergebnis ist nur ein Sechzehntel des FP32-Ergebnisses. Das ist schon etwas anderes.
Carsten meint wohl 1/12. (http://www.pcgameshardware.de/aid,873907/Test-Geforce-GTX-680-Kepler-GK104/Grafikkarte/Test/?page=2)

Für mich wirkt das, ob er das einfach annimmt. Das Whitepaper schweigt dazu, wenn ich nichts übersehen habe.

AnarchX

2012-03-22, 21:18:32

Noch eine Bestätigung der 1/24: http://forum.beyond3d.com/showpost.php?p=1631030&postcount=3455

boxleitnerb

2012-03-22, 23:11:33

Kann man sagen, woran es generell liegt, dass höhere Auflösungen AMD besser liegen? Was müsste Nvidia verbessern, um hier aufzuholen bzw. zu überholen?

AnarchX

2012-03-22, 23:23:34

Aufholen/Überholen? In den meisten Tests hält die GTX 680 doch gut mit in hohen Auflösungen, auch mit mehr als einem Display.

dildo4u

2012-03-22, 23:31:12

Kann man sagen, woran es generell liegt, dass höhere Auflösungen AMD besser liegen? Was müsste Nvidia verbessern, um hier aufzuholen bzw. zu überholen?
Mit 2560x1600 8XAA liegt sie sogar ein Tick besser als mit 4XAA kein Plan warum.
http://www.computerbase.de/artikel/grafikkarten/2012/test-nvidia-geforce-gtx-680/12/#abschnitt_leistung_mit_aaaf

deekey777

2012-03-22, 23:38:33

Kann man sagen, woran es generell liegt, dass höhere Auflösungen AMD besser liegen? Was müsste Nvidia verbessern, um hier aufzuholen bzw. zu überholen?
Meine unprofessionelle Meinung:
Es ist eher so, dass niedrigere Auflösungen den Radeons nicht schmecken. Es sind ja Rasterizer: Das Bild wird in Kacheln zerteilt, die 64 Pixel enthalten (oder eben 16 Quads). Im Idealfall sind alle Pixel eines Dreiecks in so einer Kachel. aber die Welt ist nicht ideal, also kann es schnell passieren, dass dass nur wenige volle Quads zu einem Dreieck gehören (oder nur ein Pixel eines Quads), dennoch müssen die "fremden" Quads mitberechnet werden; oder die Kachel muss mit anderen Quads gefüllt werden, um auf 64 Pixel zu kommen. Mit steigender Auflösung passen dann mehr sichtbare Quads in die einzelnen Kacheln, also dreht die Radeon weniger leere Runden.

Die Geforces sind da einfach viel früher effizienter, so dass ihre Effizienz mit steigender Auflösung nicht so deutlich zum Vorschein kommt.

Mit 2560x1600 8XAA liegt sie sogar ein Tick besser als mit 4XAA kein Plan warum.
http://www.computerbase.de/artikel/grafikkarten/2012/test-nvidia-geforce-gtx-680/12/#abschnitt_leistung_mit_aaaf
Was haben MSAA-Tests mit seiner Frage zu tun?

Coda

2012-03-22, 23:59:38

Es sind nicht nur die Rasterizer, bei AMD ist auch die generelle Compute-Granularität größer (64 statt 32).

Größere Auflösungen = Größere Dreiecke = weniger Verschnitt.

Siegfried

2012-03-23, 00:22:05

weiß schon wer wie es mit dpc-latenzen aussieht?

boxleitnerb

2012-03-23, 07:15:20

Aufholen/Überholen? In den meisten Tests hält die GTX 680 doch gut mit in hohen Auflösungen, auch mit mehr als einem Display.

Ja aber der Vorsprung schmilzt eigentlich fast immer ggü. niedrigeren Auflösungen. Schau dir mal den Skalierungstest bei CB an, das meine ich.

G3cko

2012-03-23, 09:41:01

Mit der acht-fachen Kantenglättung sieht es ähnlich aus. In 1920x1080 arbeitet die GeForce-Version sieben Prozent schneller als die Radeon HD 7970 und bietet 29 Prozent mehr Bilder pro Sekunde als der Vorgänger. In der höchsten Auflösung liegen die beiden Flaggschiffe erneut gleich auf.

Sieht doch ein Blinder das, je höher die Einstellung sie stärker einbricht gegenüber der 7970. Mal mehr mal weniger...:eek:

AnarchX

2012-03-23, 09:52:48

Trotz allem klang seine Frage eher so, dass man deutlich hinter der 7970 läge, was aber nicht so der Fall ist.

Warum Tahiti in niedrigen Auflösungen hat, wurde geklärt.
Eine Lösung für GK104 wäre wohl mehr Bandbreite und vielleicht noch mehr ALUs pro SMX.

btw.
Real World Techs Betrachtung von GK104: http://www.realworldtech.com/page.cfm?ArticleID=RWT032212172023

Kepler’s Dynamic Voltage and Frequency Scaling (DVFS) is a relatively simple, platform level approach. The GPU power is directly measured using the VRMs. The driver is responsible for selecting a frequency and voltage pair, based on the measured power and temperature and a limit that the user can set (which should be welcome by overclockers). Most DVFS systems do not measure current or power directly, because external measurements are very high latency. Instead, on-die performance counters are used to quickly estimate the switching activity and power draw

AnarchX

2012-03-23, 17:27:49

GeForce GK104 darf wohl ungedrosselt tessellieren:

http://techreport.com/r.x/geforce-gtx-680/tessmark-x64.gif

http://techreport.com/articles.x/22653/6

Dural

2012-03-23, 17:50:31

7870 vor der 7970 :freak:

aber krass wie der GK104 abgeht, wenn ich da erst an GK110 denke :eek:

AnarchX

2012-03-23, 17:53:32

w0mbat

2012-03-23, 17:53:45

oder LM110 erst!

Godmode

2012-03-23, 17:55:23

GeForce GK104 darf wohl ungedrosselt tessellieren:

http://techreport.com/r.x/geforce-gtx-680/tessmark-x64.gif

http://techreport.com/articles.x/22653/6

War GF110 gedrosselt, was Tesselation angeht?

Raff

2012-03-23, 17:59:31

7870 vor der 7970 :freak:

aber krass wie der GK104 abgeht, wenn ich da erst an GK110 denke :eek:

Tja, Pitcairn XT darf eben mit 1 GHz "upsetten", Tahiti XT nur mit 925. Aber das soll sich ja bald ändern.

MfG,
Raff

AnarchX

2012-03-23, 18:11:27

War GF110 gedrosselt, was Tesselation angeht?
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8357870#post8357870

Ja, wohl alle GeForce bis auf GTX 550 Ti und kleiner.

Godmode

2012-03-24, 13:18:16

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8357870#post8357870

Ja, wohl alle GeForce bis auf GTX 550 Ti und kleiner.

Ah danke, das ist mir entfallen!

=Floi=

2012-03-24, 13:35:47

gibt es von der 580er oder 480er auch ein whitepaper?

crux2005

2012-03-24, 15:36:50

Ja, für GF100. Ver. 1.0 - 1.4. Die GF110 hatte AFAIK keinen whitepaper.
http://www.nvidia.de/object/GTX_400_architecture_de.html
http://www.nvidia.de/object/IO_89569.html
http://www.nvidia.de/object/IO_89570.html

LOL, die Ver. auf der nVidia Seite ist sogar 1.5 :D

Superheld

2012-03-24, 16:54:15

http://www.abload.de/img/1tqass.jpg (http://www.abload.de/image.php?img=1tqass.jpg)

http://www.hardwareluxx.de/community/f14/gtx-680-vs-7970-gtx-680-vs-580-a-881081.html

Gipsel

2012-03-28, 19:43:40

Hardware.fr hat endliche seine Theorie-Tests hinzugefügt:
http://www.hardware.fr/articles/857-9/performances-theoriques-pixels.html
http://www.hardware.fr/articles/857-10/performances-theoriques-geometrie.html

Die ROPs können wohl nun Fullspeed-FP10.
Nur beim reinen Schreiben, beim Blending nicht (AMDs können auch das Fullspeed). Etwas eigenartig ist das Blending-Resultat mit FP64. Das sollte eigentlich prinzipiell hart durch die Speicherbandbreite limitiert sein (falls die ROPs schnell genug können). Jeder Pixel im Framebuffer wird genau einmal mit Blending geschrieben (dachte ich zumindest bisher immer), so daß Caching bei reinen Füllratentests nicht so viel helfen (außer die Bandbreitennutzung des Speicherinterface zu optimieren, da ganze Framebuffertiles in den Caches getauscht werden). GTX680 erreicht aber angeblich 16 Gpixel/s, was genau 256 GB/s Bandbreite erfordert. Die hat eine GTX680 aber gar nicht (und die Caches sollten wie gesagt nicht helfen).
Hat Kepler eine immer aktive (also nicht nur bei MSAA) Framebufferkompression irgend einer Art? Oder macht einfach der dort benutzte Füllratentest nicht das, was ich denke (so daß die ROP-Caches unter Umständen doch helfen können) bzw. funktionieren die ROP-Caches fundamental anders als bisher?

Captain Future

2012-03-28, 19:52:30

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8357870#post8357870

Ja, wohl alle GeForce bis auf GTX 550 Ti und kleiner.
Da kriegst du aber was durcheinander: Das Triangle-Setup is gebremst und zwar auf 1/2 bei aktuellen Zeichnen der Geometrie, nicht beim Verwerfen. Das nicht mehr tesselliert als gezeichnet wird, ist auf den Rückstau zurückzuführen.

Also:
Geforce ist gedrosselt beim Dreiecks-Setup. Tessellation darf sie so schnell sie kann machen (3,5 tri/s (http://www.gpu-tech.org/content.php/138-GF100-vs.-Archmark-3-51-Triangles-per-clock)), wird, wenn das ganze gezeichnet werden soll, aber wieder durch obiges gebremst.

AnarchX

2012-05-12, 19:13:57

dildo4u

2012-05-16, 00:49:24

NVIDIA Kepler real-time raytracing demo at GTC 2012

http://youtu.be/h5mRRElXy-w?hd=1

Gipsel

2012-05-16, 14:46:56

http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=42764&stc=1&d=1336842693
2.0 GF110
2.1 GF114
3.0 GK104

http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA_C_Programming_Guide.pdf S.74

Da ist der Durchsatz für bestimmte Operationen gegenüber Fermi schon deutlich gesunken.
Aber immerhin nicht so stark wie befürchtet. Die haben scheinbar ein silent Update der Tabelle gemacht, ursprünglich sah die Tabelle so aus:
42813
Die extrem niedrige Integer Shift- und Vergleichs-Performance (nur ein Viertel der Integer-Multiplikationen :freak:) sah irgendwie auch sehr merkwürdig aus. Außerdem paßten die Raten von 168 Int-ADDs und 136 logische Operationen pro SMX und Takt auch überhaupt nicht zu den angeblichen vec32 ALUs (und auch im Zusammenhang mit der erkennbaren Unterteilung der Registerfiles in vier bzw. acht identische Teile nicht so recht, ich hatte meine Bedenken/Zweifel in der Richtung ja schon mal angedeutet). Die 160 Vergleichs- und logischen Operationen/SMX sehen da schon besser aus. Die genaue Erklärung dafür wäre aber auch interessant (nein, daß eine der 6 vec32-ALUs diese Befehle nicht kann, stimmt höchstwahrscheinlich nicht, ich vermute es sind nicht mal vec32-ALUs sondern drei vec16-ALUs pro Scheduler verbaut, also ein SMX ist von den ALUs her praktisch ein Bündel von vier GF104/114 Style SMs ;)).

Meine Vermutung ist, daß die normalen SP-Instruktionen 10 Takte Latenz haben, die Instruktionen mit 160er Durchsatz/Takt (gemittelt) allerdings 12 Takte (offiziell ist es für alles 11, aber ich halte bekanntermaßen von der Wirklichkeitstreue dieser Angaben nicht viel) und wegen des vereinfachten statischeren Schedulings (bzw. auch, weil Teile der Pipeline für viele Instruktionen geteilt werden [allerdings z.T. in unterschiedlichen Pipelinstufen, was eine Verzögerung aufeinanderfolgender Befehle unterschiedlichen Typs nötig macht!] und sich das statisch eben nicht anders berücksichtigen läßt) das Instruktions-Issue bei Integer-Instruktionen alle 10 Takte für 2 Takte angehalten wird, um Konflikte zu vermeiden (gibt halt kein Scoreboard mehr, was variable Latenzen und eventuelle Konflikte dynamisch handhaben kann, deswegen werden Latenzunterschiede auch bei aufeinanderfolgenden Befehlen gleichen Typs in Durchsatzunterschiede umgesetzt). Ist aber ohne gezielte Tests in die Richtung ziemlich spekulativ und somit (noch?) ohne schlagenden Beweis. Aber zumindest passen die 10/12 Takte schon mal zu den vec16-ALUs (Issue für einen Warp weiterhin über 2 Takte ;)).

Ailuros

2012-05-17, 12:35:17

http://www.anandtech.com/show/5840/gtc-2012-part-1-nvidia-announces-gk104-based-tesla-k10-gk110-based-tesla-k20/1

Ich muss mal wieder etwas verpassen, aber kann mir jemand mal erklaeren wieso jemand $2500 fuer eine TeslaK10 blechen sollte und nicht im Gegensatz mit einer $1000 GTX690 auskommen kann?

Was genau hat NV auf desktop GK104 kastriert?

Skysnake

2012-05-17, 13:10:25

ECC für den DRAM und Software. Das wars.

GPU-Direct und die Virtualisierungsfunktionen werden halt nur mit K10 gehen, ergo reine Software-Sache. Dafür zahlst du halt. Empfinde ich auch als etwas fragwürdig, ob so etwas auf Dauer gut geht.

Spasstiger

2012-05-17, 13:27:52

Tesla K10 ist dafür auch relativ günstig, nur halb so teuer wie Tesla C2070.

Gipsel

2012-05-17, 15:38:32

Weil K10 mit dem GK104 eben auch nur wenig Mehrwert bietet. Übertreibt es nV bei den Preisen, sehen sich die Leute entweder woanders um oder nehmen die Consumervarianten. ECC für den Speicher ist eher Placebo, wie ich schon mal schreib. Die internen SRAMs (Caches, Registerfiles, shared memory) haben nämlich keinen ECC-Schutz (im Gegenatz zu GF100/110/GK110 oder auch Tahiti). :rolleyes:

Skysnake

2012-05-17, 15:50:43

Ja, DAS ist mir auch aufgefallen, ich konnts aber nicht so wirklich glauben. :ugly:

Hat der Chip dann intern nicht wenigstens andere Mechanismen, um Fehler zumindest zu erkennen, und die Daten dann neu zu laden?

Wenn nicht, kannste den ECC-Support nämlich in die Tonne treten meiner Meinung nach...

Schade, dass du das genau so siehst wie ich. Ich hatte noch gehofft, ich würde das einfach falsch verstehen, und wollte nicht schon wieder als "Schwarzseher" daher kommen -.-

Coda

2012-05-17, 16:01:18

Naja, Bitflips im DRAM sind häufiger nehme ich mal an.

Skysnake

2012-05-17, 18:15:08

Klar sind die Häufiger, aber die Leute, die da wirklich richtig wert drauf legen, sind da teilweise geringfügig paranoid und sehen so etwas dann gar nicht gern, wobei ein reiner Performance-Nachteil Jacke wie Hose ist, so lange die Fehler erkannt und behoben werden können, egal wie, also auch durch Nachladen/Neu berechnen.

Wenn man aber nur sieht, ja da ist ein Fehler und dann alle Berechnungen für die Arsch sind, dann wirste das ECC-Feature nur schwerlich verkaufen können.

Gipsel

2012-05-17, 18:19:18

Naja, Bitflips im DRAM sind häufiger nehme ich mal an.
Das war früher sicher mal so, aber das hat sich wohl vor 10 Jahren oder so umgedreht und SRAM ist anfälliger als DRAM (das verhält sich bei beiden Speichertypen etwas unterschiedlich bei Verkleinerung der Strukturen). Das wird natürlich z.T. durch die deutlich unterschiedlichen Mengen wieder kompensiert.

Aber ansonsten kann man auch argumentieren, daß die wirklichen Bitflips durch ionisierende Strahlung eigentlich ziemlich selten sind im Vergleich zu Übertragungsfehlern und deswegen das EDC von GDDR5 eigentlich vollkommen ausreicht. Das kauft Dir aber auch kaum einer ab in den kritischen Märkten, in denen ECC verlangt wird.

Skysnake

2012-05-17, 18:27:08

Ja, ich hatte das mal getestet, und knapp 1 GB in die GPU geschrieben und dort dann mal für nen Tag oder so belassen. Ich hatte nicht einen Bitflip :D

Aber bei entsprechenden Mengen an Speicher haste statistisch gesehen einfach alle paar Minuten einen Bitflip, und da kannste so was einfach nicht gebrauchen.

Wie Gipsel schon sagt, in den entsprechenden Einsatzfeldern ist so was einfach ein K.O. Kriterium.

Gipsel

2012-05-17, 18:40:30

Ja, ich hatte das mal getestet, und knapp 1 GB in die GPU geschrieben und dort dann mal für nen Tag oder so belassen. Ich hatte nicht einen Bitflip :DBei einer Einzelkarte kannst Du mit einiger Wahrscheinlichkeit auch Dein ganzes Leben warten, bevor ein Bit kippt. :freak:

Edit:
Gibt inzwischen bestimmt schon was Neueres, aber egal. http://saahpc.ncsa.illinois.edu/09/papers/Shi_paper.pdf
We have implemented a comprehensive set of tests for checking the GPU memory for permanent hardware errors and are refining our methodology and software tools for monitoring the rate of transient soft errors. In two large NVIDIA GPU installations at NCSA [National Center for Supercomputing Applications] we have yet to see any soft errors, but 1.8% of tested GPUs turned out to have permanent memory errors. Our tests found the failures on systems that should not have been shipped to customers if the manufacturing tests were run properly. NVIDIA has since corrected the problem. But even with 1.8% of systems confirmed to have memory issues, the memory failure rate is below of what has been reported on non-GPU clusters, e.g., Li et al. [6] discovered hardware memory faults on 9 out of 212 (or 4.5%) Ask.com servers.
Sprich, die haben mit insgesamt 508 Tesla-Karten (je 4GB ohne ECC) keinen einzigen Bitflip gefunden. Der Testzeitraum betrug ziemlich genau 2 GPU-Jahre.

Edit2:
Ich sehe gerade, daß David Kanter das mit dem ECC genau so sieht (http://forum.beyond3d.com/showthread.php?p=1643485#post1643485):
Soft errors in on-chip SRAM is a far bigger problem than in DRAM. There is no point having ECC memory when your on-chip SRAMs do not have sufficient reliability. So while they might have ECC for DRAM, it's just for show.

Spasstiger

2012-09-14, 21:37:42

Ich glaube, ich weiß wie NV die Transistorzahlen berechnet.
A: Raster-Engine (GPC ohne SMX-Blöcke) - 240 Mio. Transistoren, 16 mm²
B: SMX-Block - 160 Mio. Transistoren, 12,923 mm²
C: ROP/SI/L2-Cache-Cluster - 280 Mio. Transistoren, 25,23 mm²
D: Display-Engines, PCIe, Rest - 180 Mio. Transistoren, 25,694 mm²

Die Probe aufs Exempel:

Transistorzahl
GK107: 1*A + 2*B + 2*C + 1*D = 480 Mio. + 320 Mio. + 560 Mio. + 180 Mio. = 1300 Mio.
GK106: 3*A + 5*B + 3*C + 1*D = 720 Mio. + 800 Mio. + 840 Mio. + 180 Mio. = 2540 Mio.
GK104: 4*A + 8*B + 4*C + 1*D = 960 Mio. + 1280 Mio. + 1120 Mio. + 180 Mio. = 3540 Mio.

Diefläche
GK107: 1*A + 2*B + 2*C + 1*D = 16 mm² + 25,846 mm² + 50,46 mm² + 25,694 mm² = 118,000 mm²
GK106: 3*A + 5*B + 3*C + 1*D = 48 mm² + 64,615 mm² + 75,69 mm² + 25,694 mm² = 213,999 mm²
GK104: 4*A + 8*B + 4*C + 1*D = 64 mm² + 103,384 mm² + 100,92 mm²+ 25,694 mm² = 293,998 mm²

Sind die Zahlen so plausibel? Die Ergebnisse der Rechnungen passen exakt auf die offiziellen Angaben seitens Nvidia.

/EDIT: Und die zugehörigen Dieflächen:
A => 16 mm²
B => 12,923 mm²
C => 25,23 mm²
D => 25,694 mm²
Hab sie jetzt auch oben hinzugefügt.
Damit komme ich für GK107 auf 118 mm² Fläche, für GK106 auf 214 mm² Fläche und für GK104 auf 294 mm² Fläche, genau wie von Nvidia angegeben.
Ein GPC mit zwei 2 SMX-Blöcken ist demnach rund 42 mm² groß. Klingt imo plausibel.

/EDIT2: Resultierende Packdichten:
A => 15 Mio. Transistoren pro mm²
B => 12,38 Mio. Transistoren pro mm²
C => 11,10 Mio. Transistoren pro mm²
D => 7,01 Mio. Transistoren pro mm²
Erwartungsgemäß ist die Packdichte bei den externen Schnittstellen (Display-Engines, PCIe, tendentiell auch Speicherinterface) am Geringsten.

Ein Kepler im Minimalausbau nach meiner Systematik mit 1 GPC, 1 SMX, 1 ROP-SI-L2-Cluster, 4 Display-Engines und PCIe 3.0 hätte demnach 860 Mio. Transistoren bei 80 mm² Diefläche.
Für GK110 hab ich spasseshalber auch mal gerechnet. Ein Gamer-GK110 wäre mit 5 GPCs (gemäß Dieshots-Spekulationen), 15 SMX und 6 ROP-SI-L2-Clustern insgesamt 5,46 Mrd. Transistoren schwer mit einer Diefläche von 451 mm². Für die erweiterten Compute-Fähigkeiten muss aber ein Aufschlag auf Transistorzahl und Fläche für die einzelnen Funktionsblöcke berücksichtigt werden, der größte davon sicherlich für die SMX-Blöcke. Bei 50% mehr Transistorzahl und Fläche pro SMX wären es schon 6,66 Mrd. Transistoren und 548 mm² Diefläche. Und wenn man noch weitere 35% pro GPC (ohne SMX) draufschlägt, kommt man auf 7,08 Mrd. Transistoren (spekuliert werden 7,1 Mrd.) und 576 mm². Das wäre die gleiche Diesize wie beim GT200 in 65 nm. Den doppelten so großen L2-Cache pro ROP-SI-Cluster hab ich dabei aber unterschlagen.

Und jetzt mal eine ganz verrückte Spinnerei:
GK"What Gamers Want": 6 GPCs (Gamer-Grade), 18 SMX (3456 CUDA-Cores, Gamer-Grade), 6 ROP/SI/L2 (384-Bit-SI) => 6,18 Mrd. Transistoren, 506 mm².
Das Teil dürfte eine GTX 690 abhängen. Lasst uns eine Petition bei NV starten. ;)

Gipsel

2012-09-14, 23:43:38

Ich glaube, ich weiß wie NV die Transistorzahlen berechnet.Na offentlich rechnet nV die nicht aus, sondern zählt. ;)
A: Raster-Engine (GPC ohne SMX-Blöcke) - 240 Mio. Transistoren, 16 mm²
B: SMX-Block - 160 Mio. Transistoren, 12,923 mm²
C: ROP/SI/L2-Cache-Cluster - 280 Mio. Transistoren, 25,23 mm²
D: Display-Engines, PCIe, Rest - 180 Mio. Transistoren, 25,694 mm²

Die Probe aufs Exempel:

Transistorzahl
GK107: 1*A + 2*B + 2*C + 1*D = 480 Mio. + 320 Mio. + 560 Mio. + 180 Mio. = 1300 Mio.
GK106: 3*A + 5*B + 3*C + 1*D = 720 Mio. + 800 Mio. + 840 Mio. + 180 Mio. = 2540 Mio.
GK104: 4*A + 8*B + 4*C + 1*D = 960 Mio. + 1280 Mio. + 1120 Mio. + 180 Mio. = 3540 Mio.Du hast also eine Lösung eines linearen Gleichungssystems aus 3 Gleichungen mit 4 Unbekannten gefunden. Dummerweise gibt es da ein paar mehr (d.h. ziemlich viele) Lösungen, selbst wenn man sich auf die natürlichen Zahlen beschränkt. Man kann einen Parameter frei wählen, die anderen ergeben sich dann aus dieser Wahl.

In dem Gleichungssystem ist nur A mit 240 Millionen eindeutig bestimmt.
Nehmen wir z.B. für B 200 Millionen an (statt wie bei Dir 160 Millionen), ergeben sich C=160 Millionen (statt 280) und D=340 Millionen (statt 180). Diese Zahlen lösen das Gleichungssystem genauso (für die Flächen gilt das Ganze analog). Man kann sich also praktisch beliebige Zahlen für die einzelnen Teile herzaubern.

Spasstiger

2012-09-14, 23:58:33

42 mm² (1*A + 2*B) für einen GK104-GPC mit 2xSMX sind ja imo durchaus plausibel, wenn man sich den GK104-Dieshot anschaut. Aber du hast natürlich recht, dass es unendlich viele Lösungen gibt. Manche Lösungen sind plausibel, andere nicht. Z.B. werden die nicht-skalierenden Teile wie die Display-Engines und PCIe wohl kaum 340 Mio. Transistoren benötigen. Man muss auch schauen, dass die Packdichten für die einzelnen Funktionsgruppen plausibel sind (externe Schnittstellen haben geringere Packdichten als Arithmetik, interne Verbindungen oder Caches) was nach meiner Rechnung ja der Fall ist.
Vielleicht kommt ja noch eine vierte Gamer-Kepler-Variante, damit das Gleichungssystem eindeutig lösbar wird. ;)

Na offentlich rechnet nV die nicht aus, sondern zählt. ;)
Schon klar, hatte den Satz ursprünglich auch mit einer Ironie-Kennzeichnung bedacht. ;)

/EDIT: Ich mache mir am WE noch ein paar ausführlichere Gedanken darüber, in welchem Bereich plausible Werte rauskommen, speziell auch, was die Packdichten angeht. Jetzt ist es etwas spät dafür.

Spasstiger

2012-09-15, 11:40:10

/EDIT: Ich mache mir am WE noch ein paar ausführlichere Gedanken darüber, in welchem Bereich plausible Werte rauskommen, speziell auch, was die Packdichten angeht. Jetzt ist es etwas spät dafür.
Auf eine Neues. Die Gleichungssysteme können soweit vereinfacht werden:

Transistorzahl
A = 240 Mio.
B = ?
C = 760 Mio. - 3*B
D = 4*B - 460 Mio.
=> 115 Mio. < B < 253,33 Mio
=> 0 < C < 415 Mio.
=> 0 < D < 533,33 Mio.

Fläche
A = 16 mm²
B = ?
C = 64 mm² - 3*B
D = 4*B - 26 mm²
=> 6,5 mm² < B < 21,33 mm²
=> 0 < C < 44,5 mm²
=> 0 < D < 59,33 mm²

Man kann jetzt für diese Gültigkeitsbereiche die Packdichten in Abhängigkeit der Dimensionierung von B plotten:

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

Ich habe den Bereich herausgestellt, in dem die Verhältnisse der Packdichten zueinander meiner Meinung nach plausibel wären:

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

Mit den obigen Formeln kann man aus der Dimensionierung von B die Dimensionierung von C und D berechnen.
Für die Bedingungen 100 Mio. < Transistorzahl D < 300 Mio. und Transistorzahl B < Transistorzahl C wird der Plausibilitätsbereich folgendermaßen weiter eingeschränkt:
http://www.abload.de/img/packdichten_kepler_gkrdliw.png

Nochmal zur Erinnerung, wofür A, B, C und D stehen:
A: GPCs ohne SMX-Blöcke (Raster-Engines)
B: SMX-Block
C: ROP/SI/L2-Cache-Cluster
D: Nicht-skalierender Rest (Display-Engines, PCIe)

Aus dem Dieshot des GK104 kann man für einen SMX ja ziemlich genau 15 mm² abschätzen. Damit wäre eine Transistorzahl zwischen 170 Mio. und 190 Mio. pro SMX plausibel. Unter der Annahme von 180 Mio. hätte man folgende Werte für A, B, C und D:
A => 240 Mio. Transistoren, 16 mm²
B => 180 Mio. Transistoren, 15 mm²
C => 220 Mio. Transistoren, 19 mm²
D => 260 Mio. Transistoren, 34 mm²

Gipsel

2012-09-16, 13:05:46

:eek:
Da hat sich jemand aber Mühe gegeben (ich habe über solche Plots nachgedacht, das aber aus Gründen des Aufwand/Nutzen-Verhältnis verworfen).
Da traue ich mich fast gar nicht zu erwähnen, daß es auch Anteile bei GPUs gibt, die nicht linear skalieren, sondern eher mit dem Produkt aus Anzahl Setup/Raster * SMX oder mit SMX * ROP-Partitionen. ;)

Coda

2012-09-16, 15:24:38

Jup, die Crossbars sind m*n von der Komplexität.

Gipsel

2013-10-30, 00:49:22

*mal den Thread wieder rauskram*

Kepler scheint doch arge Probleme mit Registerbank-Konflikten zu haben (http://forum.beyond3d.com/showthread.php?p=1799683#post1799683). Sieht so aus, als wenn das Registerfile aus lediglich 4 Bänken besteht und pro Schedulingtakt (zwei Kerntake) die bis zu zwei Instruktionen nur jeweils einen einzigen Operanden pro Bank lesen können, was es praktisch sehr schwer bis unmöglich macht, die Peakdurchsätze von Kepler zu erreichen.
Registerportbeschränkungen waren ja auch bei AMDs VLIW-Architekturen möglich (insbesondere bei VLIW5), aber selbst da konnte man immerhin noch 3 Operanden pro Bank laden (also bis zu 12 insgesamt für die bis zu 5 Instruktionsslots), wobei das Resultforwarding zusätzlich 5 Operanden (Ergebnisse der vorherigen Instruktion[en]) liefern konnte und Konstanten bzw. Literals auch noch oben drauf kamen. Das sieht bei Kepler auf den ersten Blick von den Beschränkungen her übler aus.