Archiv verlassen und diese Seite im Standarddesign anzeigen : Noch mehr "intelligente" Texturfilter?
Demirug
2004-06-29, 15:39:39
Nachdem die Grafikchip hersteller die Texturfilter als Möglichkeit zum sparen zugunsten der Speed entdeckt haben muss man sich die Frage stellen wie sich dieser Trend weiterentwickeln wird. Wird man uns bei der nächsten Generation wieder neue Varianten anbieten oder gar aufzwingen welche die Filtergschwindihkeit zu lasten der Genauigkeit erhöhen? Wird man das ganze als noch intellengenter Verkaufen?
Oder kommt es zu einer Trendwende und wir bekommen wirklich Filterverfahren welche abhängig vom Texturinhalt pro Sample (bzw pro Quad) den Filter so varieren das im Endergebniss die Abweichung ein vorher festgelegtes Mass (einstellbar im CP) nicht übersteigt?
Gaestle
2004-06-29, 16:00:45
Original geschrieben von Demirug
Nachdem die Grafikchip hersteller die Texturfilter als Möglichkeit zum sparen zugunsten der Speed entdeckt haben muss man sich die Frage stellen wie sich dieser Trend weiterentwickeln wird.
A)Wird man uns bei der nächsten Generation wieder neue Varianten anbieten oder gar aufzwingen welche die Filtergschwindihkeit zu lasten der Genauigkeit erhöhen? Wird man das ganze als noch intellengenter Verkaufen?
B)Oder kommt es zu einer Trendwende und wir bekommen wirklich Filterverfahren welche abhängig vom Texturinhalt pro Sample (bzw pro Quad) den Filter so varieren das im Endergebniss die Abweichung ein vorher festgelegtes Mass (einstellbar im CP) nicht übersteigt?
Ich denke mal, Kandidat A) gewinnt (zumindest bei SPD und Bündnisgrünen)...
Grüße
So lange die "Need4Speed" sich weiterhin künstlich wachhalten läßt, und solange ungefragte und möglicherweise ungewollte Optimierungen nicht durch den User durch Kaufverweigerung abgestraft werden, sehe ich ehrlich gesagt schwarz.
Evtl. werden wir ja bei nV70/R700 ein bahnbrechendes neues Feature namens "patent-pending full-trilinear" geboten bekommen. :|
MadManniMan
2004-06-29, 17:34:56
Ich hoffe ganz ehrlich, daß sich bereits bei den jetzt kommenden Chips treibermäßig dahingehend was tut, daß zumindest die Hardware ausgenutzt wird.
Für zukünftige Karten würde ich mir wünschen, daß - wie aths es andeutete - eine NV40-Quali ohne Winkelabhängigkeit beim AF erreicht würde, was AF anbelangt.
Bei zukünftigen ATis würde mir reichen, wenn die Treibereien dahingehend fortgeführt werden, daß man die ganzen Filtertricks bei Bedarf abstellen kann. Einen Schritt weiter: Winkeladaption und das Flimmer-LoD(TM) weg!
Original geschrieben von Demirug
Oder kommt es zu einer Trendwende und wir bekommen wirklich Filterverfahren welche abhängig vom Texturinhalt pro Sample (bzw pro Quad) den Filter so varieren das im Endergebniss die Abweichung ein vorher festgelegtes Mass (einstellbar im CP) nicht übersteigt? Mathematisch könnte man ja eine Menge tun, also Samples sparen ohne dass das Ergebnis (wesentlich) schlechter wird. Beim tri-AF wären meiner Schätzung nach insgesamt ca. 40% Füllrate zu gewinnen*. Andererseits glaube ich nicht, in absehbarer Zeit (NV60) solche TMUs zu sehen.
* Beim Tri-AF aus der 2. MIP nur jedes 2. Sample nehmen, und krumme Zwischenstufen zulassen (5x AF, 9x AF, ...) sowie ggf. durch unterschiedliche Samplegewichtung dem "echten" Kernel näher zu kommen, als mit vielen bi-Samples.
MMM, ATI hat bislang eine eigene Auffassung von Texturfilterung an den Tag gelegt: Gerade mal genau genug, dass die Artefakte in üblichen Spielen in üblichen Szenen nicht (sofort) ins Auge fallen. Wenn das weiter so geht, müssen Spiele-Entwickler bald darauf Rücksicht nehmen und darauf achten, nicht zu scharfe Texturen zu verwenden.
betasilie
2004-06-29, 18:10:56
Wirklich schwer zu sagen.
Texturfilter sind am Massenmarkt schlecht zu bewerben. AA ist da schon was anderes, weil es einfach plakativer beworben werden kann.
Ich würde daher eher auf Stillstand tippen. Schlechter darf es auf garkeinen Fall werden, besonders bei ATI ist so langsam die Grenze erreicht.
Irgendwann wird es sicherlich solche selektiven Texturfilter geben, mit Algorythmen, die wirklich Performnce sparen bei quasi perfekter IQ, nur wird das imho nicht beim NV50 oder R5xx der Fall sein.
Corrail
2004-06-29, 20:08:43
Original geschrieben von aths
Wenn das weiter so geht, müssen Spiele-Entwickler bald darauf Rücksicht nehmen und darauf achten, nicht zu scharfe Texturen zu verwenden.
... oder den Texturfilter selbst im Pixelshader schreiben ;)
robbitop
2004-06-30, 00:34:17
ist das nicht sowieso die Zukunft?
Zumindest nicht die nähere.
robbitop
2004-06-30, 01:51:31
ist das etwa nicht in WGF spezifiziert?
gab vor 2 Jahren mal Gerüchte für sowas in DX-Next
Man kann sicher den Texturfilter auch als Shadercode realisieren, aber spezialisierte Hardware kann das noch um Welten schneller. Wenn man für AF Branching verwenden müsste oder immer die maximale Sampleanzahl nehmen...
robbitop
2004-06-30, 02:04:05
hm ich hab mir das eigentlich anders vorgestellt.
Kann man nicht die Pixelshader ALUs dafür auslegen in Zukunft?
Original geschrieben von robbitop
hm ich hab mir das eigentlich anders vorgestellt.
Kann man nicht die Pixelshader ALUs dafür auslegen in Zukunft? Kann man. Man könnte auch TMUs auf FP32 aufbohren und die Recheneinheiten der PS-ALU zuschlagen. Macht man aber nicht, weil sich die TMU mit ihren auf Sampling beschränkten Rechnungen als TMU-Baugruppe kleiner (und schneller) kriegen lässt.
TMUs braucht man oft genug, das lohnt sich noch. Flexibel zuweisbare TMUs (ein TMU-Array) würde die Auslastung mehrerer Quadpipes auch steigern können, aber die Pipeline weiter strecken (da die Latenzen stiegen) und den Transistorcount steigen lassen. Bringt dann auch wieder Nachteile.
Demirug
2004-06-30, 20:23:42
Mhm wenn ich mir so den Programmcode für AF anschaue kann man da schön Shaderleistung verheizen. Das können die festeingebauten Verfahren wohl günstiger und das noch eine ganze Zeit lang
Corrail
2004-06-30, 20:37:15
Original geschrieben von Demirug
Mhm wenn ich mir so den Programmcode für AF anschaue kann man da schön Shaderleistung verheizen. Das können die festeingebauten Verfahren wohl günstiger und das noch eine ganze Zeit lang
Ja, das auf jeden Fall, aber bei diesen "fest-eingebauten Verfahren" hat man mittlerweile leider keine Garantie mehr...
Also Entwickler dieser Welt: Schreibt eure Textur-Filter im Shader selbst, dann überlegen es sich ATI und nVidia zwei mal ob sie weiter solche "Optimierungen" machen ;D
Tigerchen
2004-07-01, 06:59:47
Original geschrieben von Corrail
Ja, das auf jeden Fall, aber bei diesen "fest-eingebauten Verfahren" hat man mittlerweile leider keine Garantie mehr...
Also Entwickler dieser Welt: Schreibt eure Textur-Filter im Shader selbst, dann überlegen es sich ATI und nVidia zwei mal ob sie weiter solche "Optimierungen" machen ;D
Lustige Ideen hast du.
;D
][immy
2004-07-01, 07:11:40
dazu hätte ich mal ein paar fragen
der neuste S3 chip, kann ja direkt trilinear filtern.
wie hoch ist da die chance, das auch nvidia und ati solch ein technologie in ihre chips einbauen?
kann der S3 chip überhaupt noch bilinear filtern, oder filtert der immer gezwungenermaßen voll trilinear? (mag sein das ich da damals etwas nicht ganz verstanden hab)
also filtertricks find ich ansich sind eine tolle sache, aber sie müssen dennoch vom nutzer extra und einfach einschaltbar bzw abschaltbar sein. wenn der nutzer diese qualität- gegen geschwindigkeits-einstellungen selbst aktiviert, ist das ok, aber bei allem anderen wird dem nutzer etwas, das möglich ist vorenthalten (und wofür man ansich gezahlt hat, nämlich bildqualität)
robbitop
2004-07-01, 11:18:38
natürlich kann er bilinear filtern, aber wenn man bilinear ohne AF Filtert, ist es nicht langsamer als bi +2xAF oder Tri 1xAF. Zumindist in der Theorie.
Ich glaube kaum dass ATi/NV sowas einbauen. Dafür haben die einfach nicht genug Speicherbandbreite (gut S3 hat die auch nicht X-D) und ausserdem wären dann ihre ganzen Bi/Bri Optimierungen für die Tonne
MadManniMan
2004-07-01, 13:01:31
Original geschrieben von robbitop
natürlich kann er bilinear filtern, aber wenn man bilinear ohne AF Filtert, ist es nicht langsamer als bi +2xAF oder Tri 1xAF. Zumindist in der Theorie.
IIRC nicht ganz richtig.
Der DC hat 8*1TriPipes ... ergo 2.4GTex Bi und FastTri, jedoch nur noch 1.2GTex 2*BiAF, wenn denn alles wirklich mit 2*AF gesampelt würde, also die grundsätzliche Adaptivität von AF unberücksichtigt bleibt.
Demirug
2004-07-01, 13:09:20
Beim Deltachrome kommt ein Tri aus einer Mipmap Filter zum Einsatz. Dieser kann natürlich auch nur Bilinear Filtern. Genauso kann er in zwei Takten aus 2 Bilinearen Samples ein Trilineares erzeugen. Die Variante welche das aus einer Mipmap macht kann das in einem Takt. Das Verfahren ist aus der Sicht der Filterqualität nicht immer ganz unproblematisch.
Da dieser Filter aber kein 2xBIAF direkt unterstützt braucht man für 2xBIAF auch zwei Takte.
Original geschrieben von MadManniMan
IIRC nicht ganz richtig.
Der DC hat 8*1TriPipes ...
Nein, hat er eben nicht. Er hat Fast-Tri TMUs. Das ist ein Unterschied.
MadManniMan
2004-07-01, 13:44:23
Original geschrieben von Gast
Nein, hat er eben nicht. Er hat Fast-Tri TMUs. Das ist ein Unterschied.
Du hast recht, aber es macht für meine Betrachtung keinen Unterschied.
Fakt ist: die Pipes schaffen ein BiSample pro Takt, genau wie ein FastTriSample -> Bi macht gegenüber FastTri keinen theoretischen Füllratenunterschied.
robbitop
2004-07-01, 14:12:58
ist mir entfallen
sry
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.