Hat Fermi ein "Wunder-VRAM-Management"?

[Fetter Fettsack]

Der Herr Kasmopaya behauptet in diesem Thread (http://www.computerbase.de/forum/showthread.php?t=636865&page=10), dass Fermi ein "Wunder-VRAM-Management" habe.

Er behauptet felsenfest, dass Fermi aufgrund seiner Out-Of-Order-Fähigkeiten und seiner L1 und L2 Caches kein Problem mit VRAM-Überlauf habe und weiterhin ohne merklichen fps-Verlust ein Spielvergnügen ermöglicht.

Teile seiner Begründungen:

Zitat von Kasmopaya

Die Caches werden dazu benutzt damit die GPU überhaupt die out of Order Berechnung stemmen kann, das muss ja irgend wo gespeichert werden welcher Teil grad wo rumliegt und welcher Teil auf welchen wartet und welcher Teil als nächstes dran kommt, ohne das die GPU dafür anhalten muss. Also was ich damit sagen will, die neuen Caches ermöglichen erst eine so komplexe(hunderttausend Threads) out of order Funktion.

Out of order = GPU kann weiterrechnen ohne auf die Daten vom System Ram warten zu müssen -> massiver Speedschub wenn der Vram überläuft, im Vergleich zu Karten die das nicht können.
Die neuen GPU Caches von Fermi = Ermöglichung der out of order Befehle

Die Sache ging etwa ab hier los:
http://www.computerbase.de/forum/showpost.php?p=9014872&postcount=750

Ich halte diese These für nicht korrekt, weil man ungeachtet dessen, dass man aufgrund der Out-Of-Order-Fähigkeit an anderen Berechnungen weitermachen kann, immernoch auf die Daten aus dem System-RAM warten muss, um ein Bild vollständig zu berechnen. Ergo sollte der Zeitverlust nihct sonderlich geringer werden als bei anderen GPUs (Cypress usw.).

Jedoch wäre es mir allerliebst, wenn sich hier jemand mit tiefergehenden Kenntnissen zu dieser Meinungsstreitigkeit äußert. Danke sehr :)

[SamLombardo]

aber irgendwas muss dran sein. Das hab ich mich auch schon gefragt. zB hat eine GTX 465 mit 1GB Ram in bestimmten Metro 2033 Settings (1920x1200 inkl AA) die fast vierfache Anzahl an FPS wie die HD5870 mit ebenfalls 1gb (zwar auf niedrigem niveau, so 14,.. zu 4 wars glaub ich aber dennoch.). Bei der 5870 geht eindeutig der Vram aus, bei der 465 ist der drop bei weitem nicht so heftig.

*frag jetzt bitte nicht nach links, es waren benches der PC Games in ihrem GTX465 test.

Wäre dennoch interessant was der Grund sein könnte.

[Raff]

Doppelte Direct-Memory-Access-Engine (DMA). Hat Cayman nun auch (bi-direktional). Das ist es IMO, was den Unterschied macht. GT200 ist bei vollem Speicher noch gnadenlos abgesoffen, bei Furby haben sie das Problen richtig gefixt.

MfG,
Raff

[deekey777]

Sry, aber WTF?

Die Caches werden dazu benutzt damit die GPU überhaupt die out of Order Berechnung stemmen kann, das muss ja irgend wo gespeichert werden welcher Teil grad wo rumliegt und welcher Teil auf welchen wartet und welcher Teil als nächstes dran kommt, ohne das die GPU dafür anhalten muss. Also was ich damit sagen will, die neuen Caches ermöglichen erst eine so komplexe(hunderttausend Threads) out of order Funktion.

Die GPU ist doch keine OoO-Architektur, oder? Wenn ein Warp nicht berechnet werden kann, weil er auf Daten warten muss, wird er zur Seite geschoben und die Recheneinheiten bearbeiten einen anderen Thread. Es sind zwar keine 100.000e Threads, aber bis zu 30.000.

[Bucklew]

Doppelte Direct-Memory-Access-Engine (DMA).
Haben (so ich das jetzt richtig im Kopf habe) nur Quadro/Tesla. Bei GeForce ist die zweite DMA-Engine abgeschaltet.

[Exxtreme]

Haben (so ich das jetzt richtig im Kopf habe) nur Quadro/Tesla. Bei GeForce ist die zweite DMA-Engine abgeschaltet.
Wieso schaltet man sowas absichtlich ab? Damit die Geforce künstlich langsamer wird? :confused:

[y33H@]

Die doppelte DMA sollte vor allem bei "Kleinkram" etwas bringen, also eher GGPU statt fette Texturen.

[Rente]

Wieso schaltet man sowas absichtlich ab? Damit die Geforce künstlich langsamer wird? :confused:
Verkaufsargument für die Quadros, so einfach ist das.

