dynamisches AA/AF möglich?

[MrMostar]

Gibt es eine Möglichkeit das AA/AF dynamisch einzustellen?

z.B. AA zu Beginn auf 4x, bei weniger als 30fps eine Stufe runter (2x), wird danach die 30fps Grenze wieder unterschritten, geht AA wieder eine Stufe runter (hier: aus), wenn die framerate z.B. über 60 geht sollt natürlich die AA Stufe wieder um eins erhöht werden.
So sollte es möglich sein, die Frameraten immer über 30 fps zu halten, und bei ruhigen Szenen trotzdem hohe AA Werte möglich sein, das Tool sollte den AA Wert immmer herauf und herunterstellen, je nach Bildrate.

Ist so etwas möglich, oder unterbrechen die AA Modiwechsel den Spielfluss zu stark?

[Gast]

Im alten ATI Control Panel gab es da ne Option die sich "Zeitliches AntiAnliasing" nannte.

[tombman]

das war aber was völlig anderes...

könnte man fast "Interlacestes" AA nennen ;D

[Coda]

Hat bestimmt schon mal ein IHV testweise drin gehabt und es wohl für nicht gut befunden ;)

[DeutscherHerold]

halt das für schwer realisierbar, man beachte die nachladezeit wenn man im menü von 0x -> 2x -> 4x AA umstellt.. sowas dynamisch zu regeln würde sich sicher eher kontraproduktiv auf die fps auswirken.

[Gast]

das war aber was völlig anderes...

könnte man fast "Interlacestes" AA nennen ;D
So völlig anders ist es nicht. Temporal AA bietet alternierende Abtastmuster oberhalb einer bestimmten Bildwiederholfrequenz. Wird diese Schwelle unterschritten, schaltet es ab und man bekommt nur die zugrunde liegende AA-Stufe zu sehen.

Dass sich dass feiner granulieren läßt (2*6xAA >60 Fps, 2x4*AA >50 Fps, 6x AA > 40 Fps, 4x AA >30 Fps, 2x AA >20 Fps, kein AA bei weniger als 20 Fps) halte ich durchaus für möglich.

Problematischer ist IMO, dass es ein reaktives Verfahren ist, d.h. der Ruckler ist schon da, bevor angepasst werden kann.

[Spasstiger]

Problematischer ist IMO, dass es ein reaktives Verfahren ist, d.h. der Ruckler ist schon da, bevor angepasst werden kann.
Zum einen das.
Zum anderen würde die Framerate spürbar einbrechen, wenn auf einmal mehr Samples pro Pixel berechnet werden müssen. Wenn die zu berechnende Szene im gleichen Moment auch noch stressiger wird, hätte man starkes Ruckeln zur Folge. Ok, durch eine Hysterese-Regelung und ausreichend hohe Frameraten für die Regelungsgrenzen könnte man diese Effekte vielleicht minimieren.

Trotzdem hätte man dann einen sehr unrunden, springenden fps-Verlauf, den man wohl auch spürt.

Aber wo das Thema "Temporal-AA" von ATI angesprochen wurde: Woher wissen das Triangle-Setup und der Rasterizer eigentlich, wann die Framerate hoch genug ist und sie das Samplemuster ändern dürfen? Das müsste doch über die CPU laufen und somit letzendlich immer mit einer gewissen Verzögerung verbunden sein.

[Xmas]

Aber wo das Thema "Temporal-AA" von ATI angesprochen wurde: Woher wissen das Triangle-Setup und der Rasterizer eigentlich, wann die Framerate hoch genug ist und sie das Samplemuster ändern dürfen? Das müsste doch über die CPU laufen und somit letzendlich immer mit einer gewissen Verzögerung verbunden sein.
Die GPU signalisiert dem Treiber wenn alle Render-Befehle für ein Frame abgearbeitet sind. Der Treiber misst dann einfach die Zeit die für ein Frame (bzw. die letzten paar Frames) benötigt wurde und kann dann möglicherweise sofort ein neues Samplemuster einstellen, denn die GPU ist ja erst am Beginn des nächsten Frames (und wartet evtl. auf einen Startbefehl des Treibers).

[Gast]

