Archiv verlassen und diese Seite im Standarddesign anzeigen : GPU-Limitierung durch ROPs
robbitop
2006-11-03, 09:50:11
Aus gegebenem Anlass möchte ich dieses Thema mit euch erörtern.
An vielen Stellen muss ich lesen, dass die ROPs die Leistung einer GPU in aktuellen Spielen limitieren kann.
ROPs sind zuständig für:
- Schreiben und Lesen von Farb- und Tiefernwerten
- Stenciloperationen
- Alphablending
All dies erledigen sie in einem Takt. Die NV/ATI Karten haben mittlerweile Doppel ROPs, welche bei 2xMSAA immernoch keine Beeinträchtigung in ihrer Arbeitsleistung haben. Um einen Pixel in aktuellen Spielen berechnen zu können sind viele Takte an Filterung und Pixelshading nötig. Da sollte der eine Takt der ROPs lächerlich sein.
Gegen die These der Limitierung spricht eindeutig der NV43, welcher auch bei Doom 3 mit 4xMSAA (einem Spiel mit hoher Stencil-last) gegenüber einem rohleistungsgleichen NV40 (6800 vanilla...beeinflußt durch die Taktrate) nicht das Nachsehen hat. Und das Obwohl der NV40 über 4x soviele ROPs verfügt.
Hier limitiert offensichtlich noch die Bandbreite.
ab zwei texturen können die rops nicht mehr limitieren, bei 4xaa
Jedoch für diese These der Limitierung spricht der R580. Hier ist das Verhältnis Bandbreite/Rohleistung deutlich mehr zugunsten der Bandbreite.
In FEAR (sehr stencillastig) erleidtet sie unter 2048x1536 von NoAA auf 4xMSAA einen Einbruch um 48,5%. Die GDDR4 Version dieser Karte (X1950XT) mit gleichem Chiptakt jedoch um fast 30% erhöter Bandbreite erleidet exakt diegleichen 48,5% in diesem Setting. Die erhöte Bandbreite hilft dem R580 hier nicht aus der Patsche (Link (http://www.anandtech.com/video/showdoc.aspx?i=2821&p=9)).
In anderen Engines hingegen (auch Doom3) profitiert die X1950XT von ihrer erhöten Bandbreite.
Limitieren hier tatsächlich die ROPs? Oder ist es etwas ganz anderes?
Sind es irgendwelche Caches oder der Hirarchial-Z Buffer, der an seinem Limit ist? Könnte es der Speichercontroller sein, der ja vom Treiber konfiguriert wird und vieleicht noch nicht vernünftig auf GDDR4 Latenzen eingestellt ist?
Oder möglicherweise ein Treiberbug? Das erinnert mich an den G70 der schon bei 2xMSAA bei FEAR sehr stark eingebrochen ist. G71 mit aktuellen Treibern jedoch nichtmehr.
Anscheinend ist es nur bei FEAR so, dass die X1950XT nicht von der deutlich höheren Bandbreite limitiert (also der MSAA Hit geringer ist).
Kann bei ATI ein Treiber-Problem sein.
][immy
2006-11-03, 10:34:21
vielleicht liegt es einfach an fear selbst, es ist ja ansonsten auch eher nicht der optik-brüller aber läuft trotzdem lahm
bei Stencil-Berechnungen waren ATi-Chips aber immer schon irgendwie langsamer. Ich erinnere mich da an meine Radeon 9500 Pro und Jedi Outcast. Die schatten (waren ja pure stencil-berechnungen) haben massig an der Performance gesaugt. eine nvidia Karte schien damit hingegen überhaupt keine Probleme zu haben.
war das Feature Ultra-shadow bei nvidia nicht für massive Stencil-Berechnungen verantwortlich
Gouvernator
2006-11-03, 11:07:43
Liegt wohl an FEAR selbst. Wenn mann auf low stellt dann gibts zwar mehr FPS aber auch nicht viel mehr (2048x1536+AA)
@robbi
IMO machst du hier einen Denkfehler. Und zwar folgenden: Die Pixelberechnung bis zu den ROPs ist fix - die dauert eine gewisse Zeit X, unabhängig von der Anzahl der ROPs. Soweit d'accor?
Nun haben wir ein Design, welches diese ankommenden Pixel in einem gewissen Qualitätsgrad in einem Takt durchschieben kann. Fein. Dann haben wir ein anderes Design, welches das nicht kann, sondern doppelt solange benötigt. Dann haben wir hier einen Flaschenhals. Richtig?
micki
2006-11-03, 12:20:48
das schlimmste zZ sind texturzugriffe, wenn es dependant reads sind, haben die eine ziemlich ueble latenz, da hilft pixelshaderleistung und rops nicht viel, man wartet einfach erstmal auf die texturdaten. wenn man das aendern will, muss die latenz vom ram besser sein (das muss nicht von takt oder bandbreite abhaengen).
das schlimmste zZ sind texturzugriffe, wenn es dependant reads sind, haben die eine ziemlich ueble latenz, da hilft pixelshaderleistung und rops nicht viel, man wartet einfach erstmal auf die texturdaten. wenn man das aendern will, muss die latenz vom ram besser sein (das muss nicht von takt oder bandbreite abhaengen).
Oder man hat wie ATI genug in Logik investiert um zuerst an etwas anderem weiterzurechnen.
Dass jetzt eine R580 schon durch die ROPs limitiert wird, halte ich für unwahrscheinlich. Ich denke mal eher, da wurde irgendwo an den Registern gespart.
Bei einer USA kann man dagegen u.U. mehr ROPs gebrauchen, da bei PS-losen Passes (oder schwachen wie zB. der erste Depth-Pass bei Crysis der nur den Z-Wert in einen Floatbuffer schreibt) die ganze Rechenleistung in die Geometrieverarbeitung gesteckt wird und sich das Zeugs dann vor den ROPs ansammelt kann.
das schlimmste zZ sind texturzugriffe, wenn es dependant reads sind, haben die eine ziemlich ueble latenz, ... die natürlich in der Pipe versteckt wird.
Dass jetzt eine R580 schon durch die ROPs limitiert wird, halte ich für unwahrscheinlich. Ich denke mal eher, da wurde irgendwo an den Registern gespart.Was für Register denn?
robbitop
2006-11-03, 12:52:49
@robbi
IMO machst du hier einen Denkfehler. Und zwar folgenden: Die Pixelberechnung bis zu den ROPs ist fix - die dauert eine gewisse Zeit X, unabhängig von der Anzahl der ROPs. Soweit d'accor?
Nun haben wir ein Design, welches diese ankommenden Pixel in einem gewissen Qualitätsgrad in einem Takt durchschieben kann. Fein. Dann haben wir ein anderes Design, welches das nicht kann, sondern doppelt solange benötigt. Dann haben wir hier einen Flaschenhals. Richtig?
Quasar (vergiss das "Q" nicht ;-), kannst du das ein wenig tiefer erläutern?
Moralelastix
2006-11-03, 12:59:14
Wenns bei NV limitieren würde hätten sie das doch beim G80 ändern müssen?
G80 boasts 24 raster operation units
http://uk.theinquirer.net/?article=35495
robbitop
2006-11-03, 13:00:36
Der G80 hat in diesem Bereich eine verdammt starke Änderung bekommen. (Laut dem INQ Bericht)
Moralelastix
2006-11-03, 13:06:44
Also eine Art Effizienzsteigerung der 24 ROP gegenüber dem G71?
mapel110
2006-11-03, 13:08:55
Also eine Art Effizienzsteigerung der 24 ROP gegenüber dem G71?
G71 hat doch nur 16 ROPs iirc?!
Quasar (vergiss das "Q" nicht ;-), kannst du das ein wenig tiefer erläutern?
In Kurz: Was ich meine ist, wir müssen untersuchen, ob wir wirklich beim Arbeitstempo an den ROPs hängen oder an etwas anderem. Obwohl Doom3 und ähnliche massiv auf ROP-intensive (aber auch CPU-intensive) Stencilschatten setzen, scheint es hier nicht der Fall zu sein, dass die ROPs der limitierende Faktor sind. In Spielen, würde ich mal sagen, gibt es kaum eine Situation, wo wirklich die ROPs limitieren.
In synthetischen Tests dagegen schon.
Q (zufrieden?)
G71 hat doch nur 16 ROPs iirc?!
Da geht es wieder los. Die Leute zählen "Pipelines", "ALUs" und "ROPs" ohne zu fragen, was so eine Unit denn pro Takt alles kann. Dann kann man auch gleich "4x" Antialiasing oder "16x" AF vergleichen.
Moralelastix
2006-11-03, 13:10:18
Also ich hab ja auch keine Ahnung, aber?
http://www.3dcenter.de/artikel/2006/03-10_a.php
robbitop
2006-11-03, 13:10:39
Also eine Art Effizienzsteigerung der 24 ROP gegenüber dem G71?
If you use only Z-processing, you can expect a massive 192 pixels if one sample per pixel is used. If 4x FSAA is being used, then this number drops to 48 pixels per clock.
G71 konnte entweder 32 Z Werte schreiben oder 16 Color + Z (bis 2xMSAA). Danach halbierte sich das. Die ROPs im G80 sind doch schon ein wenig stärker. ;)
robbitop
2006-11-03, 13:16:47
In Kurz: Was ich meine ist, wir müssen untersuchen, ob wir wirklich beim Arbeitstempo an den ROPs hängen oder an etwas anderem. Obwohl Doom3 und ähnliche massiv auf ROP-intensive (aber auch CPU-intensive) Stencilschatten setzen, scheint es hier nicht der Fall zu sein, dass die ROPs der limitierende Faktor sind. In Spielen, würde ich mal sagen, gibt es kaum eine Situation, wo wirklich die ROPs limitieren.
In synthetischen Tests dagegen schon.
Genau da stimme ich dir zu. :up:
Q (zufrieden?)
Ich finde das nicht witzig.
M.E. müßte gegen Leute hart vorgegangen werden, die hier registriert sind und trotzdem absichtlich anonym (was bei dir ja nicht der Fall ist) posten. Gast auf Arbeit ist ok, solange man sich zu erkennen gibt.
Alles andere führt die Moderation und die Ordnung im Forum ad absurdum.
Banshee18
2006-11-03, 18:57:34
Liegt wohl an FEAR selbst. Wenn mann auf low stellt dann gibts zwar mehr FPS aber auch nicht viel mehr (2048x1536+AA)
Du sprichst aber nicht von den Schatten, oder? Es bringt bei mir nämlich extrem viel, wenn ich die Qualität reduziere oder sie sogar komplett ausschalte.
Ich als Laie erlaube mir zwar normalerweise kein Urteil über die Qualität einer Engine, aber kann es sein, dass Fear wirklich schlecht programmiert ist? Doom3 z.B. läuft deutlich besser, und da wirf nahezu alles Echtzeitschatten, bei Fear nicht.
Gibt es eventuell eine Möglichkeit, ROPs zu deaktivieren? Mit dem Rivatuner kann man zumindest bei einigen Karten iirc ganze Quads deaktivieren.
Doom3 z.B. läuft deutlich besser, und da wirf nahezu alles Echtzeitschatten, bei Fear nicht.
fear verwendet deutlich mehr lichtquellen als doom3 und in der höchsten detailstufe wirft auch alles einen schatten (alpha-kanten ausgenommen, was ja mit stencil-shadows auch nicht möglich ist)
(alpha-kanten ausgenommen, was ja mit stencil-shadows auch nicht möglich ist)
Das müsste eigentlich möglich sein, bei Neverwinter Nights z.B. funktionierte das auch schon.
Das müsste eigentlich möglich sein, bei Neverwinter Nights z.B. funktionierte das auch schon.
stencil-shadows werden über die geometrie erzeugt, da ist nicht bekannt welche teile davon evtl. durchsichtig sein können.
ich weiß zwar nicht welche technik neverwinter nights für die schatten verwendet, aber stencil-shadows von AT-kanten sind prinzipbedingt unmöglich.
bei fear wird das manchmal so gelöst dass diverse durch AT-texturen dargestellte gitter garnicht in die schattenberechnung mit einfließen, bzw. manchmal einfach das komplette polygon einen schatten wirft (ohne löcher)
stencil-shadows werden über die geometrie erzeugt, da ist nicht bekannt welche teile davon evtl. durchsichtig sein können.
ich weiß zwar nicht welche technik neverwinter nights für die schatten verwendet, aber stencil-shadows von AT-kanten sind prinzipbedingt unmöglich.
bei fear wird das manchmal so gelöst dass diverse durch AT-texturen dargestellte gitter garnicht in die schattenberechnung mit einfließen, bzw. manchmal einfach das komplette polygon einen schatten wirft (ohne löcher)
Ja, du hast Recht. Ich habe mir das nochmal angeguckt und es scheinen wirklich Polygone zu sein, nur eben nicht als ausmodelliertes Objekt, sondern als ebene Fläche mit Löchern.
Quasar
2006-11-06, 02:00:52
Wenn ich mir das Review von XBit-Labs zur X1950 Pro gegen die 7900 GS so anschaue, dann habe ich fast den Eindruck, dass bei der 7900 doch die ROPs z.T. limitieren könnten.
Von den theoretischen 20% Vorsprung der 7900 GT ggü. der GS bleiben mit Glück ab und zu 10% nach.
Da dort aber nur mit 4xFSAA getestet wurde, könnte das Ganze natürlich auch an der Speicherbandbreite hängen...
micki
2006-11-06, 08:37:20
Oder man hat wie ATI genug in Logik investiert um zuerst an etwas anderem weiterzurechnen.
... die natürlich in der Pipe versteckt wird.
ja, schoene theorie, doch in der realitaet sampled man locker 8mal aus texturen, was pro read im schnitt ne latenz von 10 ALU instructions ist (ATI und NV geben zwar 1:6 bzw 1:7 an, aber das ist nur im falle das alles immer im cache liegt) und die effekte heutzutage setzen immer mehr auf textureleistung, wie z.b. bei parallax mapping, volumelights, posteffects, shadowmaps usw. und das wird weiter in die richtung gehen, da man mit daten viel einfacher (artist kontrollierter) content erstellen kann, als mit irgendwelchen freakigen operationen.
rops sind seltener limitierend und pixelshader-rechenleistung ist natuerlich auch ein faktor, doch meistens nur weil die latenz der texturzugriffe schlecht versteckt wird, wuerde alles unabhaengig voneinander laufen, waeren die texturzugriffe das fuer die performance ausschlaggebende.
ja, schoene theorie, doch in der realitaet sampled man locker 8mal aus texturen, was pro read im schnitt ne latenz von 10 ALU instructions ist (ATI und NV geben zwar 1:6 bzw 1:7 an, aber das ist nur im falle das alles immer im cache liegt) und die effekte heutzutage setzen immer mehr auf textureleistung, wie z.b. bei parallax mapping, volumelights, posteffects, shadowmaps usw. und das wird weiter in die richtung gehen, da man mit daten viel einfacher (artist kontrollierter) content erstellen kann, als mit irgendwelchen freakigen operationen.Darum werde ich mich mal kümmern (schlau machen) aber an dieser Stelle dürfte nichts limitieren. Der G71 hat zum Beispiel generell 220 Takte pro Batch, darin kann man bequem eine Menge verstecken.
Wie soll G71 da was verstecken, wenn der Texturzugriff die ganze ALU-Pipeline stallt?
Wie soll G71 da was verstecken, wenn der Texturzugriff die ganze ALU-Pipeline stallt?
Was ja für die GPGPU Leute einer der Hauptgründe war auf ATI zu setzen.
Dort haben sie mit Zugriffslatenzen kaum ein Problem.
Wie soll G71 da was verstecken, wenn der Texturzugriff die ganze ALU-Pipeline stallt?In dem immer Batches bearbeitet werden. In 221 Takten wird jeweils eine Operation für 220 Quads durchgeführt. Entsprechend hat die TMU Zeit, die Daten zu holen. Im G71 gibts auch keine "ALU-Pipe", es gibt eine Pipe mit ALUs und TMUs. Bei Filterung besser als bilinear wartet die gesamte Pipe, nicht nur die "ALU-Pipeline".
Nein hat sie nicht. Die Pixelshader laufen immer pro Pixel komplett sequentiell durch, das hat mit den Batches nix zu tun.
Die TMU Zeit die Daten zu holen. Vielleicht kann man die Caches füllen, aber die Pipe stallt trotzdem pro Sample einen Takt.
Die TMU Zeit die Daten zu holen. Vielleicht kann man die Caches füllen, aber die Pipe stallt trotzdem pro Sample einen Takt.Die Pipe steht, sofern besser als bilinear gefiltert wird. Aber was hat das mit dependent reads zu tun?
Nein hat sie nicht. Die Pixelshader laufen immer pro Pixel komplett sequentiell durch, das hat mit den Batches nix zu tun.
Jede Shaderinstruktion wird auf 220 Quads ausgeführt, bevor die nächste Instruktion drankommt. Ein bilinearer Texturzugriff stallt in der Regel nicht die Pipeline, das kommt nur in Ausnahmefällen vor.
micki
2006-11-08, 14:13:49
das haengt vom shader und den texturen ab, und heutzutage ist man sehr bandbreiten lastig, klar kann man alu instruktionen hinter texturzugriffen verstecken, nur meist hat man nicht so unglaublich viel mehr zu rechnen als daten lesen und da immer mehr in die alus gesteckt wird, wird das missverhaeltniss zum texturelesen immer groesser.
micki,
dein Posting kann ich jetzt nicht einordnen. Was hängt wovon ab? BTW, gerade weil man heute noch nicht so viel rechnet, ist eine ALU-Blockierung beim G71 – für seine Generation – nicht sonderlich schlimm.
micki
2006-11-08, 22:58:27
micki,
dein Posting kann ich jetzt nicht einordnen. Was hängt wovon ab? BTW, gerade weil man heute noch nicht so viel rechnet, ist eine ALU-Blockierung beim G71 – für seine Generation – nicht sonderlich schlimm.der aufwand fuers texturlesen (aufgrund grosser latenz und heutzutage oft vieler texturereads) ist sehr viel groesser, als was die shader rechnen muessen.
wenn also die latenz versteckt werden sollte, muessten die shader schon extrem lang sein und ca 10 instructions unabhaengig von texturen machen koennen bis die naechste textur kommt. es gibt also nicht wirklich genug, das man hinter der texture-lese-latenz verstecken koennte.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.