[Exxtreme]

Verkaufsargument für die Quadros, so einfach ist das.
Und ein Verkaufsargument für Radeons.

[Dural]

wieso? die GeForce sind ja auch so ganz offensichtlich überlegen...

ich finde es eh sehr faszinierend wie NV beim Fermi in dieser Hinsicht gezaubert hat, das ding ist so extrem effizient und benötig kaum grosse Bandbreiten um richtig viel Leistung auf den Bildschirm zu zaubern, da bin ich immer wieder erstaunt! kein Vergleich mehr zu den bekannten Schwachstellen des GT200!

NV hat in dieser hinsicht nicht nur aufgeholt, sondern auch deutlich überholt.

[Gipsel]

Sry, aber WTF?

Die GPU ist doch keine OoO-Architektur, oder? Wenn ein Warp nicht berechnet werden kann, weil er auf Daten warten muss, wird er zur Seite geschoben und die Recheneinheiten bearbeiten einen anderen Thread. Es sind zwar keine 100.000e Threads, aber bis zu 30.000.
Da hast Du vollkommen recht. Das können auch alle GPUs, egal ob von nv oder AMD. Und das auch schon sehr lange. Der Kram mit OoO, den er da schreibt, ist gelinde gesagt Blödsinn.

Eine GPU (Hersteller wieder egal) versucht immer so viele Threads zu starten, wie nur irgendwie möglich. Die Anzahl wird meistens durch die Anzahl der Register bestimmt (alle Threads müssen sich die Register teilen => werden weniger Register benutzt, können mehr Threads gestartet werden), bei Shader-Kerneln mit sehr geringer Registernutzung limitieren die Scheduler (die können nur eine bestimmte Anzahl von Warps/Wavefronts verwalten). Die genauen Zahlen hängen jeweils von der Anzahl der einzelnen Einheiten ab, aber einige zehntausend Threads für die Topmodelle von nv/AMD kommen schon hin.

Trifft eine Wavefront/Warp jetzt auf eine abhängige Instruktion (bei AMD kann dies prinzipiell nur ein Speicherzugriff sein, bei nv zusätzlich auch normale Instruktionsabhängigkeiten), wird genau wie deekey geschrieben hat einfach zu einem anderen Warp/Wavefront geswitched und daran weiter gerechnet. Da alle aktiven Daten aller Warps vollständig in den Registerfiles liegen, geht das auch recht schnell. Das ist ja der Grund, warum GF100/110 2 MB an Registern besitzt, Cypress 5 MB und Cayman gar 6 MB (die AMDs nutzen die Größe tendenziell etwas ineffizienter, da die Registerfiles im Prinzip 4 Bänke [xyzw] besitzen, die zusammen 128Bit- statt 32Bit-Einträge wie bei nv bilden, aber prinzipiell paßt das ganz gut zur höheren Shader-Rohleistung der AMDs). Dagegen sind die Caches sogar bei GF100/110 relativ klein (256kB L1 [Grafikmodus], 768kB L2), können also außer als Puffer bei gelegentlichen(!) Registerspills nicht zur Vergrößerung des aktiven Workingsets beitragen. Dies ist deutlich unterschiedlich zu (x86-)CPUs, wo die Daten sehr regelmäßig im L1 liegen und man praktisch daraus arbeitet. Dafür würde die L1-Bandbreite bei GPUs überhaupt nicht ausreichend dimensioniert sein (bei Fermi nur 64 Byte pro Takt bei 32 oder gar 48 ALUs).

Abschließend noch eine Anmerkung zur "out-of-order execution of threadblocks", die Fermi ja unterstützt. Das ist insofern kein großes Ding, als daß keine API irgendeine Ordnung zwischen Threadblocks (OpenCL: work group) voraussetzt, solange man nicht explizit irgendwelche Synchronisationen zwischen denen einbaut. Soweit ich mich erinnere, sagen so ziemlich alle Manuals, daß man gar keine Ordnung dazwischen erwarten kann, da ja der nächste Threadblock auf einem anderen SM/SIMD-Engine gescheduled wird. Die OoO Ausführung und Completion mehrerer Threadblocks (local work groups) ist sozusagen der Normalzustand und jetzt kein spezielles Feature. OoO (asynchrone) Ausführung mehrerer Kernel wäre es (Cayman kann das) ;)