Ideal wäre neben einer Entwicklerspezifischen Einstufung, wo welche Art und welcher Grad von FSAA angewandt werden soll, eine User-Einstellung direkt in Windows (OS, weil dann kein IHV dran rumfrickeln darf), wo ich angeben kann, welche Fps-Rate erreicht werden soll.

Dann wissen API, Treiber und GPU im Voraus, wieviel Zeit für jedes Frame zur Verfügung steht und können je nach Spiel oder Content oder sonstwas dynamisch AA (ok, hier halt mit starken Einschränkungen), AF und zusätzlich Post-Processing-Effekte anwenden.

[dargo]

Ich finde diese Idee vom dynamischen AA/AF eh etwas beklopft. Man stelle sich doch mal vor, das AF würde ständig zwischen 2/4/8 und 16x hin und herschalten. Das bewegte Bild würde mich umbringen. :ugly:

[san.salvador]

Voraussetzung wäre natürlich, dass das optional ist. :rolleyes:

Für AF würd ich das glaub ich auch nicht wollen, aber fürs AA wär das eine sehr interessante Sache.

http://www.pawlitta.de/img/dafuer.jpg

:D

[dargo]

Für AF würd ich das glaub ich auch nicht wollen, aber fürs AA wär das eine sehr interessante Sache.

Auch das bezweifle ich. Ständig 2/4/8x AA hin und her würde denke ich auch das Auge stören. Ich vergleiche das mit der Lüftersteuerung einer X1800XL. Diese war genauso bescheuert. Sobald der Chip eine bestimmte Temp. erreicht hat drehte der Lüfter sehr stark auf. Nach paar Sekunden ist die Temp. abgesunken und der Lüfter drehte wieder ziemlich langsam. Das ständige wechseln der Geräuschkulisse ging mir mehr auf die Nerven als wenn der Lüfter ständig mit der schnellen Geschwindigkeit gedreht hätte.

[LordDeath]

ich glaub auch, dass ein ständiges wechseln bei z.B. einem avg 30fps spiel das bild sehr unruhig machen würde. da ist man mit keinem oder wenig aa besser dran, als mit einem ständigen modi-wechsel.

sinnvoll wär das aber meiner meinung nach bei konsolentiteln: die eine szene ist nicht aufwändig, also 4xAA rein. aber bei der massenschlacht dann doch lieber keine kantenglättung.
da hat man ja den vorteil, dass die leistung der hardware konstant ist.

[Lightning]

ich glaub auch, dass ein ständiges wechseln bei z.B. einem avg 30fps spiel das bild sehr unruhig machen würde. da ist man mit keinem oder wenig aa besser dran, als mit einem ständigen modi-wechsel.

sinnvoll wär das aber meiner meinung nach bei konsolentiteln: die eine szene ist nicht aufwändig, also 4xAA rein. aber bei der massenschlacht dann doch lieber keine kantenglättung.
da hat man ja den vorteil, dass die leistung der hardware konstant ist.

Bei Konsolenspielen wird es imo auch ab und zu so eingesetzt. Zumindest kam es mir beispielsweise in ingame-Cutscenes schon öfter so vor, als würde an bestimmten Stellen Edge Anti-Aliasing(?) eingesetzt. Wäre auch nicht unlogisch, da in solchen Cutscenes die Performance ja immer gleich ist und man daher sichergehen kann, dass nicht zu viel Performance verloren geht.

[Kladderadatsch]

sinnvoll wäre es auf jeden fall. eine lösung wäre zum beispiel, einen toleranzbereich von 10 fps (je nach auge z.b. zwischen 30 und 40 fps) festzulegen, der bei der unterschreitung bzw überschreitung eines mittelwertes von x sekunden/minuten den aa/af-grad reguliert.
(ein toleranzbereich wäre zwar nicht unbedingt nötig, würde eine wechselnde regulierung aber noch einmal weiter in die schranken weisen)

bsp.:
ich renne in far cry in außenlevels dank cpu-limitierung am limit, habe indoor allerdings relativ gesehen extrem hohe fps-raten. der treiber stellt nach einer minute fest, dass der mittelwert weit über dem toleranzbereich zwischne 30 und 40 fps liegt und gibt ein paar kohlen ins feuer. da nehme ich doch den ruckler lieber in kauf als die ecken und kanten.

