- 05.04.26
- 10:13
- Artikel
-
+1-1
Speicherkrise für Gamer entschärft? Nvidia-KI-Kompression beeindruckt
Die meisten Spiele können NTC technisch gar nicht verwenden.
Technisch basiert NTC darauf dass die Textur einfach nur in 1/4tel der Original-Auflösung im VRAM liegt, was 15/16tel des VRAM spart, gleichzeitig aber noch ein 200-500kB an Gewichten für ein Neuronales Netzwerk pro so "optimierter" Textur notwendig werden.
Das eigentliche Problem das sich dabei jetzt ergibt, ist aber wie viele Bytes an Daten pro zu renderdem Pixel notwendig sind. Mit klassischer Block-Kompression sind das amortisiert 0.5 Byte pro Pixel, und im Worstcase (Microgeometrie) bis zu 16 Bytes pro Pixel die per Quasi Random-Access aus dem VRAM zu laden sind. Kernproblem hier ist der Worstcase-Fall.
Mit NTC hingegen wird für jeden Pixel jeweils der komplette Gewichtvektor benötigt. Heißt 200-500kB als Minimum für den Bestcase und den Worstcase-Fall, pro Pixel. Das funktioniert genau so lange, wie aggressiv Geometrie mit der selben Textur strikt in Batches gerendert wird, in dem Fall leben diese 200-500kB nicht im VRAM sondern im L2-Cache. Und der L2-Cache liefert dann X Terabyte pro Sekunde an die Shaderkerne, damit das auch nur irgendwie funktioniert.
Die meistens Spiele betreiben aber kein so aggressives Batching, das wirklich nur maximal 16 Texturen jeweils gleichzeitig zum Einsatz kommen (mit mehr ist der L2-Cache voll!), und ohne diese Einschränkung bricht die Performance des NTC-Ansatz komplett in sich zusammen weil der VRAM die benötigte Speicherbandbreite nicht liefern kann.
Je komplexer die Szene, sprich je mehr unterschiedliche Materialien, desto schlechter ist die Performance von NTC. Heißt es funktioniert abseits der Techdemos genau in den Szenarien nicht, wo eine bessere Texturkompression notwendig gewesen wäre.
Kommentare
8
Kommentare
geschrieben
8
Antworten
erhalten
13
Likes
erhalten
VW-Vollhybrid: Volkswagen kopiert Toyotas Erfolgsrezept für den Golf
Grober inhaltlicher Fehler im Artikel - kopiert wurde hier nicht Toyotas Ansatz mit dem Planetengetriebe zur Koppelung und klassischem Getriebe, sondern der von Honda seit mittlerweile 8 Jahren erprobte serielle Hybrid der ziemlich gut an der Kupplung im 1-Gang-Getriebe (hat praktisch nur den 6. Gang für Landstraße/Autobahn, alle unteren Gänge sind elektrisch) wieder erkennbar ist. (Und nebenbei schon seit Jahren in ADAC-Tests die Rangliste bei Zuverlässigkeit anführt!)
Ist übrigens meines Wissens nach nicht nur von VW, sondern auch von BMW und Toyota für die nächste Hybrid-Generation als Design lizenziert worden. Toyota ist vermutlich nur wegen Corona noch so lange bei dem Ansatz mit dem Planetengetriebe geblieben weil die Leistungselektronik die als "elektronisches Getriebe" zwischen den Motoren benötigt würde nach Corona noch für 3-4 Jahre praktisch nicht mehr käuflich war. Der Wechsel war aber schon lange absehbar.
Speicherkrise für Gamer entschärft? Nvidia-KI-Kompression beeindruckt
@Aerith: mit dem Support in zukünftigen Engines schaut es sehr mau aus. Aufgrund der genannten Einschränkung dass es pro Render-Pass mit einer nur lächerlich niedrigen Anzahl von Texturen funktioniert, ist die Praxistauglichkeit nicht gegeben.
Das Problem ist seit der ersten Vorstellung von NTC in Fachkreisen bekannt. Der Sourcecode für NTC steht mittlerweile seit über einem Jahr zur Integration durch Engine-Entwickler bereit, die Adaption ist bei Null.
Speicherkrise für Gamer entschärft? Nvidia-KI-Kompression beeindruckt
Die meisten Spiele können NTC technisch gar nicht verwenden.
Technisch basiert NTC darauf dass die Textur einfach nur in 1/4tel der Original-Auflösung im VRAM liegt, was 15/16tel des VRAM spart, gleichzeitig aber noch ein 200-500kB an Gewichten für ein Neuronales Netzwerk pro so "optimierter" Textur notwendig werden.
Das eigentliche Problem das sich dabei jetzt ergibt, ist aber wie viele Bytes an Daten pro zu renderdem Pixel notwendig sind. Mit klassischer Block-Kompression sind das amortisiert 0.5 Byte pro Pixel, und im Worstcase (Microgeometrie) bis zu 16 Bytes pro Pixel die per Quasi Random-Access aus dem VRAM zu laden sind. Kernproblem hier ist der Worstcase-Fall.
Mit NTC hingegen wird für jeden Pixel jeweils der komplette Gewichtvektor benötigt. Heißt 200-500kB als Minimum für den Bestcase und den Worstcase-Fall, pro Pixel. Das funktioniert genau so lange, wie aggressiv Geometrie mit der selben Textur strikt in Batches gerendert wird, in dem Fall leben diese 200-500kB nicht im VRAM sondern im L2-Cache. Und der L2-Cache liefert dann X Terabyte pro Sekunde an die Shaderkerne, damit das auch nur irgendwie funktioniert.
Die meistens Spiele betreiben aber kein so aggressives Batching, das wirklich nur maximal 16 Texturen jeweils gleichzeitig zum Einsatz kommen (mit mehr ist der L2-Cache voll!), und ohne diese Einschränkung bricht die Performance des NTC-Ansatz komplett in sich zusammen weil der VRAM die benötigte Speicherbandbreite nicht liefern kann.
Je komplexer die Szene, sprich je mehr unterschiedliche Materialien, desto schlechter ist die Performance von NTC. Heißt es funktioniert abseits der Techdemos genau in den Szenarien nicht, wo eine bessere Texturkompression notwendig gewesen wäre.
Nicht nur Nvidia: Auch bei AMD schmelzen immer weitere Stromstecker
Es gibt in diesem Fall die PCI-SIG als zuständiges Normierungs-Gremium. Die sind aber - was Stecker angeht - nur der verlängerte Arm des Unternehmens Molex, und schreiben damit vor was auch immer die im Angebot haben.
Wie man jetzt allerdings auf die Idee kommt einen Stecker der pro Pin theoretisch 8A kann so zu behandeln als könnte er ohne aktives Loadbalancing 50A auf einer einzigen Schiene ist extrem fragwürdig. Das stinkt schon fast nach Bestechung durch einen Vertriebler bei Molex, so wenig technisches Sachverständniss steckt hinter dieser Entscheidung. Elektroingenieure waren bei der Auswahl von diesem Stecker nicht beteiligt.
Linux-Vater Torvalds erklärt: Windows oft nicht schuld an Bluescreens
RAM-Fehler betreffen meistens eher GPUs, nicht CPUs... Wenn auf alternden GPUs irgendwann plötzlich Geometrie oder Texturen im laufenden Betrieb korrupt werden sind das wirklich RAM-Fehler. Das führt aber meistens nicht bis zum Bluescreen!
Aber bei CPUs - außerhalb vom Lowcost-Embedded-Bereich - sind die eigentlich ziemlich selten. Und meistens eher ein Fall von "funktioniert ganz oder gar nicht", kein "führt irgendwann spontan zu Korruption".
Hauptursache für Bluescreens unter Windows sind sind in den letzten 20 Jahren ziemlich konsequent immer die gleichen gewesen: Fehlerhafte Treiber. Überwiegend GPU-Treiber um genau zu sein, und Storage-Treiber sind knapp dahinter auf Platz zwei. Und selbst wenn da Mal Speicher korrupt wird dann ist es selten die Hardware die Schuld ist, sondern fast immer eine Racekondition in Software weil in diesen Daten schaufelden Treibern ziemlich viel asynchron passiert und häufig mehr "optimiert" als getestet wird.
Nur zum Verständnis: Es reicht eine einzige fehlerhafte Zeile Code in einem Treiber im System - eine aus mehreren dutzend Millionen - um das ganze System in einen instabilen Zustand zu bringen wo dann die resultierenden Korruptionen praktisch willkürlich in anderen Komponenten Folgefehler ohne nachvollziehbare Ursache auslösen.
Was hier tatsächlich für Abhilfe sorgt, ist das reduzieren der eigentlichen Treiber auf ein absolutes Minimum, und die Verlagerung der meisten Arbeit in Services die außerhalb des Addressraums des Kernels arbeiten. Die zum Treiber gehörigen Services stürzen dann zwar auch heute immer noch regelmäßig ab, aber der Bluescreen bleibt aus.
Tatsächlich gab es neben GPU und Storage-Treibern in der Vergangenheit noch einen weiteren Übeltäter: Die Treiber von Antivirus-Diensten. Da hat aber Windows inzwischen die eben beschriebene Trennung erzwungen, was die Systemstabilität massiv verbessert hat. Schlagzeilen gibt es trotzdem immer noch jedes Mal wenn ein Softwarehersteller es da "besser weiß" und drauf besteht doch noch monolitische Treiber für irgendwelche "Enterprise" Sonderfunktionen zu schreiben.
Intel: Neuer Core Ultra 9 285 in Benchmark deutlich abgeschlagen
@WinFuture bei den Geekbench Multicare-Benchmarks sollte man ganz generell extrem vorsichtig sein. Laut deren eigener Dokumentation ist der Benchmark für Prozessoren mit mehr als 16 Threads nur noch eingeschränkt überhaupt aussagekräftig, und bei mehr als 64 Threads übrigens überhaupt nicht mehr. Schlichtweg weil ein paar der Tests lediglich 16 Threads verwenden, und fast alle weniger als 64 Threads.
Chip-Revolution: Neuartiger "Fabric"-Prozessor 100-mal effizienter
@KiaW: nicht ASIC, sondern FPGA. Ein Haufen von ALUs bzw. FPUs plus fertigen Speichercontrollern und Cache-Blöcken mit einem kleinen Anteil von programmierbaren Gattern dazwischen ist das Standard-Rezept für einen modernen FPGA.
Aber die bessere Effizienz ist in der Regel ein Märchen - man erreicht zwar trivial bessere Signallaufzeiten, aber die Effizienz killt einem dann in der Regel doch die fehlende Skalierbarkeit und das fehlen der Hoch-spezialisierten ASICs für bestimmte Domänenspezifische Instruktionen die CPUs und GPUs dann doch haben.
Was CPUs und GPUs komplett aufbläht, ist der zusätzliche Mehraufwand um ein kohärentes Speichermodell zu bieten, und das mit Speicherzugriff für 60+ CPU-Kerne / Compute Units / Shader Module / Whatever. Sowie bei CPUs die ganze Sprungvorhersage - weil wenig überraschend die FPGAs auch dort wieder nur profitieren und die fixe Pipeline voll ausreizen können wenn es höchstens minimale Verzweigungen notwendig sind.
Putzteufel-Gene benötigt: Apple Vision Pro verlangt (zu) viel Reinigung
@Mitsch79: größeres Display innen und mehr Sensorik innen (Eyetracking) die wirklich sauber sein muss.
Und im Gegensatz zu Profi-Modellen die für die schnelle Reinigung auf Messen oder im Kundenkontakt ausgelegt sind, sind hier zu viele verschiedene Materialien sowie nicht kratzfeste bzw. chemisch angreifbare Oberflächen involviert.
Auch außen wurde z.B. auf die üblichen hervorgehobenen Rahmen um die Kameras verzichtet, weshalb die schneller Fingerabdrücke kassieren als Konkurrenzmodelle.