Kleiner Texturkompressions-Benchmark

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Antworten
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Alexander Kornrumpf »

wenn du eine nvidia karte hast benutz doch cuda und dessen memcpy um die dinger einmal aufs device zu schaufeln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

Nein, habe ich nicht.

Ich lasse die hohe Systemauslastung wohl auch weg; scheinbar kommen da die gleichen Werte raus wie bei mittlerer.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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:
  • 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 %)
Hier bin ich überrascht, wie stark PNG-Kompression gegriffen hat – bei meinen eigenen Texturen fällt der Gewinn bei weitem geringer aus … andererseits liegt bei rund einem Drittel der DDS' der Alpha-Kanal brach und insbesondere die Texturen, die für Spezialeffekte benutzt werden, haben sehr regelmäßige Muster.

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 %
Hier hat PNG mich wirklich umgehauen. Ich hätte nie gedacht, dass PNG-Optimierung sich auf die Ladezeiten auswirkt – und dann auch noch so stark. Ich habe keine Ahnung, wo der Geschwindigkeitsgewinn herkommt … zumal ja beim Entpacken noch zusätzliche Leistung aufgewendet werden muss, um die entfernten Alpha-Kanäle wiederherzustellen.

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Aramis »

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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

Die Ladezeiten unter 50 % CPU-Last (hier ist die Streuung größer, was aber unvermeidbar war – darum auch ohne CPU-Auslastung):
  • 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)
Ergo braucht unter Last (und verglichen mit DDS) NTFS-komprimiertes DDS 1,27× so lange, um die 1,64× komprimierten Daten zu laden; PNG 1,74× so lange, um die 2,86× komprimierten Daten zu laden und optimiertes PNG 1,2× so lange, um die 3,65× komprimierten Daten zu laden.

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Alexander Kornrumpf »

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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Alexander Kornrumpf »

Näherungsweise würde mich interessieren ob es was vergleichbares zu Moores Law bezüglich Festplattenkapazität gibt.

EDIT: Wiki sagt ja.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Schrompf »

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 :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
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 :)
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.
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 :-)
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 ^^
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 575
Registriert: 05.07.2003, 11:17

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Lord Delvin »

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.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Zudomon »

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.
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.
Konsole.jpg
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
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Alexander Kornrumpf »

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.
Freut mich, obwohl diese Option sich wohl nicht rechnen wird, wenn ich der einzige Betroffene bin. :)
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Kleiner Texturkompressions-Benchmark

Beitrag von eXile »

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
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
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.
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.
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.
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: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.
Die Festplatte wirkt sich nicht auf die Ladezeit aus; selbst aus dem RAM lädt es genauso schnell bzw. irgendwie noch langsamaer :(
Alexander Kornrumpf hat geschrieben:Freut mich, obwohl diese Option sich wohl nicht rechnen wird, wenn ich der einzige Betroffene bin. :)
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?
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
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.

Achja; kommt ihr auch nicht mehr in ICQ?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
NytroX
Establishment
Beiträge: 358
Registriert: 03.10.2003, 12:47

Re: Kleiner Texturkompressions-Benchmark

Beitrag von NytroX »

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.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Alexander Kornrumpf »

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?
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.

P.S. Was richtig viel Platz verbraucht sind übrigens Schallplatten. Aber das nur am Rande.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Krishty »

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.
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.
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 )
Hach, das kenne ich. Bin mal gepapnnt, für wie wenig ich die Wagenladungen DVDs in ein paar Jahren loswerde.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Lynxeye
Establishment
Beiträge: 145
Registriert: 27.02.2009, 16:50
Echter Name: Lucas
Wohnort: Hildesheim
Kontaktdaten:

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Lynxeye »

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.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Kleiner Texturkompressions-Benchmark

Beitrag von Chromanoid »

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 ;).
Antworten