oblivion dürfte auch so ein kandidat sein, bei dem lange indoor-abschnitte mit weit höheren fps als im außenbereich keine seltenheit sind.

[FlashBFE]

Richtig. Solange die Umschaltregelung sinnvoll gestaltet ist und, noch besser, der Benutzer alles einstellen kann, wäre es doch nicht schlecht.

Die Flachbildschirme heutzutage sind nunmal meistens auf 60Hz begrenzt. Warum sollte man eine Mehrleistung der Grafikkarte in anspruchsloseren Szenen einfach verpuffen lassen?

[dargo]

Die Flachbildschirme heutzutage sind nunmal meistens auf 60Hz begrenzt. Warum sollte man eine Mehrleistung der Grafikkarte in anspruchsloseren Szenen einfach verpuffen lassen?
Nicht ganz, meistens sind 75Hz oder gar 85Hz (bei kleinerer Auflösung) drin. An 100Hz TFTs wird afaik gerade gearbeitet was ich auch für "vsync off" User sehr begrüßen würde.

[FlashBFE]

Nicht ganz, meistens sind 75Hz oder gar 85Hz (bei kleinerer Auflösung) drin. An 100Hz TFTs wird afaik gerade gearbeitet was ich auch für "vsync off" User sehr begrüßen würde.

Das stimmt leider nicht. Auch wenn bei manchen Monitoren 75Hz im Datenblatt in ihrer nativen Auflösung angegeben werden, so ist es immernoch nicht sichergestellt, dass sie auch wirklich 75Hz darstellen. Der letzte Test in der Richtung, den ich kenne, hat gezeigt, dass bei den getesteten 75Hz-Monitoren diese intern entweder auf 60Hz runtergerechnet werden oder jeweils 1 von 5 Bildern ausgelassen wird.

Aber darum gehts hier eigentlich garnicht. Es geht um eine sinnvolle Regelung für dynamisches AA und AF und die kann man, wenn man will, für jede beliebige Bildwiederholrate einstellen.

[dargo]

Das stimmt leider nicht. Auch wenn bei manchen Monitoren 75Hz im Datenblatt in ihrer nativen Auflösung angegeben werden, so ist es immernoch nicht sichergestellt, dass sie auch wirklich 75Hz darstellen. Der letzte Test in der Richtung, den ich kenne, hat gezeigt, dass bei den getesteten 75Hz-Monitoren diese intern entweder auf 60Hz runtergerechnet werden oder jeweils 1 von 5 Bildern ausgelassen wird.

Dann erkläre mir bitte warum ich mit 75Hz kaum mehr Tearing bei Vsync off erkenne im Gegensatz zu 60Hz. Bei 60Hz wird das Bild je nach Game regelrecht "zerissen".

[Spasstiger]

Eine Techdemo mit der Idee fände ich auch mal interessant.
Man könnte ja dann nach dem Hystere-Prinzip regeln, also z.B.:
Mehr als 59 fps => von 4xMSAA nach 6x/8xMSAA schalten
Mehr als 49 fps => von 2xMSAA nach 4xMSAA schalten
Mehr als 39 fps => von noAA nach 2xMSAA schalten
Weniger als 50 fps => von 6x/8xMSAA nach 4xMSAA schalten
Weniger als 40 fps => von 4xMSAA nach 2xMSAA schalten
Weniger als 30 fps => von 2xMSAA nach noAA schalten

Die Regelungskurve würde dann so aussehen:
http://www.imagehosting.com/out.php/i399258_dynaahysterese.png

/EDIT: Mir fällt gerade nach einem Gastposting auf, dass es Blödsinn ist, die MSAA-Stufe von den fps abhängig zu machen, also dass 6xMSAA erst bei über 60 fps möglich ist. Viel sinnvoller wäre es, für jede Stufe die gleiche fps-Ober- und Untergrenze zu wählen.
Hab jetzt mal einen Spoiler-Tag um das Zeug oben gesetzt.
Sinnvoll wäre der Vorschlag vom Gast:
unter 30 FPS => AA eine Stufe runter
über 60 FPS => AA eine Stufe höher