Edit:
Als kleine Ergänzung sei vielleicht noch angemerkt, daß auch ältere GPUs schon mehrere Shader-Kernel gleichzeitig ausführen können (aber keine zwei gleichen Types!). So laufen die verschiedenen Stages der DX-Pipeline (und damit auch verschiedene Shader, z.B. Vertex- und Pixelshader) schon parallel. Hier besteht auch immer mal wieder eine Möglichkeit durch Treiberarbeit die Performance zu verbessern, denn das Load-Balancing zwischen den Stages wird maßgeblich vom Treiber mitbestimmt. Die oben angesprochene Neuerung sieht also praktisch so aus, daß jede Anwendung eine eigene Queue bekommt und die Kernels von verschiedenen Anwendungen gleichzeitig laufen und sich gegenseitig überholen können, dabei aber keine gegenseitig Beeinflussung (außer Performance natürlich) möglich ist, praktisch eine Virtualisierung der GPU-Resourcen.

[deekey777]

Wie war das eigentlich mit den Phasen der Prä-R520-Radeons?

[Fetter Fettsack]

Um da nochmals nachzuhaken: Wenn der VRAM voll ist, dann geht das ganz normal über DMA auf den System RAM und fertig?
Oder bringt auch hier eine "bessere" VRAM-Verwaltung etwas?

[Gipsel]

Wie war das eigentlich mit den Phasen der Prä-R520-Radeons?
Nun, vor R600 gab es ja noch keine unified shader (außer beim Xenos). Da liefen die Vertexshader auf den Vertexshadern und die Pixelshader ebenfalls auf ihren eigenen Einheiten. Oder was war die Frage?

[Gipsel]

Um da nochmals nachzuhaken: Wenn der VRAM voll ist, dann geht das ganz normal über DMA auf den System RAM und fertig?
Oder bringt auch hier eine "bessere" VRAM-Verwaltung etwas?
Nun, irgendwann muß der Treiber entscheiden, ob nur der System-RAM gemapped wird und die Shader direkt darauf zugreifen (geht nur für kleinere Datenmengen passabel) oder ob in den VRAM kopiert wird. Wenn Letzteres gemacht wird, muß man sich auch entscheiden, was dafür rausgeschmissen wird. Das sollte natürlich nichts sein, was man direkt danach gleich wieder benötigt. Insofern existiert da schon ein wenig Optimierungspotential. Sagen wir mal so: man kann es zumindest auch sehr schlecht machen ;)

[Coda]

Danke Gipsel, du hast mir Schreibarbeit erspart :)

Wie war das eigentlich mit den Phasen der Prä-R520-Radeons?
Das betrifft nicht die Threads sondern wie ALUs und TMUs synchronisiert sind. Heute läuft das automatisch, bei R3xx-R5xx wurde explizit das Programm in "Teile" zerlegt die parallel liefen. Das waren die Phasen.

Also auch R300 hatte natürlich pro Pixel irgend eine Art von "Thread" in den Pixelshadern, auch wenn das sicher noch viel einfacher war.

[Fetter Fettsack]

Danke schön für die Erklärung, Gispel. :)

[SamLombardo]

@gispel (oder auch coda oder alle anderen:))
wenn das so ist wie beschrieben, wie kommt es dann, dass bei Cypress der Vram offenbar entweder schneller volläuft als bei Fermi (glaub ich ehr nicht) oder Fermi damit deutlich besser umgehen kann (siehe mein erstes Posting in diesem Thread zu den Frameeinbrüchen bei metro)

Thx für Aufklärung:wink:

Sam

[Coda]

Wenn überhaupt dann liegt es an den DMA-Engines.

[Gipsel]

Wenn überhaupt dann liegt es an den DMA-Engines.
Oder Metro ist ein singuläres Beispiel, was man so nicht verallgemeinern kann. Gab es da nicht auch immer heftige Einbrüche mit Tess oder PhysX?

[deekey777]

Oder Metro ist ein singuläres Beispiel, was man so nicht verallgemeinern kann. Gab es da nicht auch immer heftige Einbrüche mit Tess oder PhysX?
http://www.hardware.fr/articles/813-21/dossier-amd-radeon-hd-6970-6950-seules-crossfire-x.html
Also die Tessellation in Metro2033 ist genau so ein Witz wie in CoP.
Metro2033 scheint den Radeons eh nicht zu schmecken und der DoF-Filter macht den Rest.

[y33H@]

Ohne DX11-DoF liegt Metro 2033 den Caymans exzellent.

[Gipsel]

http://www.hardware.fr/articles/813-21/dossier-amd-radeon-hd-6970-6950-seules-crossfire-x.html
Also die Tessellation in Metro2033 ist genau so ein Witz wie in CoP.
Metro2033 scheint den Radeons eh nicht zu schmecken und der DoF-Filter macht den Rest.
Das sieht ja wirklich eigenartig aus. Die 1 GB-Karten brechen in 2560x1600 4AA überhaupt nicht ein, aber bei 1920x1200 schmieren die bei Aktivierung von DOF total ab. Das sieht für mich nicht wirklich nach einer VRAM-Begrenzung aus. Wieso sollte DOF so viel mehr fressen als die deutlich höhere Auflösung? Wieso sollte DOF überhaupt mehr VRAM fressen? Entfernungsabhängige Unschärfe bekommt man doch im Prinzip mit einem PP-Filter hin, das sollte nur hauptsächlich Bandbreite und ein wenig Shaderleistung kosten. Oder machen die da irgendwas Wildes wegen dem deferred Rendering von Metro?

