Archiv verlassen und diese Seite im Standarddesign anzeigen : Framebuffer- und Texturkomprimierung vs. Bildqualität
Die neue Pascal GPU Generation bietet eine deutliche Steigerung der Speicherbandbreite durch Texturkompression.
Es werden größere Anteile der Texturen komprimiert, wie die beiden pinken Bilder zeigen.
Leider ist die Kompression (bis 8:1) normalerweise auch mit einem Qualitätsverlust verbunden.
1.Ist ein Qualitätsvelust sichtbar bzw. wie stark ist der Qualitätsverlust sichtbar?
2.Ist es möglich für maximale Qualität die Kompression auch auszuschalten bzw. zu regeln?
Tesseract
2016-05-30, 22:32:49
du vermischt da was. die kompressionstechniken um bandbreite zu sparen sind lossless und bringen im schnitt X% einsparung die je nach content aber nicht garantiert werden können. texturkompressionsformate hingegen sind etwas, das der developer explizit verwenden muss. die sind zwar lossy, qualitativ unterm strich aber trotzdem deutlich besser als unkomprimiert weil sie bei gleichem speicherverbrauch deutlich höher aufgelöst sein können.
Foobar2001
2016-05-30, 22:38:31
Die Speicher-Bandbreiten-Kompression ist bitidentisch, da gibt es ueberhaupt keinen Unterschied.
Textur-Kompression ist wie Tesseract sagt etwas anderes. Die Formate vor DX11 waren ziemlich uebel (DXT1, DXT5, etc.). BC6H/BC7/ASTC sind ziemlich anstaendig und man erkennt eigentlich keinen Unterschied.
ah, ok.
Bei den hohen genannten TexturMemorykompressionsraten von 4:1 und 8:1 dachte ich, die können eigentlich kaum verlustfrei sein. :freak:
OBrian
2016-05-30, 23:10:54
Ist ja immer "bis zu". Stell Dir als Vergleich sowas wie Bitmap zu PNG vor, bei einem Bild nur aus drei Strichen und großen einfarbigen Flächen ist die Kompression extrem stark (aus 3 MB können 10 kB oder so werden), bei einem Foto, wo keine zwei Pixel nebeneinander die gleiche Farbe haben, ist ein PNG kaum kleiner. So ähnlich ist das bei diesen Bandbreiten-Spar-Kompressionen auch, eigentlich unvorhersehbar, wie stark komprimiert wird. Nur weil man ja weiß, was üblicherweise an Material kommt, kann man halbwegs brauchbare Durchschnittswerte angeben - oder eben weniger brauchbare Extremwerte, wenn dem Marketing das opportun erscheint.
Ist ja immer "bis zu". Stell Dir als Vergleich sowas wie Bitmap zu PNG vor, bei einem Bild nur aus drei Strichen und großen einfarbigen Flächen ist die Kompression extrem stark (aus 3 MB können 10 kB oder so werden), bei einem Foto, wo keine zwei Pixel nebeneinander die gleiche Farbe haben, ist ein PNG kaum kleiner. So ähnlich ist das bei diesen Bandbreiten-Spar-Kompressionen auch, eigentlich unvorhersehbar, wie stark komprimiert wird. Nur weil man ja weiß, was üblicherweise an Material kommt, kann man halbwegs brauchbare Durchschnittswerte angeben - oder eben weniger brauchbare Extremwerte, wenn dem Marketing das opportun erscheint.
Hofft man jedenfalls, daß es noch so ist.:wink:
Die neue Pascal GPU Generation bietet eine deutliche Steigerung der Speicherbandbreite durch Texturkompression.
Es werden größere Anteile der Texturen komprimiert, wie die beiden pinken Bilder zeigen.
Leider ist die Kompression (bis 8:1) normalerweise auch mit einem Qualitätsverlust verbunden.
1.Ist ein Qualitätsvelust sichtbar bzw. wie stark ist der Qualitätsverlust sichtbar?
2.Ist es möglich für maximale Qualität die Kompression auch auszuschalten bzw. zu regeln?
Ich habe mir erlaubt, den Threadtitel zu ändern da es sich abgesehen vom Bild ganz rechts nicht um Texturkomrimierung handelt, sondern darum, Framebuffer-Inhalte zur Übertragung zu komprimieren.
Dabei wird im Gegensatz zur Texturkomprimierung kein Speicher gespart, da der Framebuffer weiterhin linear adressierbar bleiben muss. Beim Zugriff auf den Framebuffer versucht der Controller, den Inhalt verlustfrei zu komprimieren. Gelingt dies nicht, wird unkomprimiert übertragen. Die Komprimierung muss sehr schnell gehen und kann daher nicht besonders intelligent sein. Sie ist verlustfrei, aber erzielt eben keine besonders gute Komprimierungrate – und oft genug kann gar nicht komprimiert werden.
Bei Texturkomprimierung liegt der Fall anders, da man ja tatsächlich Platz im Grafikkartenspeicher spart. Hier wird mit fester Bitrate gearbeitet und die Komprimierung ist verlustbehaftet. Das heißt, eine komprimierte Textur ist Texel für Texel schlechter, man verliert Farbgenauigkeit. In Doom 3 (Standard-Edition, nicht BFG-Edition) kann man die unkomprimierten Originaltexturen nutzen, was besser aussieht. Allerdings ist das nur eine Seite der Medaille.
Wenn man einen vorgegebenen Platz für Texturen hat, lohnt es sich eigentlich immer, mit hochwertigen Verfahren komprimierte Texturen zu verwenden: Durch den gesparten Platz kann man Texturen in höherer Auflösung mitliefern. Selbst wenn die Texturen nicht in höherer Auflösung vorliegen: Heutige Komprimierungsverfahren erlauben, mit geringem Qualitätsverlust zu arbeiten aber die Grafikkarte kann schneller auf Texturinhalte zugreifen und bringt mehr Bilder pro Sekunden.
Zum Thema ausschalten: Sofern der Entwickler nicht die unkomprimierten Texturen mitliefert, kann man die Komprimierung nicht abschalten. Framebuffer-Speicherübertragungs-Komprimierung braucht man nicht abschalten, da kein Qualitätsverlust vorliegt. Das kann man sich auch nicht leisten, da heutige 3D-Engines oft Zwischenergebnisse schreiben und diese später weiterverwenden. Gäbe es dabei Qualitätsverlust, hätte das schwer vorhersehbare Auswirkungen auf die Grafik.
Pascal vs. Maxwell: Bereits Maxwell beherrscht 2:1-, 4:1- und 8:1-Komprimierung. Offenkundig hat Nvidia für Pascal die Algorithmen verbessert, so dass es häufiger als bisher möglich ist, dass eines der Verfahren verlustfrei arbeitet. Maxwell schaut im Wesentlichen, ob sich ein Framebuffer-Teil verlustfrei in geringerer Auflösung übertragen lässt. Pascal schaut gleichzeitig, ob vielleicht einige dieser gröber aufgelösten Pixel dieselbe Farbe haben und kann damit noch was sparen.
Ätznatron
2016-05-31, 08:29:49
Irgendwie muss ja berechnet werden, welches Verfahren zu einem gegebenen Zeitpunkt verwendet wird.
Das müsste doch Prozessorzeit kosten, fällt dieser Zeitverlust nicht ins Gewicht oder funktioniert das auf völlig andere Weise?
Godmode
2016-05-31, 08:43:37
Dabei wird im Gegensatz zur Texturkomprimierung kein Speicher gespart, da der Framebuffer weiterhin linear adressierbar bleiben muss. Beim Zugriff auf den Framebuffer versucht der Controller, den Inhalt verlustfrei zu komprimieren. Gelingt dies nicht, wird unkomprimiert übertragen. Die Komprimierung muss sehr schnell gehen und kann daher nicht besonders intelligent sein. Sie ist verlustfrei, aber erzielt eben keine besonders gute Komprimierungrate – und oft genug kann gar nicht komprimiert werden.
Bist du dir sicher, dass kein Speicher gespart wird? Ich ging immer davon aus, dass der Treiber die Textur verlustfrei komprimiert im Grafikspeicher ablegt. Die Entpackung findet dann in der GPU statt. Oder wie soll man den Bandbreite einsparen, wenn die Textur nicht komprimiert im Speicher liegt?
Irgendwie muss ja berechnet werden, welches Verfahren zu einem gegebenen Zeitpunkt verwendet wird.
Das müsste doch Prozessorzeit kosten, fällt dieser Zeitverlust nicht ins Gewicht oder funktioniert das auf völlig andere Weise?
Das Entpacken wird wohl in der Hardware und nicht über die Software laufen.
Ätznatron
2016-05-31, 08:47:58
Bist du dir sicher, dass kein Speicher gespart wird? Ich ging immer davon aus, dass der Treiber die Textur verlustfrei komprimiert im Grafikspeicher ablegt. Die Entpackung findet dann in der GPU statt. Oder wie soll man den Bandbreite einsparen, wenn die Textur nicht komprimiert im Speicher liegt?
Das Entpacken wird wohl in der Hardware und nicht über die Software laufen.
Das schon, aber es muss doch eine Entscheidung getroffen werden: Der Teil wird jetzt komprimiert, der andere nicht, und so weiter...
Maxwell schaut im Wesentlichen, ob sich ein Framebuffer-Teil verlustfrei in geringerer Auflösung übertragen lässt. Pascal schaut gleichzeitig, ob vielleicht einige dieser gröber aufgelösten Pixel dieselbe Farbe haben und kann damit noch was sparen.
Bist du dir sicher, dass kein Speicher gespart wird? Ich ging immer davon aus, dass der Treiber die Textur verlustfrei komprimiert im Grafikspeicher ablegt. Die Entpackung findet dann in der GPU statt. Oder wie soll man den Bandbreite einsparen, wenn die Textur nicht komprimiert im Speicher liegt?Die Texturen sparen bei Komprimierung Speicher. Der komprimierte Framebuffer spart keinen Speicher.
Irgendwie muss ja berechnet werden, welches Verfahren zu einem gegebenen Zeitpunkt verwendet wird.
Das müsste doch Prozessorzeit kosten, fällt dieser Zeitverlust nicht ins Gewicht oder funktioniert das auf völlig andere Weise?Wie es gelöst ist, weiß ich nicht. Da ohnehin über einige Takte lang gelesen oder geschrieben wird, hat man aber einige Takte Zeit, schon mal den nächsten Zugriff vorzubereiten. Man könnte die Framebuffer-Kachel gleichzeitig durch alle drei Algorithmen jagen und den am stärksten komprimierten nehmen, der noch ein valides Ergebnis liefert. Die wesentlichen Berechnungen sind Subtraktionen, also nicht besonders teuer.
Nighthawk13
2016-05-31, 11:49:17
Erläuterung, wie man programmieren muss, damit die Framebuffer-Kompression gut funktioniert:
http://gpuopen.com/dcc-overview/
(gefunden hier: http://gpuopen.com/slides-from-our-the-most-common-vulkan-mistakes-talk/)
(...) the introduction of Delta Color Compression — or DCC for short. This is a domain-specific compression that tries to take advantage of this data coherence to reduce the required bandwidth. It’s lossless, in many ways similar to typical compressors but adapted for 3D rendering. The key idea is to process whole blocks instead of individual pixels. Inside a block, only one value is stored with full precision, and the rest is stored as a delta – hence the name. If the colors are similar, the delta values can use a lot fewer bits relative to the input.
Edit: Kommentar ist noch interessant:
Compression is exclusive to the ROPs. Some drivers may implement a copy on the graphics queue using the ROPs to write, but apps can do that explicitly to be sure. Technically a CS could be used to address and encode, but it wouldn’t be easy.
Die ROPs komprimieren beim Schreiben, d.h. die Shadercores haben keine Arbeit damit.
High-Level wird etwas in der Art laufen:
Beim Schreiben:
1.) Es gibt ein Metastruktur für die Surface, die angibt, ob eine Kachel(sowas wie 8x8 Pixel) verlustfrei komprimiert werden kann (1 Bit je Kachel)
2.) Bei Rendern puffert die ROP alle Pixel, bis die Kachel voll beschrieben ist
3.) Beim Rausschreiben wird testweise versucht die Kachel zu komprimieren(dedizierte HW in den ROPs), und das Bit gesetzt(Kompression möglich: ja/nein)
4.) Entweder werden in den Speicherbreich der Kachel die komprimierten oder unkomprimierten Daten geschrieben (->evtl. gesparte Bandbreite)
Beim Auslesen:
Die Texunits überprüfen beim Sampling in einer Kachel das Kompression-Bit, und kopieren oder dekomprimieren die Kachel in den Textur-Cache (->evtl. gesparte Bandbreite)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.