[Mr. Lolman]

Ich fänd ein kontrastspezifisches AA da weitaus sinnvoller. Schwache Kontraste = wenig AA, starke Kontraste = viel AA.

[Gast]

Eine Techdemo mit der Idee fände ich auch mal interessant.
Man könnte ja dann nach dem Hystere-Prinzip regeln, also z.B.:
Mehr als 59 fps => von 4xMSAA nach 6x/8xMSAA schalten
Mehr als 49 fps => von 2xMSAA nach 4xMSAA schalten
Mehr als 39 fps => von noAA nach 2xMSAA schalten
Weniger als 50 fps => von 6x/8xMSAA nach 4xMSAA schalten
Weniger als 40 fps => von 4xMSAA nach 2xMSAA schalten
Weniger als 30 fps => von 2xMSAA nach noAA schalten


Warum denn solche Abstufungen?
Ich meine, warum sollten mit 2xAA noch >30FPS akzeptabel sein, aber mit 8xAA nur >50FPS ?

Wäre es nicht sinnvoller, für alle Modi die gleichen Grenzen zu verwenden, also zB.:
unter 30 FPS => AA eine Stufe runter
über 60 FPS => AA eine Stufe höher

[Gast]

Wenn man die Framezahl als Indikator nimmt, dann wird man deutliche Probleme bei der Umschaltung haben. Da eine geringere Stufe des AA gleichbedeutend mit einem Geschwindigkeitszuwachs ist, würde es immer zwischen Stufe 1 und Stufe 2 hin und her wackeln.
Beispiel:
Ich erreiche mit 4xMSAA 60 FPS und wechsle dann auf 8xMSAA um, dann bricht meine FPS auf 40 ein und ich habe wieder 4xMSAA. Dadurch erhöht sie sich wieder...
Es wäre also eine Endlosschleife zwischen 4xMSAA und 8xMSAA, die bestimmt bei dem ein oder anderen Kopfschmerzen verursachen würde.

[Gast]

Wenn man die Framezahl als Indikator nimmt, dann wird man deutliche Probleme bei der Umschaltung haben. Da eine geringere Stufe des AA gleichbedeutend mit einem Geschwindigkeitszuwachs ist, würde es immer zwischen Stufe 1 und Stufe 2 hin und her wackeln.
Beispiel:
Ich erreiche mit 4xMSAA 60 FPS und wechsle dann auf 8xMSAA um, dann bricht meine FPS auf 40 ein und ich habe wieder 4xMSAA. Dadurch erhöht sie sich wieder...
Es wäre also eine Endlosschleife zwischen 4xMSAA und 8xMSAA, die bestimmt bei dem ein oder anderen Kopfschmerzen verursachen würde.
Natürlich, aber das ließe sich umgehen, wenn nur die Grenzen weit genug voneinander entfernt liegen. So wie ich oben vorgeschlagen habe, 30FPS also untere und 60FPS obere Grenze sollten ausreichen, denn man verliert eine höhere AA-Stufe nicht mal eben 50% der FPS.

[Spasstiger]

Es wäre also eine Endlosschleife zwischen 4xMSAA und 8xMSAA, die bestimmt bei dem ein oder anderen Kopfschmerzen verursachen würde.
Deshalb ja auch das Hystereseprinzip und keine einzelne feste Grenzen für den Übergang von zwei Modi. Man müsste vielleicht die Abstände noch größer wählen als ich das getan habe.

Wäre es nicht sinnvoller, für alle Modi die gleichen Grenzen zu verwenden, also zB.:
unter 30 FPS => AA eine Stufe runter
über 60 FPS => AA eine Stufe höher
Oh, stimmt natürlich. Dein Vorschlag klingt sogar recht sinnvoll, der Abstand zwischen den Grenzen ist so groß, dass die Framerate nicht ständig springen würde.

Wer programmiert eine Techdemo? :)
Oder geht das nur treiberseitig so wie "temporal AA"?

[Xmas]

