Kleiner Texturkompressions-Benchmark
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Kleiner Texturkompressions-Benchmark
Hi,
Aus Interesse, ob man sich bei Texturen für ein komprimiertes Format, für transparente Kompression (NTFS) oder für ein unkomprimiertes Format entscheiden sollte, führe ich gerade eine kleine Untersuchung durch. Während ich noch messe und Zahlen sortiere, könnt ihr schonmal Kritik an meinen Methoden äußern:
Testobjekte: 3384 Texturen aus S.T.A.L.K.E.R. - Shadow of Chernobyl. (Ich wollte eigentlich Crysis benutzen, aber dafür reichte mein Platz nicht.) Die Gesamtgröße beträgt rund 4,22 GiB und alles wird abgedeckt: Normal-, Bump- und Detailmaps; GUI-Hintergründe und Buttons; Displacement- und Distortion-Maps für Special Effects; Übersichtskarten und sogar ein paar Dummy-Texturen und Überbleibsel aus der Entwicklungsphase – in Größen von 4² bis 2048². Die Texturen liegen alle in 32-Bit-RGBA vor (Kompression wurde entfernt, da es sonst unfair gegenüber Dateiformaten wäre, die die nicht unterstützen). HDR-Texturen benutzt das Spiel leider kaum (außer ein paar RGBEs), aber für den Datendurchsatz sollte das keine Rolle spielen. Der Windows-Dateicache dürfte bei solchen Datenmengen (ich habe nur 4 GiB RAM) nicht dazwischenfunken.
Testformate: Unkomprimiert (DDS), transparent komprimiert (DDS mit NTFS-Kompression), komprimiert (PNG auf mittlerer Kompressionsstufe, wie es AMDs Compressionator ausgegeben hat) und – aus Eigeninteresse – optimal komprimiert (PNG mit entfernten überflüssigen Farbkanälen, optimierten Filtern, aufgelösten Blöcken, optimiertem DEFLATE; die Optimierung hat ungefähr 15 Stunden gedauert). Ursprünglich wollte ich noch BMP testen, aber das wäre zu viel Aufwand mit zu wenig Nutzen gewesen – es hätte sich wahrscheinlich genau wie DDS verhalten, nur mit größerem CPU-Overhead zum vertauschen der Komponenten und Zeilen. Nebenbei teste ich auch ein eigenes Format, da das aber fast identisch mit DDS ist lasse ich es der Klarheit zuliebe weg.
Durchführung: Die Dateien werden in den Speicher eingeblendet; die Texturen werden alle in RGBA gelesen (das bedeutet, dass bei optimierten PNGs, deren überflüssige Alpha-Kanäle weggelassen wurden, diese auch wiederhergestellt werden müssen und geht mit der Tatsache konform, dass moderne GPUs nur Texturen mit Pixelgrößen von Zweierpotenzen verarbeiten). Dann werden alle Pixel in einem Zug ge-memcpy()-ed, um einen GPU-Upload zu simulieren (diesen tatsächlich durchzuführen war mir zu viel Arbeit). Die Zeit, die zum Parsen des Verzeichnisses draufgeht, wird nicht miteinbezogen. Der DDS-Loader wurde gestern selber zusammengepfrickelt (ich benutze normalerweise kein DDS) und erfüllt für diesen Bench seinen Zweck. Der PNG-Loader ist eine aktuelle libpng ohne Ballast (MNG-Support, exotische Chunks, progressives Laden, Programmierhilfen). Überflüssige Kanäle werden nicht nach dem Laden wieder eingefügt, sondern von libpng schon während des Entpackens. Kompiliert wurde mit meinen üblichen Optimierungen, LTCG und so.
Umgebung: Core 2 Quad mit 4 GiB RAM. Alle Dateien liegen auf einer eigenen Partition in optimaler, defragmentierter Anordnung. Die Systemauslastung ist einmal optimal (kein Virenscanner, keine anderen Programme, keine geplanten Tasks), dann mittelhoch (Virenscanner, Browser, 50 % CPU-Auslastung durch Full-HD-Film) und dann hoch (Virenscanner, Browser, 80 % CPU-Auslastung durch ein paar im RAM schuftende Kompressionsalgorithmen).
Ich werde die Ergebnisse nachtragen und bis dahin die Test gemäß eurem Feedback korrigieren; bis später.
Aus Interesse, ob man sich bei Texturen für ein komprimiertes Format, für transparente Kompression (NTFS) oder für ein unkomprimiertes Format entscheiden sollte, führe ich gerade eine kleine Untersuchung durch. Während ich noch messe und Zahlen sortiere, könnt ihr schonmal Kritik an meinen Methoden äußern:
Testobjekte: 3384 Texturen aus S.T.A.L.K.E.R. - Shadow of Chernobyl. (Ich wollte eigentlich Crysis benutzen, aber dafür reichte mein Platz nicht.) Die Gesamtgröße beträgt rund 4,22 GiB und alles wird abgedeckt: Normal-, Bump- und Detailmaps; GUI-Hintergründe und Buttons; Displacement- und Distortion-Maps für Special Effects; Übersichtskarten und sogar ein paar Dummy-Texturen und Überbleibsel aus der Entwicklungsphase – in Größen von 4² bis 2048². Die Texturen liegen alle in 32-Bit-RGBA vor (Kompression wurde entfernt, da es sonst unfair gegenüber Dateiformaten wäre, die die nicht unterstützen). HDR-Texturen benutzt das Spiel leider kaum (außer ein paar RGBEs), aber für den Datendurchsatz sollte das keine Rolle spielen. Der Windows-Dateicache dürfte bei solchen Datenmengen (ich habe nur 4 GiB RAM) nicht dazwischenfunken.
Testformate: Unkomprimiert (DDS), transparent komprimiert (DDS mit NTFS-Kompression), komprimiert (PNG auf mittlerer Kompressionsstufe, wie es AMDs Compressionator ausgegeben hat) und – aus Eigeninteresse – optimal komprimiert (PNG mit entfernten überflüssigen Farbkanälen, optimierten Filtern, aufgelösten Blöcken, optimiertem DEFLATE; die Optimierung hat ungefähr 15 Stunden gedauert). Ursprünglich wollte ich noch BMP testen, aber das wäre zu viel Aufwand mit zu wenig Nutzen gewesen – es hätte sich wahrscheinlich genau wie DDS verhalten, nur mit größerem CPU-Overhead zum vertauschen der Komponenten und Zeilen. Nebenbei teste ich auch ein eigenes Format, da das aber fast identisch mit DDS ist lasse ich es der Klarheit zuliebe weg.
Durchführung: Die Dateien werden in den Speicher eingeblendet; die Texturen werden alle in RGBA gelesen (das bedeutet, dass bei optimierten PNGs, deren überflüssige Alpha-Kanäle weggelassen wurden, diese auch wiederhergestellt werden müssen und geht mit der Tatsache konform, dass moderne GPUs nur Texturen mit Pixelgrößen von Zweierpotenzen verarbeiten). Dann werden alle Pixel in einem Zug ge-memcpy()-ed, um einen GPU-Upload zu simulieren (diesen tatsächlich durchzuführen war mir zu viel Arbeit). Die Zeit, die zum Parsen des Verzeichnisses draufgeht, wird nicht miteinbezogen. Der DDS-Loader wurde gestern selber zusammengepfrickelt (ich benutze normalerweise kein DDS) und erfüllt für diesen Bench seinen Zweck. Der PNG-Loader ist eine aktuelle libpng ohne Ballast (MNG-Support, exotische Chunks, progressives Laden, Programmierhilfen). Überflüssige Kanäle werden nicht nach dem Laden wieder eingefügt, sondern von libpng schon während des Entpackens. Kompiliert wurde mit meinen üblichen Optimierungen, LTCG und so.
Umgebung: Core 2 Quad mit 4 GiB RAM. Alle Dateien liegen auf einer eigenen Partition in optimaler, defragmentierter Anordnung. Die Systemauslastung ist einmal optimal (kein Virenscanner, keine anderen Programme, keine geplanten Tasks), dann mittelhoch (Virenscanner, Browser, 50 % CPU-Auslastung durch Full-HD-Film) und dann hoch (Virenscanner, Browser, 80 % CPU-Auslastung durch ein paar im RAM schuftende Kompressionsalgorithmen).
Ich werde die Ergebnisse nachtragen und bis dahin die Test gemäß eurem Feedback korrigieren; bis später.
-
- Moderator
- Beiträge: 2119
- Registriert: 25.02.2009, 13:37
Re: Kleiner Texturkompressions-Benchmark
wenn du eine nvidia karte hast benutz doch cuda und dessen memcpy um die dinger einmal aufs device zu schaufeln.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Nein, habe ich nicht.
Ich lasse die hohe Systemauslastung wohl auch weg; scheinbar kommen da die gleichen Werte raus wie bei mittlerer.
Ich lasse die hohe Systemauslastung wohl auch weg; scheinbar kommen da die gleichen Werte raus wie bei mittlerer.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Soooo, dann mal los. Damit, dass NTFS-Kompression die Ladezeit reduzieren würde, lag ich wohl falsch … aber es gibt noch eine andere Überraschung … erstmal ein Überblick über die Daten:
Rohe Größe als DDS: 4,224 GiB (4.535.742.528 B)
Tatsächliche Größe:
Die Ladezeiten unter optimalen Bedingungen (je vier Durchläufe):
Unter optimalen Bedingungen und verglichen mit DDS braucht NTFS-komprimiertes DDS also 1,2× so lange, um die 1,64× komprimierten Daten zu laden; PNG 1,61× so lange um die 2,86× komprimierten Daten zu laden und optimiertes PNG 1,05× so lange um die 3,65× komprimierten Daten zu laden.
Das ist noch kein Fazit, erst kommen noch die Benchmarks unter Last.
Rohe Größe als DDS: 4,224 GiB (4.535.742.528 B)
Tatsächliche Größe:
- DDS:
4,236 GiB (4.549.132.288 B; +13.389.760 B; +0,295 %) - DDS (NTFS-komprimiert):
2,571 GiB (2.761.110.016 B; -1.774.632.512 B; -39,125 %) - PNG
1,48 GiB (1.589.301.248 B; -2.946.441.280 B; -64,961 %) - PNG (optimiert)
1,158 GiB (1.243.406.336 B; -3.292.336.192 B; -72,586 %)
Die Ladezeiten unter optimalen Bedingungen (je vier Durchläufe):
- DDS:
67 s (67,0436 s; 67,7099 s; 67,1513 s; 66,2035 s)
Dateidurchsatz 64,75 MiB/s (Datendurchsatz 64,51 MiB/s); CPU-Auslastung < 10 % - DDS (NTFS-komprimiert):
80,5 s (80,3253 s; 81,049 s; 80,6028 s; 80,1627 s)
Dateidurchsatz 32,71 MiB/s (Datendurchsatz 54,73 MiB/s); CPU-Auslastung zwischen 10 und 30 % - PNG
108,2 s (108,787 s; 108,124 s; 107,897 s; 107,887 s)
Dateidurchsatz 14,01 MiB/s (Datendurchsatz 39,98 MiB/s); CPU-Auslastung 25 % - PNG (optimiert)
70,4 s (69,258 s; 70,5043 s; 70,2043 s; 71,466 s)
Dateidurchsatz 16,84 MiB/s (Datendurchsatz 61,44 MiB/s); CPU-Auslastung 25 %
Unter optimalen Bedingungen und verglichen mit DDS braucht NTFS-komprimiertes DDS also 1,2× so lange, um die 1,64× komprimierten Daten zu laden; PNG 1,61× so lange um die 2,86× komprimierten Daten zu laden und optimiertes PNG 1,05× so lange um die 3,65× komprimierten Daten zu laden.
Das ist noch kein Fazit, erst kommen noch die Benchmarks unter Last.
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Wie bereits geauessert, weitere Informationen ueber die Beschaffenheit der DEFLATEten PNGs waere hilfreich -- tendenziell wuerde ich vermuten dass die ganzen Datenstrukturen (Woerterbuch, etc.) im einen Fall in den L2er reinpassen, bei den normalen PNGs aber nicht mehr, was dann den enormen Laufzeitunterschied verursacht.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Die Ladezeiten unter 50 % CPU-Last (hier ist die Streuung größer, was aber unvermeidbar war – darum auch ohne CPU-Auslastung):
PNG-Kompression ist also stärker abhängig von CPU-Verfügbarkeit, als es NTFS-Kompression ist … ist unter’m Strich aber immernoch schneller als selbige, falls optimiert. Für pure Geschwindigkeit ist ein möglichst rohes Format optimal, aber PNG ist da auch nicht allzu weit hinter – jedenfalls, wenn man es richtig macht.
Setzt man Effizienz = Kompression ÷ Ladezeit mit DDS = 1, ergibt sich (unter Last): NTFS-komprimiertes DDS = 1,37 (1,3); PNG = 1,78 (1,64); optimiertes PNG = 3,48 (3,04). Diese Zahlen sind natürlich mit Vorsicht zu genießen – eine Verlängerung der Ladezeit von 15 auf 25 Sekunden, nur, um 60 % Speicherplatz zu sparen, dürfte in der heutigen, speicherbilligen Welt keinem User gefallen. Für das Laden im Hintergrund auf einem Mehrkerner mit begrenzter I-/O-Performance sieht die Sache aber wieder anders aus.
Und am Ende sind all die Benchmarks umsonst, weil Superfetch das Spiel eh in den RAM lädt bevor der User es startet und DDS dann, egal ob komprimiert oder nicht, eine Ladezeit gegen Null hat während PNG immernoch aufwendig entpackt werden muss.
Ich für meinen Teil werde aus garnichts schlau und benche jetzt ein wenig mit gecacheten PNGs, um zu schauen, ob ich ein wenig Licht in dieses Mysterium bringen kann.
- DDS:
77,2 s (75,3723 s; 81,6218 s; 77,7638 s; 74,0935 s)
Dateidurchsatz 56,2 MiB (Datendurchsatz 56,03 MiB) - DDS (NTFS-komprimiert):
98,02 s (96,6816 s; 98,8766 s; 100,024 s; 96,5269 s)
Dateidurchsatz 26,86 MiB (Datendurchsatz 44,13 MiB) - PNG:
134,59 s (137,007 s; 132,39 s; 133,567 s; 135,385 s)
Dateidurchsatz 11,26 MiB (Datendurchsatz 32,14 MiB) - PNG (optimiert):
92,27 s (92,0059 s; 91,9635 s; 92,6317 s; 92,4919 s)
Dateidurchsatz 12,85 MiB (Datendurchsatz 46,88 MiB)
PNG-Kompression ist also stärker abhängig von CPU-Verfügbarkeit, als es NTFS-Kompression ist … ist unter’m Strich aber immernoch schneller als selbige, falls optimiert. Für pure Geschwindigkeit ist ein möglichst rohes Format optimal, aber PNG ist da auch nicht allzu weit hinter – jedenfalls, wenn man es richtig macht.
Setzt man Effizienz = Kompression ÷ Ladezeit mit DDS = 1, ergibt sich (unter Last): NTFS-komprimiertes DDS = 1,37 (1,3); PNG = 1,78 (1,64); optimiertes PNG = 3,48 (3,04). Diese Zahlen sind natürlich mit Vorsicht zu genießen – eine Verlängerung der Ladezeit von 15 auf 25 Sekunden, nur, um 60 % Speicherplatz zu sparen, dürfte in der heutigen, speicherbilligen Welt keinem User gefallen. Für das Laden im Hintergrund auf einem Mehrkerner mit begrenzter I-/O-Performance sieht die Sache aber wieder anders aus.
Und am Ende sind all die Benchmarks umsonst, weil Superfetch das Spiel eh in den RAM lädt bevor der User es startet und DDS dann, egal ob komprimiert oder nicht, eine Ladezeit gegen Null hat während PNG immernoch aufwendig entpackt werden muss.
Ich für meinen Teil werde aus garnichts schlau und benche jetzt ein wenig mit gecacheten PNGs, um zu schauen, ob ich ein wenig Licht in dieses Mysterium bringen kann.
-
- Moderator
- Beiträge: 2119
- Registriert: 25.02.2009, 13:37
Re: Kleiner Texturkompressions-Benchmark
Naja, man könnte auch Argumentieren, dass mit dem Aufkommen von solid states Speicher wieder teurer, Ladezeiten dagegen aber enorm viel billiger werden. Nur so als Idee.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Da das Entpacken CPU-limitiert ist, würde ich mit dem Gegenteil argumentieren: Wenn man herkömmliche HDDs mit unkomprimierten Texturen benutzt, ist das nicht nur geringfügig schneller, sondern auch bedeutend günstiger als das Laden von SSDs :) Wenn wir uns auf einen pro-GiB- und pro-Ghz-Preis einigen, können wir ja ausrechnen, welche Möglichkeit am schonendsten für den Geldbeutel ist.
-
- Moderator
- Beiträge: 2119
- Registriert: 25.02.2009, 13:37
Re: Kleiner Texturkompressions-Benchmark
Näherungsweise würde mich interessieren ob es was vergleichbares zu Moores Law bezüglich Festplattenkapazität gibt.
EDIT: Wiki sagt ja.
EDIT: Wiki sagt ja.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Kleines Update zu den PNGs:
— Ich hatte mal vermutet, dass die geringere Performance der Default-PNGs daran liegt, dass die Bilder blockweise komprimiert und gespeichert werden (das Wörterbuch also alle 8192 B wechselt, viele Implementierungen folgen diesem Muster). Dem ist aber nicht so; die Bilder sind in einem Rutsch gespeichert.
— Die Ladezeit der optimierten PNGs bleibt scheinbar identisch, wenn alle Dateien aus dem RAM gelesen werden statt von der Festplatte … ich habe aber momentan nicht die Zeit, einen Test unter optimalen Bedingungen durchzuführen; auch daran könnte das liegen.
— Ich hatte mal vermutet, dass die geringere Performance der Default-PNGs daran liegt, dass die Bilder blockweise komprimiert und gespeichert werden (das Wörterbuch also alle 8192 B wechselt, viele Implementierungen folgen diesem Muster). Dem ist aber nicht so; die Bilder sind in einem Rutsch gespeichert.
— Die Ladezeit der optimierten PNGs bleibt scheinbar identisch, wenn alle Dateien aus dem RAM gelesen werden statt von der Festplatte … ich habe aber momentan nicht die Zeit, einen Test unter optimalen Bedingungen durchzuführen; auch daran könnte das liegen.
- Schrompf
- Moderator
- Beiträge: 4878
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Hm. Nach meinem Wissen sind DXT-komprimierte Texturen der Standard. Die hast Du aber leider komplett ausgelassen. Für die würde ich dann nämlich sowas wie 1.0GB und 15s vermuten. Ich weiß, dass Du die verlustbehaftete Kompression nicht magst, aber ich betrachte die eigentlich als absolut unverzichtbar.
[edit] Es gibt Spiele, die die DDS-Kompression (je nach Konfig) zur Laufzeit machen und für die höchste Detailstufe komplett weglassen. Das läge dann wahrscheinlich bei 200s-300s und ebenso 1.5GB Speicherbedarf - man gewinnt halt Flexibilität, auch wenn den Unterschied keiner merkt :-)
[edit] Es gibt Spiele, die die DDS-Kompression (je nach Konfig) zur Laufzeit machen und für die höchste Detailstufe komplett weglassen. Das läge dann wahrscheinlich bei 200s-300s und ebenso 1.5GB Speicherbedarf - man gewinnt halt Flexibilität, auch wenn den Unterschied keiner merkt :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Dass Block-Compressed-Textures das Nonplusultra sind wollte ich direkt im Intro schreiben – dann hat Alexander es mir aber schon in dem anderen Thread entlockt und ich habe es irgendwie vergessen :)Schrompf hat geschrieben:Hm. Nach meinem Wissen sind DXT-komprimierte Texturen der Standard. Die hast Du aber leider komplett ausgelassen. Für die würde ich dann nämlich sowas wie 1.0GB und 15s vermuten.
Unbrauchbar ist der Benchmark für BCs nicht – du kannst daraus ja immernoch ablesen, was es kosten würde, BCs mit NTFS-Kompression zu versehen. Wenn du die PNGs weglässt, brauchst du im Grunde nur die Größe durch 16 zu dividieren (oder die Texturanzahl mit 16 multiplizieren) und hast einen Benchmark für komprimierte Texturen.
Meinst du die DXT-Kompression? In dem Fall sind mir nur Spiele bekannt, die das beim ersten Laden tun. Auch gibt es ab D3D10.1 BC-Rendertargets – d.h. man lädt die Texturen wie gehabt von der Platte und lässt sie die GPU nach DXT konvertieren. Wenn man den unkomprimierten Ansatz wählt, also beim Laden quasi die volle CPU-Leistung zur Verfügung hat, dürfte das kaum langsamer sein als normales Laden … was ich auch benchen wollte war, ob die Mip-Map-Erzeugung auf der GPU die 33 % gesparte Festplattenbandbreite aufhebt. Aber der Bench hat mich so, wie er ist, schon zwei Tage gekostet und ich kann jetzt keine Zahlen mehr sehen ^^Schrompf hat geschrieben:[edit] Es gibt Spiele, die die DDS-Kompression (je nach Konfig) zur Laufzeit machen und für die höchste Detailstufe komplett weglassen. Das läge dann wahrscheinlich bei 200s-300s und ebenso 1.5GB Speicherbedarf - man gewinnt halt Flexibilität, auch wenn den Unterschied keiner merkt :-)
- Lord Delvin
- Establishment
- Beiträge: 583
- Registriert: 05.07.2003, 11:17
Re: Kleiner Texturkompressions-Benchmark
Ich hab noch nie verstanden, warum es Leute gibt die alle potenziell interessanten Texturen gleich am Anfang laden. Ich mein schau dir deine Daten doch mal an: Wenn du nur die relevanten Texturen im Hintergrund nachlädst dann is es doch total egal, in welchem Format die abgelegt sind; dann zählt eigentlich nurnoch der Plattenplatz. Und wenn ich mir n Spiel(oder Patches davon) übers Netz runterlad, dann isses ziemlich ärgerlich, wenn ich 3x so lange laden muss. Also würd ich ma sagen Ladezeit ist total egal, alles was zählt ist Kompression.
EDIT: Müsste das nicht sogar noch effizienter werden, wenn du die PNGs in nen simplen container reinlegst? Dann würde sich das Blockalignment auf Dateisystemebene nich mehr auswirken.
EDIT: Müsste das nicht sogar noch effizienter werden, wenn du die PNGs in nen simplen container reinlegst? Dann würde sich das Blockalignment auf Dateisystemebene nich mehr auswirken.
Re: Kleiner Texturkompressions-Benchmark
Naaaaajaaaaaaaa!!!!!! Also ersteres ist natürlich richtig... aus dem Netz laden sollte es so schnell wie möglich sein -> folglich sollten die Texturen auch so klein wie möglich sein. Aber die Ladezeit gutheißen, ich schockiert!!! Runtergeladen wird der Patch meißt nur einmal, aber die Anwendung starten, dass passiert doch um einiges häufiger. Und meine Zeit ist mir doch zu kostbar, um sie mit warten zu verschwenden. Für mich sind Ladezeiten > 1 Sekunde absolut inaktzeptabel... besser wäre natürlich auf 0 zu kommen, aber ich sehe ein, dass das wohl vorerst nicht möglich sein wird.Lord Delvin hat geschrieben:Und wenn ich mir n Spiel(oder Patches davon) übers Netz runterlad, dann isses ziemlich ärgerlich, wenn ich 3x so lange laden muss. Also würd ich ma sagen Ladezeit ist total egal, alles was zählt ist Kompression.
Hier sieht man meine Bestrebungen, die Ladezeiten in der Engine so klein wie möglich zu halten... ich bin dabei allerdings noch nicht so erfolgreich, die Ladezeit wirklich unter eine Sekunde zu drücken, wie man sieht. Es werden auch nur Aktionen in der Konsole dargestellt, die länger als 2 ms brauchen.
Wichtig ist dabei, nur das zu laden, was man am Anfang wirklich braucht, der Rest kann dann im Hintergrund (was bei mir noch nicht passiert) in den nächsten Sekunden nachgeladen werden.
Um beide Ziele, also kleine Gesamtgröße und schnelle Ladezeit zu realisieren, habe ich vor, den Content prozedural zu erzeugen und dann bei der Installation oder da, wo es halt aktzeptabel wäre, das ganze so zu speichern, dass es am schnellsten abrufbar ist.
Wobei ich aber sagen muss, dass ich mir die Aussage von Alexander Kornrumpf mit seiner kleinen Festplatte zu Herzen nehme. Wenn einfach kaum Speicher da ist, kann ich verstehen, wenn man lieber alles komprimiert oder zumindest nicht verschwenderisch mit dem Speicher umgeht. Deswegen werde ich wohl die Möglichkeit bereithalten, dass man selbst wählen kann, ob man lieber kurze Ladezeiten oder kleine Dateigröße bevorzugt.
Gruß
Zudo
-
- Moderator
- Beiträge: 2119
- Registriert: 25.02.2009, 13:37
Re: Kleiner Texturkompressions-Benchmark
Freut mich, obwohl diese Option sich wohl nicht rechnen wird, wenn ich der einzige Betroffene bin. :)Wobei ich aber sagen muss, dass ich mir die Aussage von Alexander Kornrumpf mit seiner kleinen Festplatte zu Herzen nehme. Wenn einfach kaum Speicher da ist, kann ich verstehen, wenn man lieber alles komprimiert oder zumindest nicht verschwenderisch mit dem Speicher umgeht. Deswegen werde ich wohl die Möglichkeit bereithalten, dass man selbst wählen kann, ob man lieber kurze Ladezeiten oder kleine Dateigröße bevorzugt.
Re: Kleiner Texturkompressions-Benchmark
Nein, ich leide auch unter chronischer Speicherplatzarmut ;)
Darum an Krishty: Ich weiß, dass du Zahlen nicht mehr sehen kannst, aber … würde eine Testreihe mit PNG (optimiert + NTFS-komprimiert) noch etwas bringen? :D
Darum an Krishty: Ich weiß, dass du Zahlen nicht mehr sehen kannst, aber … würde eine Testreihe mit PNG (optimiert + NTFS-komprimiert) noch etwas bringen? :D
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Tu doch nicht, als hättest du die Ertgebnisse des Benchs voraussagen können. Außerdem spielt da noch mehr rein – da PNG CPU-limitiert ist, ist es z,B. furchtbar ineffizient für im-Hintergrund-laden, wenn die Anwendung ebenfalls CPU-limitiert ist. Außerdem hat das Optimieren der PNGs 15 Stunden gedauert … viel Spaß, wenn du das in deine Content-Pipeline miteinbeziehst. Und schlussendlich wei0t du nicht, ob Superfetch nicht dein ganzes Program-Folder schon in den RAM geladen hat wenn du das Spiel startest, wobei DDS PNG um den Faktor 100 abhängt.Lord Delvin hat geschrieben:Ich hab noch nie verstanden, warum es Leute gibt die alle potenziell interessanten Texturen gleich am Anfang laden. Ich mein schau dir deine Daten doch mal an: Wenn du nur die relevanten Texturen im Hintergrund nachlädst dann is es doch total egal, in welchem Format die abgelegt sind; dann zählt eigentlich nurnoch der Plattenplatz.
Ich bin auch kein alles-am-Anfgang-lader … ich bin nur ein sehr sher verwirrter Mensch der die Performance seiner ideen benchen wollte, statt sie erst umzusetzen und dann zu mutmaßen. Ich habe mich atm noch für nichts entschieden und keinen Plan, was ich tun soll.
Bei der Distribution können optimierte PNGs bedeutend mehr Platz verbrauchten als DDS’s (weil Kompressionsalgorithmen ihren Input möglichst „breit“, also nicht vorgekaut) – und die Umstände, unter denen sich PNGs mit Gewissheit besser komprimieren lassen (wofür ich Tools geschrieben habe) erfordern ein Re-coding, das beim End-User Stunden in Anspruch nehmen würde. Solange also niemand so blöd ist, sein Spiel nicht zu zippen bevor er es zum Download stellt, tun sich DDS und PNG nur im einstelligen Prozentbereich was.Lord Delvin hat geschrieben:Und wenn ich mir n Spiel(oder Patches davon) übers Netz runterlad, dann isses ziemlich ärgerlich, wenn ich 3x so lange laden muss. Also würd ich ma sagen Ladezeit ist total egal, alles was zählt ist Kompression.
Die Festplatte wirkt sich nicht auf die Ladezeit aus; selbst aus dem RAM lädt es genauso schnell bzw. irgendwie noch langsamaer :(Lord Delvin hat geschrieben:EDIT: Müsste das nicht sogar noch effizienter werden, wenn du die PNGs in nen simplen container reinlegst? Dann würde sich das Blockalignment auf Dateisystemebene nich mehr auswirken.
Kein Vorwurf — aber kann es sein, dass du viel zu früh auf SSD umgestiegen bist, und wir jetzt schuld sind, dass du chronisch knapp bei Speicherplatz bist? Also nicht in dem 5-TB-reichen-nicht-nehr-für-meine-HD-FIlm-Sammlung-Sinn wie ich, sondern im ich-kriege-nicht-mehr-als-zwei-games-auf-meine-64-GiB-systemplatte-und-die-laden-auch-nicht-schneller-Sinn?Alexander Kornrumpf hat geschrieben:Freut mich, obwohl diese Option sich wohl nicht rechnen wird, wenn ich der einzige Betroffene bin. :)
Optimierte PNGs lassen sich nicht weiter komprimieren – du kannst also dne Geschwindigkeitsverlust von NTFS-Kompression auf die Ladezeit der optimierten PNGs addieren, due Größe beibehalten und hast die Testreihe. NTFS-Kompression ist auf allem, was vorgekaut ist (PNG genau wie MP3 oder idverse Videoformate) herrlich kontraproduktiv.eXile hat geschrieben:Ich weiß, dass du Zahlen nicht mehr sehen kannst, aber … würde eine Testreihe mit PNG (optimiert + NTFS-komprimiert) noch etwas bringen? :D
Achja; kommt ihr auch nicht mehr in ICQ?
Re: Kleiner Texturkompressions-Benchmark
Hm, ich muss sagen an die Sache mit den Dateinamen hatte ich noch garnicht gedacht, ist eigentlich ne gute idee, einiges dort reinzupacken...
Aber ich denke schon, dass es sinn macht, auch z.B. png zu unterstützen, sodass man später nach Bedarf switchen kann.
Aber ich denke schon, dass es sinn macht, auch z.B. png zu unterstützen, sodass man später nach Bedarf switchen kann.
-
- Moderator
- Beiträge: 2119
- Registriert: 25.02.2009, 13:37
Re: Kleiner Texturkompressions-Benchmark
No offense taken, aber es stimmt überhaupt nicht. Ich habe eine hekömmliche Festplatte, die jedoch nicht annähernd an der Terabyte Grenze kratzt. Meine Filme lagere ich im Schrank auf der jeweiligen DVD auf der sie erworben wurden (wobei der Schrank auch chronisch zu klein ist, vielleicht bin ich zu früh auf Solid State Schränke umgestiegen :D ) HD Technologie besitze ich nicht.Kein Vorwurf — aber kann es sein, dass du viel zu früh auf SSD umgestiegen bist, und wir jetzt schuld sind, dass du chronisch knapp bei Speicherplatz bist? Also nicht in dem 5-TB-reichen-nicht-nehr-für-meine-HD-FIlm-Sammlung-Sinn wie ich, sondern im ich-kriege-nicht-mehr-als-zwei-games-auf-meine-64-GiB-systemplatte-und-die-laden-auch-nicht-schneller-Sinn?
P.S. Was richtig viel Platz verbraucht sind übrigens Schallplatten. Aber das nur am Rande.
- Krishty
- Establishment
- Beiträge: 8267
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Jaja, also (schmeißen wir hier die Threads durcheinander?): Ich würde Header-lose dateien als erste Wahl benutzen, und wenn der Textur-Manajah sie nicht findet, würde er nach einem gleichnamigen DDS/PNG/BMP suchen. Die meisten Games brauchen sowas ja sowieso für ihre Mods.NytroX hat geschrieben:Hm, ich muss sagen an die Sache mit den Dateinamen hatte ich noch garnicht gedacht, ist eigentlich ne gute idee, einiges dort reinzupacken...
Aber ich denke schon, dass es sinn macht, auch z.B. png zu unterstützen, sodass man später nach Bedarf switchen kann.
Hach, das kenne ich. Bin mal gepapnnt, für wie wenig ich die Wagenladungen DVDs in ein paar Jahren loswerde.Alexander Kornrumpf hat geschrieben:Meine Filme lagere ich im Schrank auf der jeweiligen DVD auf der sie erworben wurden (wobei der Schrank auch chronisch zu klein ist, vielleicht bin ich zu früh auf Solid State Schränke umgestiegen :D )
- Lynxeye
- Establishment
- Beiträge: 145
- Registriert: 27.02.2009, 16:50
- Echter Name: Lucas
- Wohnort: Hildesheim
- Kontaktdaten:
Re: Kleiner Texturkompressions-Benchmark
Der Trend geht doch immer weiter zu Multicore CPUs, die bisher in Spielen sowieso nicht vernünftig ausgelastet werden können. Selbst mit Rendermultithreading und eigenen Threads für Physik und andere Spielereien kommen wir momentan viel zu selten an das wirkliche physikalische Limit der heutigen CPUs. Ich hätte also kein Problem mit einem Thread der immer im Hintergrund mitläuft und die aktuell benötigten Texturen von der Festplatte lädt und dekomprimiert. Ich bin also ganz offen für möglichst gute Kompression der Daten auf dem Datenträger und mehr CPU Leistungsverbrauch.
- Chromanoid
- Moderator
- Beiträge: 4262
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Kleiner Texturkompressions-Benchmark
Mittel- bis Langfristig sollte man sich sowieso eher Gedanken darüber machen, wie man überhaupt die ganzen Texturen erstellen soll, die dann in höchster Auflösung die virtuellen Welten schmücken. Speicherplatzverbrauch und Verarbeitungsgeschwindigkeit sind zeitlich gesehen IMO eher irrelevante Maße. Aber für jetzt und gleich natürlich nicht :D also viel Spaß weiterhin ;).