Archiv verlassen und diese Seite im Standarddesign anzeigen : News 3./4. April 2004
Demirug
2004-04-05, 08:51:30
Ich kann mich für das "dynamische AA" welches in dem besagten PDF beschrieben wird nun nicht sonderlich erwärmen.
Das ganze läuft auch einen Mix aus MS und einem zusätzlichen Supersampling Anteil hinaus. Wobei der MS Anteil fest ist und nur der Supersampling Anteil dynamisch verändert wird. Im schlimmsten Fall kann diese Lösung sogar einen SS-Anteil von unter 1 erreichen indem sie die Renderauflösung unter die Bildschirmauflösung senkt und dann eben hochskaliert.
Das ganze kann ja durchaus helfen die Framerate stabil zu bekommen hat allerdings noch einen weiteren grossen Hacken. Koppelt man das ganze an die FPS kann es sehr schnell passieren das die Bildqualität aufgrund zu geringer FPS reduziert wird aber die FPS nicht steigt weil die limitierung an einer anderen Stelle liegt. Da die Reduzierung nichts gebracht hat könnte die Engine dann auf die Idee kommen noch weiter zu reduzieren. Am Ende hat man dann keinen Frame mehr aber die schlechteste Bildqualität die man sich vorstellen kann obwohl die Grafikkarte genügend Leistung hätte um die beste Qualität darzustellen weil die CPU am Limit ist.
AlfredENeumann
2004-04-05, 11:26:17
Stimme dem zu. Zum anderen wäre die Vergleichbarkeit, vor allem bei Benches noch weniger gegeben als es jetzt sowieso schon ist.
mapel110
2004-04-05, 11:35:12
Original geschrieben von AlfredENeumann
Stimme dem zu. Zum anderen wäre die Vergleichbarkeit, vor allem bei Benches noch weniger gegeben als es jetzt sowieso schon ist.
Ich bezweifle, dass die Gameentwickler grosses interesse daran haben, dass ihre Produkte sich gut benchmarken lassen, geschweigedenn dass sie sich überhaupt benchmarken lassen.
Halbiert ja unter umständen die Käuferschicht. :)
Dynamisches AA find ich irgendwie uninteressant. entweder genug leistung insgesamt, oder eben nicht. das würde mich bei einem game irgendwie dazu bringen, dass mir die kanten noch stärker auffallen.
SuperHoschi
2004-04-05, 14:48:14
Jetzt ist genau das gemacht worden, was ich schon vor einiger
Zeit nachgefragt habe, ob es den möglich ist, da für mich dieses
der nächste logische Schritt wäre.
Jeder 3D Guru meinte das es nonsens ist.
siehe:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1594072#post1594072
Das Werkzeug ist da. Jetzt muss es nur noch "vernünftig"
eingesetz werden. Wie Demi ja schon festgestellt hat.
lg
SuperHoschi
Ausserdem würde doch eine ziemlich Unruhe ins Bild kommen, wenn da dauernd der SS-Anteil verändert wird. Ausser man benutzt hohe MSAA Stufen, sagen wird ab 4xRGAA oder 6xSGAA.
Dann allerdings würde es kaum was bringen überhaupt noch zusätzliches AA einzuschalten. Imho ist das ganze eigentlich für die Katze und leidet an den gleichen Problemen wie eine Zufälliges Abtastmuster.
@ demi man könnte doch sicherlich auch einstellen, dass der SSAA-Anteil nicht unter 1 fällt, dann hätte man doch zumindest das von dir angesprochene Problem gelöst...
Demirug
2004-04-05, 16:07:24
Original geschrieben von SuperHoschi
Jetzt ist genau das gemacht worden, was ich schon vor einiger
Zeit nachgefragt habe, ob es den möglich ist, da für mich dieses
der nächste logische Schritt wäre.
Jeder 3D Guru meinte das es nonsens ist.
siehe:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1594072#post1594072
Das Werkzeug ist da. Jetzt muss es nur noch "vernünftig"
eingesetz werden. Wie Demi ja schon festgestellt hat.
lg
SuperHoschi
Man kann so aber nur den SS-Anteil kontrolieren aber nicht den MS Anteil. Da heute kaum ein Spiel Füllrate im Überfluss übrig lässt bringt das nicht viel.
Demirug
2004-04-05, 16:08:30
Original geschrieben von burk23
@ demi man könnte doch sicherlich auch einstellen, dass der SSAA-Anteil nicht unter 1 fällt, dann hätte man doch zumindest das von dir angesprochene Problem gelöst...
Natürlich. Nur dann kann es nie schneller werden als es im Moment mit dem gleiche MSAA sowieso schon ist.
Wenn dieses Dynamische AA irgendwann in jedem Spiel "eingebaut" ist,wozu dann noch GraKas mit fetter Rohpower?
Dann spar ich nicht jedesmahl auf ne sauteure GraKa,sondern kaufe mir nur irgendwelche Mittelklassekarten.
Damit gräbt sich doch ein GPU-Hersteller selbst das Wasser ab.Wer käuft dann schon ne GraKa für>400€?
Oder seh ich das falsch?
Riptor
2004-04-05, 17:05:19
Original geschrieben von Gast
Oder seh ich das falsch?
Es gibt eben andere Wege, eine Grafikkarte in die Knie zu zwingen. Dynamische Lichtquellen en masse, komplexere Welten und vielleicht irgendwann "64-Bit Farbtiefe". ;) Wenn AA nicht mehr das Killerfeature ist, dann kommt eben ein neues, was man haben "muß". Denn damit würde eben nur das AA-Performanceproblem beseitigt werden... Nicht aber die allgemeine Geschwindigkeit der Spiele, die wäre ja immer gleich und wer die volle Qualität will, greift sowieso zur High-End Karte.
Auch wenn ich es schon gepostet habe, hier hätte es ja anscheinend hingehört:
Moment mal, bei der Funktionsweise des dynamischen AA nach NV-Empfehlung kam mir doch gleich sofort der gedankliche Querverweis zu den Problemen der R3X0 Chips mit riesigen Texturen. Ist das jetzt ein gedanklicher Schnellschuß oder versucht NV, den ATI-Karten Blockbildungen beim Kantenbügeln unterzujubeln, die auf unzureichend genauer Hardware beruhen und daher NICHT per Treiber ausgebügelt werden können? Quasi als Retourkutsche für das Miesmachen des Branching beim NV40?
Wäre nätürlich sehr hintertückisch, ATI ausgerechnet bei der Kantenglättung zu schlagen bei gleichzeitig breiterer Einsatzmöglichkeit! Und Blockbildung in ruhigen Bildern, wo das dynamische AA richtig aufdreht, das fällt extrem auf!
Bitte nur technische Comments, wer sich momentan (un)korrekter verhält ist mir schnuppe.
Ein unregistrierter Leser, der hofft genug verstanden zu haben um das Denken anderer anstoßen zu können...
Aquaschaf
2004-04-05, 19:08:39
Wie schon gesagt wurde, viel BQ kann die Sache nicht bringen da bei aktuellen Spielen nur selten für Supersampling genug Füllrate vorhanden ist. Was hat die Sache mit großen Texturen zu tun?
http://www.3dcenter.org/artikel/2003/11-21_b.php
Kämen die bilinearen Artefakte nicht auch in einen dynAA-Modus auf einer Radeon?
Ein unregistrierter Leser, der hofft genug verstanden zu haben um das Denken anderer anstoßen zu können...
ShadowXX
2004-04-05, 19:47:05
Original geschrieben von Gast
http://www.3dcenter.org/artikel/2003/11-21_b.php
Kämen die bilinearen Artefakte nicht auch in einen dynAA-Modus auf einer Radeon?
Ein unregistrierter Leser, der hofft genug verstanden zu haben um das Denken anderer anstoßen zu können...
a.) könne die Radeons kein SSAA (zumindest unter Windows und auf dem MAC war es auch nur eine Notlösung)
und
b.) was hat das DynaAA jetzt gross mit den Texturfiltern zu tun...(davon abgesehn, das man diese Bilineare Artefaktbildung sowieso nicht bemerkt)
und als letztes
c.) Müssen das die SW-Entwicker ja auch erstmal überhaupt unterstützen (es ist kein "Zuschalteffekt" wie das jetzige MSAA der Radeon bzw. des MS/SSAA der nVs)
zu a), b) und c) eine kombinierte Antwort:
Das was programmiert werden muß ist doch gerade das Supersampling und die dynamische Umschaltung zwischen mehreren SS-Modi (1x1, 2x2, 3x3 etc.)
Das NV-pdf von hier:
http://download.nvidia.com/developer/presentations/GDC_2004/D3DTutorial_Sim.pdf
noch nicht gelesen?
Zu dem Zusammenhang mit übergroßen Texturen bin ich noch am Suchen, aber mit an Sicherheit grenzender Wahrscheinlichkeit ist es auch hier auf 3dcenter...
*weiterdurchhtmlwühl*
Ein unregistrierter Leser, der hofft genug verstanden zu haben um das Denken anderer anstoßen zu können...
Demirug
2004-04-05, 20:17:02
Das "Problem" von ATI bei handgemachtem SS ist das man bei 4xAA (2x2OG) maximal eine Auflösung von 1024*1024 erreichen kann weil ATI nur Texturen bis 2048*2048 unterstützt.
ShadowXX, der Filter kann eine Rolle spielen wenn der Blit über die Texturfilter durchgeführt wird.
Leonidas
2004-04-05, 20:21:35
Original geschrieben von Demirug
Ich kann mich für das "dynamische AA" welches in dem besagten PDF beschrieben wird nun nicht sonderlich erwärmen.
Das ganze läuft auch einen Mix aus MS und einem zusätzlichen Supersampling Anteil hinaus. Wobei der MS Anteil fest ist und nur der Supersampling Anteil dynamisch verändert wird. Im schlimmsten Fall kann diese Lösung sogar einen SS-Anteil von unter 1 erreichen indem sie die Renderauflösung unter die Bildschirmauflösung senkt und dann eben hochskaliert.
Das ganze kann ja durchaus helfen die Framerate stabil zu bekommen hat allerdings noch einen weiteren grossen Hacken. Koppelt man das ganze an die FPS kann es sehr schnell passieren das die Bildqualität aufgrund zu geringer FPS reduziert wird aber die FPS nicht steigt weil die limitierung an einer anderen Stelle liegt. Da die Reduzierung nichts gebracht hat könnte die Engine dann auf die Idee kommen noch weiter zu reduzieren. Am Ende hat man dann keinen Frame mehr aber die schlechteste Bildqualität die man sich vorstellen kann obwohl die Grafikkarte genügend Leistung hätte um die beste Qualität darzustellen weil die CPU am Limit ist.
Stimmt wohl. Mein Text war jetzt allerdings unabhängig von der Art des dynamischen AA, es ging rein nur um die Möglichkeiten.
Leonidas
2004-04-05, 20:23:38
Original geschrieben von Gast
Auch wenn ich es schon gepostet habe, hier hätte es ja anscheinend hingehört:
Moment mal, bei der Funktionsweise des dynamischen AA nach NV-Empfehlung kam mir doch gleich sofort der gedankliche Querverweis zu den Problemen der R3X0 Chips mit riesigen Texturen. Ist das jetzt ein gedanklicher Schnellschuß oder versucht NV, den ATI-Karten Blockbildungen beim Kantenbügeln unterzujubeln,
Das PDF liegt zwar auf dem nVidia-Server, stammt aber offenbar von ATi und NV zusammen.
ShadowXX
2004-04-05, 22:43:46
Original geschrieben von Demirug
Das "Problem" von ATI bei handgemachtem SS ist das man bei 4xAA (2x2OG) maximal eine Auflösung von 1024*1024 erreichen kann weil ATI nur Texturen bis 2048*2048 unterstützt.
ShadowXX, der Filter kann eine Rolle spielen wenn der Blit über die Texturfilter durchgeführt wird.
Du meinst den Blit für den SS anteil, oder??
Demirug
2004-04-05, 22:48:08
Original geschrieben von ShadowXX
Du meinst den Blit für den SS anteil, oder??
Genau. Am Ende muss ja von der Renderauflösung in die Bildschirmauflösung umgerechnet werden.
ShadowXX
2004-04-05, 22:54:52
Original geschrieben von Demirug
Genau. Am Ende muss ja von der Renderauflösung in die Bildschirmauflösung umgerechnet werden.
Danke...dann hatte ichs richtig verstanden und muss zugeben, dass ich daran vorhin nicht gedacht hatte...
egdusp
2004-04-06, 00:44:35
Ich kann prinzipiell schon Vorteile bei dynamischen Qualitätsanpassungen zur Erreichung von konstanten fps erkenne.
Wenn ich mich recht erinnere hatte Shiny mal so etwas in Software, sah für damalige Verhältnisse sehr geil aus (die Figuren), hieß Messiah, die Engine wurde auch noch für Sacrifice genutzt.
Zum Topic:
Da durch CC und Shader das AA wohl immer seltener die kritische Komponente darstellt, ist es eigentlich unsinnig da anzusetzten.
Sinnvoll wäre aber IMHO dieses Verfahren bei AF und Shadern.
Durch die Anpassung des AF Levels je nach fps könnte massig Füllrate gespart werden.
Durch Branching könnten bei den Shadern komplexe und "langsame" durch schnelle aber unschönere ersetzt werden. Ich weiß hierbei allerdings nicht, ob es immer funktioniert, d.h. für jeden Shadern eine weniger schöne Entsprechung existiert. Evtl. könnten Effekte komplett wegfallen, dies dürfte dann aber im Spiel schon negativ auffallen.
Die Reduzierung des AF halte ich für einen sehr einfachen und vielversprechenden Ansatz, seltsam, dass sie zuerst auf das AA kamen.
Die Meinung, dass dies eine Sache der Programmierer sei, teile ich nicht. Der Treiber kann leicht die fps auslesen und entsprechend den AF Level anpassen. Ob der Treiber auch den Engpass korrekt identifizieren kann weiß ich nicht, aber beim AF kann ich es mir sehr gut vorstellen. Bei Shadern sollte eine Auswertung auch recht flott gehen (wieviel ops pro Bild geleistet, sofern kritische Grenze überschritten Shader vereinfachen).
In der Praxis gibt es da sicher noch Probleme, aber nichts was ich für unlösbar halte.
Wird auf Pixelshader Effekte auch AF angewandt?
Stehen (AF-)Füllrate und arithmetische Rechenleistung in einer Interdependez, z.B. in einer negativen Relation?
mfg
egdusp
Demirug
2004-04-06, 01:44:22
egdusp, das AF könnte der Treiber ja noch reduzieren wenn er erkennt das die Fillrate ausgeht. Shader automatisch vereinfachen ist dagegen schon fast ein Ding der unmöglichkeit. In der Regel tut sich ein Treiber leichter die Flaschenhälse zu finden weil er viel mehr Informtionen von der Karte erhalten kann.
Auf einen Pixelshader selbst wird kein AF angewendet nur auf die Texturen die er benutzt. Aus diesem Grund stehen die Fillrate und Rechenleistung auch in einer Beziehung. Da beides gleichzeitig abläuft hat man für beide teile (Rechnen und Samplen) die gleiche Anzahl von takten zur Verfügung. Benutzt man aufwendige Texturfilter hat man im gegenzug wenn die Filter zum Einsatz kommen auch viele Takte zum rechnen. Hat man einen Shader der viel rechnet kann man die Texturen in der Regel auch gut filtern weil die Takte für den Pixel ja sowieso aufgrund der Rechnungen benötigt werden.
egdusp
2004-04-06, 09:20:30
Ich habe mich schlecht ausgedrückt. Natürlich kann der Treiber shader nicht automatisch "schlechter" optimieren, aber er könnte ein Flag setzten, so dass ein 3.0 Shader weiß, dass er jetzt Qualität für Geschwindigkeit opfern soll. Natürlich muss der Shader vorher entsprechend programmiert worden sein.
Mein Hauptbedenkenhierbei war ja, ob es für jeden Shader oder zumindest für die gängisten schnellere Versionen gibt und ob man das Umschalten on the fly bei denen merken würde.
mfg
egdusp
egdusp
2004-04-06, 09:21:34
Original geschrieben von Demirug
Auf einen Pixelshader selbst wird kein AF angewendet nur auf die Texturen die er benutzt. Aus diesem Grund stehen die Fillrate und Rechenleistung auch in einer Beziehung. Da beides gleichzeitig abläuft hat man für beide teile (Rechnen und Samplen) die gleiche Anzahl von takten zur Verfügung. Benutzt man aufwendige Texturfilter hat man im gegenzug wenn die Filter zum Einsatz kommen auch viele Takte zum rechnen. Hat man einen Shader der viel rechnet kann man die Texturen in der Regel auch gut filtern weil die Takte für den Pixel ja sowieso aufgrund der Rechnungen benötigt werden.
Interpretiere ich das richtig, dass ein Reduzieren des AF Levels keine Arithmetik Ops spart?
mfg
egdusp
Demirug
2004-04-06, 10:07:34
Original geschrieben von egdusp
Ich habe mich schlecht ausgedrückt. Natürlich kann der Treiber shader nicht automatisch "schlechter" optimieren, aber er könnte ein Flag setzten, so dass ein 3.0 Shader weiß, dass er jetzt Qualität für Geschwindigkeit opfern soll. Natürlich muss der Shader vorher entsprechend programmiert worden sein.
Mein Hauptbedenkenhierbei war ja, ob es für jeden Shader oder zumindest für die gängisten schnellere Versionen gibt und ob man das Umschalten on the fly bei denen merken würde.
mfg
egdusp
OK, das wäre natürlich eine Möglichkeit. Wenn man die unterschiedlichen Level of Details von Entwickler festlegen lässt. Wenn es eben keine einfacherer Version gibt dann eben nicht. Ist genau wie bei den Mipmaps einer Textur. Die Gefahr das man es sieht ist natürlich sehr hoch. Ein einfacherer Shader führt auch zu einer einfacheren Version des Effekts.
Demirug
2004-04-06, 10:08:12
Original geschrieben von egdusp
Interpretiere ich das richtig, dass ein Reduzieren des AF Levels keine Arithmetik Ops spart?
mfg
egdusp
Richtig, Reduzieren des AFs spart nur Füllrate aber keine Rechenleistung im Shader.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.