Es geht auch anwendungsseitig, braucht dann allerdings deutlich mehr Speicher (man muss für jede AA-Stufe ein zusätzliches Rendertarget anlegen).

[Gast]

Natürlich, aber das ließe sich umgehen, wenn nur die Grenzen weit genug voneinander entfernt liegen.

Da halte ich dagegen. Mit meiner alten 6800LE 128MB, hatte ich bei CS:S auf einer Map mal mit 1280x1024 2xAA 90 fps und 4xAA 40 fps, weil plötzlich der VRAM nicht mehr ausgereicht hat. Da sollte man also vorsichtig sein.

[Spasstiger]

Da halte ich dagegen. Mit meiner alten 6800LE 128MB, hatte ich bei CS:S auf einer Map mal mit 1280x1024 2xAA 90 fps und 4xAA 40 fps, weil plötzlich der VRAM nicht mehr ausgereicht hat. Da sollte man also vorsichtig sein.
Dann lässt man es halt bleiben mit der dynamischen Regelung, ich sehe da kein Problem. Es soll ja nur ein optionales Feature sein. Man könnte ganz nebenbei auch dann noch die Grenzen so weit auseinanderliegend wählen, dass es trotzdem nicht ständig zu Sprüngen kommt.

Im Normalfall, wenn es nicht zur VRAM-Limitierung kommt, bricht die Framerate bei einer Verdoppelung des MSAA-Grades auf schlimmstenfalls die Hälfte ein. Und das auch nur, wenn man an einer Bandbreitenlimitierung hängt. Wenn man nicht bandbreiten- und nicht VRAM-limitiert ist, wird die Framerate um nichtmal 20% einbrechen bei einer Verdoppelung des MSAA-Grades (wie man z.B. immer wieder bei Erscheinen neuer High-End-Karten sieht).

[MrMostar]

Leider war ich Beruflich unterwegs, und konnte meinen Thread nicht verfolgen,
freue mich aber das es möglich erscheint, über mehrere Rendertargets die Umschaltung zwischen den AA Stufen verzögerungsfrei zu gestalten.
Es bildet sich auch ein Konsens auf die von mir im Startpost vorgeschlagenen 30/60 fps Schaltschwellen.

Dazu drei weitere Vorschläge zum Ausbau meiner ursprünglichen Idee:

1. Die User sollten beide Schaltschwellen selbst beeinflussen können.
-Es sollte lediglich im Setting verhindert werden, das die beiden Werte zu nah zusammengeschoben werden können, um ein Pendeln zwischen 2 AA Werten zu verhindern
-Es sollte hier auch an die Low End und extreme High end Hardware User gedacht werden


2. Die Anzahl der AA Stufen sollte beschränkt werden können.
-Die Rendertargets für 16FSAA brauchen sehr viel Speicher , User mit wenig VRAM sollten diese abwählen können, weil die Rendertargets für hohe AA Modi ständig vom Texturspeicher abgezogen werden müssen
-Poweruser möchten evtl. niedrige AA Stufen ausklammern


3. Die Regelung sollte für den fps Eingangswert einen Tiefpassfilter mit einer Cutoff Frequency von ca. 1Hz enthalten, um kurzzeitige Schwankungen auszugleichen.
-eine einfache Implementation wäre die duchschnittlichen fps über die letzen 30 frames
-Dieser Werst sollte sich auch in den Grenzen 10-90 vom User beeinflussen lassen.




eine Frage ist noch offen:
Muss die Anwendung/Spiel dynamisches AA unterstützen in Hinsicht auf mehrere Rendertargets?

PS.
Gibt es bereits ein AA Tool, das man über die fps (fern)steuern könnte?

[FlashBFE]

3. Die Regelung sollte für den fps Eingangswert einen Tiefpassfilter mit einer Cutoff Frequency von ca. 1Hz enthalten, um kurzzeitige Schwankungen auszugleichen.
-eine einfache Implementation wäre die duchschnittlichen fps über die letzen 30 frames
-Dieser Werst sollte sich auch in den Grenzen 10-90 vom User beeinflussen lassen.


Das finde ich nicht so gut. Vor allem beim Runterschalten muss die Regelung möglichst schnell reagieren können. Nicht dass die FPS erstmal eine Sekunde lang im Keller sind, wenn die Szene plötzlich sehr komplex wird.