[y33H@]

VRAM kostet dieses DoF nicht wirklich, da bremst etwas anderes.

[Gipsel]

Ohne DX11-DoF liegt Metro 2033 den Caymans exzellent.Nach dem von Deekey verlinkten Test verlieren die mit DOF auch nicht deutlich mehr Leistung als die nvidias. Und die 2GB HD5870er verhalten sich auch nicht anders.
Die Frage, die sich mir stellt ist eher, warum brechen die 1GB-Varianten mit DOF so ein? Wenn der VRAM-Bedarf sich mit DOF verdoppeln sollte, wäre das in meinen Augen schon ein wenig eigenartig.

[Gipsel]

VRAM kostet dieses DoF nicht wirklich, da bremst etwas anderes.
Also eher Treiber-Bug oder sowas?

[Bucklew]

Wieso schaltet man sowas absichtlich ab? Damit die Geforce künstlich langsamer wird? :confused:
Braucht die GeForce denn ne zweite DMA-Engine? Sinnvoll ist es eben bei GPGPU, weil man dann parallel Daten auf die Karte schieben und runterholen kann. Bei GeForce wohl eher nicht so wichtig.

[airbag]

VRAM kostet dieses DoF nicht wirklich, da bremst etwas anderes.
HisN hat mal nachgemesessen. Scheint mit Advanced DOF 300 mehr zu sein.
http://www.computerbase.de/forum/showpost.php?p=9033957&postcount=821

[y33H@]

:eek:

[Gipsel]

HisN hat mal nachgemesessen. Scheint mit Advanced DOF 300 mehr zu sein.
http://www.computerbase.de/forum/showpost.php?p=9033957&postcount=821
:eek:
:eek: Genau!

Da stellt sich wirklich die Frage: Was zur Hölle machen die da um dafür 300MB VRAM zu verbraten?!? Immerhin sollte das im Screenspace ablaufen und bei gerade mal 2,3 Millionen Pixeln sind mir 300MB extra vollkommen unklar, selbst wenn die dafür noch einen extra Buffer anlegen sollten (was unnötig sein sollte, da man das eigentlich beim Final Compositing miterledigen kann).

Edit:
Aber um mal auf die Frage des VRAM-Managements zurückzukommen, offensichtlich werden von den ~1,3GB belegtem Speicher nicht alles in jedem Frame benutzt. Offensichtlich schmeißt der Radeon-Treiber bloß immer genau das Falsche raus. Zumindest bei Aktivierung von DOF, ohne DOF aber mit weiterer Erhöhung der Auflösung auf 2560x1600 (womit man auch ja wohl auch über die 1GB-Grenze kommt), scheint das Management ja offensichtlich zu klappen. Vielleicht sollte man mal der Treiberabteilung einen Tipp geben?

Edit2:
Um noch mal ein Gegenbeispiel mit Metro und DOF anzubringen, schaut Euch mal die Benchmarks bei HWLuxx (http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/16815-test-amd-radeon-hd-6970-und-6950.html?start=26) an (alles high und mit aktiviertem DOF). Da sieht man keinen Unterschied zwischen nv und AMD-Karten mit 1GB. Bis zu 1920x1200 liegen die alle noch halbwegs gut, erst bei 2560x1600 brechen die deutlich ein (dann aber alle 1 GB-Karten). Das scheint sich also höchstens zuweilen ein wenig erratisch zu verhalten, einen Trend oder gar Beweis für ein besseres Speichermanagement bei nv kann man daraus aber keinesfalls ableiten.

http://www.hardwareluxx.de/images/stories/galleries/reviews/Radeon6900/bench/metro2.jpghttp://www.hardwareluxx.de/images/stories/galleries/reviews/Radeon6900/bench/metro3.jpg

[Liszca]

für mich erklärt sich der einbruch von 1920x1200 zu 2560x1600 durch eine fast verdoppelte anzahl der pixel. FSAA und AF kommen ja auch noch dazu.

----------------------
1920x1200 = ~2,3 MP
2560x1600 = ~4 MP
----------------------

[Gipsel]

für mich erklärt sich der einbruch von 1920x1200 zu 2560x1600 durch eine fast verdoppelte anzahl der pixel. FSAA und AF kommen ja auch noch dazu.

----------------------
1920x1200 = ~2,3 MP
2560x1600 = ~4 MP
----------------------
Ja na klar, das ist aber nicht der Punkt in diesem Thread ;)