Also wenn so eine Verzögerung rein soll, dann höchstens nur für den Hochschaltfall, aber auch hier erkenne ich irgendwie keinen Nutzen darin, da die Schaltschwellen schon alles ausbügeln sollten.

[MrMostar]

Na dann Erweitern wir den Einstellbereich 'fps Integral über die letzten xx frames'
auf 1-99 ;)
edit - mit 2 getrennten Werten für AA up und AA down
Das ist ja auch eher dazu gedacht ein Schwingen zu unterbinden, für solche Sonderfälle:

Gast:
Da halte ich dagegen. Mit meiner alten 6800LE 128MB, hatte ich bei CS:S auf einer Map mal mit 1280x1024 2xAA 90 fps und 4xAA 40 fps, weil plötzlich der VRAM nicht mehr ausgereicht hat. Da sollte man also vorsichtig sein.

[Spasstiger]

Also wenn so eine Verzögerung rein soll, dann höchstens nur für den Hochschaltfall, aber auch hier erkenne ich irgendwie keinen Nutzen darin, da die Schaltschwellen schon alles ausbügeln sollten.
Stell dir vor, du drehst dich und schaust dabei für einen Frame gegen eine Wand. Dieser Frame wird nun in 10 ms berechnet (= 100 fps), während die anderen Frames z.B. jeweils 30 ms brauchen (= 33 fps). Das Spiel registriert nun für diesen einen Frame "hohe Framerate" und schaltet für den nächsten Frame hoch von z.B. 2xMSAA auf 4xMSAA. Der nächste Frame würde aber mit 2xMSAA schon 30 ms brauchen. Im Falle einer Bandbreitenlimitierung würde der Frame mit 4xMSAA nun 60 ms lang in der Pipeline stecken (= 17 fps), d.h. die Framerate bricht für einen Moment von effektiv 100 fps auf 17 fps ein. Und das spürt man auch.
Man muss also definitiv die Rechenzeiten von mehreren Frames beobachten, zumindest beim Hochschalten.
Beim Runterschalten kann man natürlich immer sofort reagieren, da man ja niedrige Frameraten immer verhindern will (wobei man auch hier dem Nutzer die Wahl lassen könnte).

Sinnvolle Optionen für eine entsprechende Techdemo wären:
- obere Schaltschwelle (einstellbar von z.B. 30 fps bis 200 fps, default 60 fps)
- untere Schaltschwelle (einstellbar von z.B. 15 fps bis 60 fps, default 30 fps)
- Anzahl zu messender Frames für obere Schwelle (einstellbar von z.B. 1 bis 100 Frames, default 30 Frames)
- Anzahl zu messender Frames für untere Schwelle (einstellbar von z.B. 1 bis 100 Frames, default 1 Frame)
- max. AA-Grad (default 4xMSAA)
- min AA-Grad (default noAA)

Die Frage ist noch, wie im Fall einer CPU-Limitierung vorgegangen werden könnte, wenn man mit jeder AA-Einstellung nur 25 fps erreicht.

[MrMostar]

Auch beim Runterschalten sollte eine leichte Verzögerung vorgesehen werden, da sonst z.B. bei sporadischen Festplattenzugriffen die (ungedämpfte) Regelung einen Überschwinger produziert: xxx frames 50 fps 1 frame 15 fps ->AArunter 1frame 70 fps ->AArauf
Besser wäre z.B. für Oblivion eine deutlich stärkere Dämpfung.

Besser wäre:
- obere Schaltschwelle (einstellbar von z.B. 20 fps bis 200 fps, default 60 fps bzw. Bildwiderholrate Monitor)
- untere Schaltschwelle (einstellbar von z.B. 10 fps bis 100 fps, default 30 fps bzw. Bildwiderholrate Monitor /2)
+ Einschränkung durch die Software: obere Schaltschwelle >= 2x untere Schaltschwelle
- Anzahl zu messender Frames für obere Schwelle (einstellbar von z.B. 1 bis 100 Frames, default 30 Frames)
- Anzahl zu messender Frames für untere Schwelle (einstellbar von z.B. 1 bis 100 Frames, default 3 Frames)
- max. AA-Grad (default 4xMSAA)
- min AA-Grad (default noAA)
CPU Limitierung:
Kann gemessen werden ob die GPU vollausgelastet ist?
- ist diese nicht mehr ausgelastet, weil die CPU nicht nachkommt, sollte die Regelung ausser Kraft gesetzt werden.

[Xmas]

Da halte ich dagegen. Mit meiner alten 6800LE 128MB, hatte ich bei CS:S auf einer Map mal mit 1280x1024 2xAA 90 fps und 4xAA 40 fps, weil plötzlich der VRAM nicht mehr ausgereicht hat. Da sollte man also vorsichtig sein.
Eine solche dynamische Regelung würde nur dann gut funktionieren, wenn der Speicher für die höchste gewünschte AA-Stufe bereits im voraus reserviert wird. Der Speicherbedarf wäre in diesem Modus also konstant hoch.


CPU Limitierung:
Kann gemessen werden ob die GPU vollausgelastet ist?
Der Treiber kann in der Regel recht genau ermitteln wo eine Limitierung vorliegt. Von daher wäre eine Regelung basierend auf der Framerate wahrscheinlich gar nicht notwendig, man könnte ebenso feststellen ob ROPs oder Bandbreite limitieren.

[Armaq]

Hierzu müsste eine bidirektionale Verbindung exklusiv für CPU - Grafikkarte doch von riesigem Nutzen sein, oder?
Damit könnte man solche Dinge viel einfach Regeln ... hatte AMD nicht in diese Richtung gedacht?

[Coda]

Ich fänd ein kontrastspezifisches AA da weitaus sinnvoller. Schwache Kontraste = wenig AA, starke Kontraste = viel AA.
Geht bei einem IMR nicht. Das Bild ist erst fertig wenn das AA bereits angewendet wurde.

[MrMostar]

@Xmas
Die Regelung würde beispielhaft so funktionieren?

CPU Last<75% eine AA Stufe runter
ROP Last<75% eine AA Stufe rauf

Daraus resultierende Einstellmöglichkeiten:
- Schaltschwelle Lastunterschreitung CPU(einstellbar von z.B. 10% bis 99%, default 75%)
- Schaltschwelle Lastunterschreitung ROP(einstellbar von z.B. 10% bis 99%, default 75%)
- Zeitraum Lastmessung für CPU (einstellbar von z.B. 0.01 bis 10s, default 1s)
- Zeitraum Lastmessung für ROP (einstellbar von z.B. 0.01 bis 10s, default 0.2s)
- max. AA-Grad (default 4xMSAA)
- min AA-Grad (default noAA)

[MrMostar]

Eine Anmerkung noch, eine reine Lastmessungsmethode ist doch nicht optimal, da bei hohen fps Werten die Leistung verpufft, besser ist doch eine Kombination aus beiden Methoden, d.h. bei fps Werten über 60 sollte wieder auf die fps Regelung umgeschalten werden und bei dauerhaft niedrigen fps Werten zurück auf Lastoptimierung.

[aths]

Ich fänd ein kontrastspezifisches AA da weitaus sinnvoller. Schwache Kontraste = wenig AA, starke Kontraste = viel AA.Du weißt aber im Vorhinein nicht, wie stark die Kontraste sind. Wenn du primär eine Kontrastangleichung möchtest, sollten wir lieber über größere Filterkernel beim Downsampling reden.


Ich finde diese Idee vom dynamischen AA/AF eh etwas beklopft. Man stelle sich doch mal vor, das AF würde ständig zwischen 2/4/8 und 16x hin und herschalten. Das bewegte Bild würde mich umbringen. :ugly:Das ergibt auch nicht viel Sinn. Beim AF sollte je nach vom User eingestellten Qualitätslevel die entsprechende Texturschicht ein vom Entwickler vorgegebenes Maximal-AF erhalten. AF ist ja per se schon "dynamisch". Für viele Texturschichten brauchts aber kein 16x AF.

Beim Antialiasing ist 2x auf halbwegs aktuellen Karten immer drin. Wer 4x haben will, braucht etwas mehr Leistung, die aber auch oft genug vorhanden ist.

[FlashBFE]

Stell dir vor, du drehst dich und schaust dabei für einen Frame gegen eine Wand. [...]
Gute Erklärung! :)

Auch beim Runterschalten sollte eine leichte Verzögerung vorgesehen werden, da sonst z.B. bei sporadischen Festplattenzugriffen die (ungedämpfte) Regelung einen Überschwinger produziert: xxx frames 50 fps 1 frame 15 fps ->AArunter 1frame 70 fps ->AArauf
Das macht aber im Prinzip nichts. Dann hast du eben mal für ein Frame so einen Sprung drin. Das Verhalten bleibt aber richtig, denn du willst ja, wenn es wirklich drauf ankommt, nicht erst nen Ruckler haben, bevor die Grafikkarte reagiert.
Es ist zwar nicht direkt vergleichbar, aber bei ATIs Temporal-AA hat man das ständige Umgedrehe der Samplemuster bei 2xAA auch nicht gesehen, da hat nichts geflimmert, weils einfach zu schnell war. Deswegen sollte es auch keinen Augenkrebs verursachen, mal ein Frame eine AA Stufe runter- und dann gleich wieder hochzuschalten.

Eine Anmerkung noch, eine reine Lastmessungsmethode ist doch nicht optimal, da bei hohen fps Werten die Leistung verpufft, besser ist doch eine Kombination aus beiden Methoden, d.h. bei fps Werten über 60 sollte wieder auf die fps Regelung umgeschalten werden und bei dauerhaft niedrigen fps Werten zurück auf Lastoptimierung.

Ich würde nur nach den FPS gehen, mit einem lernenden Algorithmus.
Wenn der Prozessor limitiert, dann merkt man es an den FPS, indem man die BQ hochschrauben kann, ohne FPS zu verlieren.
Wenn das Speicherinterface limitiert, dann merkt man es genauso, wenn die FPS überproportional einbrechen. Diese Stufe, bei der das passiert, könnte dann automatisch seltener aktiviert werden.
Man muss so eine Regelung ja nicht umständlicher machen, als es sein muss, schließlich kostet das auch Rechenleistung.

[Gast]

Es geht auch anwendungsseitig, braucht dann allerdings deutlich mehr Speicher (man muss für jede AA-Stufe ein zusätzliches Rendertarget anlegen).

wieso? es würde doch eigentlich 1 rendertarget für die größtmögliche FSAA-stufe reichen. wird eine niedrigere FSAA-stufe verwendet werden einfach ein teil der subpixel nicht verwendet.

man verschwendet dabei natürlich bei den niedrigeren FSAA-stufen etwas speicher, aber lange nicht soviel wie wenn man für jede stufe ein rendertarget hätte.

[Gast]

Ich fänd ein kontrastspezifisches AA da weitaus sinnvoller. Schwache Kontraste = wenig AA, starke Kontraste = viel AA.

geht nicht, möglich wäre höchstens ein postfilter der kontraste erkennt und diese blurrt, aber kein echtes FSAA.

[Gast]

Ich finde diese Idee vom dynamischen AA/AF eh etwas beklopft. Man stelle sich doch mal vor, das AF würde ständig zwischen 2/4/8 und 16x hin und herschalten. Das bewegte Bild würde mich umbringen. :ugly:


für AF wäre das auch komplett sinnlos, das ist per definition dynamisch, es bekomm jedes pixel immer nur soviel AF wie nötig ab, bis zum eingestellten maximalgrad.

[TheRealTentacle]

Die Radeon 8500 Konnte das, in einem gewissen Rahmen. Wenn der Speicher nicht mehr ausgereicht hat, hat sie einen Modus herunter geschaltet, und das auch mittem im Spiel (Hab ich nei UT 2003 erlebt). Allerdings passierte das selten bei flüssigen Framerates.

[Gast]

Geht bei einem IMR nicht. Das Bild ist erst fertig wenn das AA bereits angewendet wurde.
Mit einem Frame Verzögerung müsste es eigentlich schon gehen. Fragt sich nur, wie das dann aussieht.