Neural Texture Compression (NTC)

[Nuon]

Es deutet sich ein kleiner Technologiesprung bei Nvidia an, bald werden die Texturen 4 fache Auflösung bei teilweise weniger VRAM-Verbrauch als bei herkömmlicher BCx Texturkompression haben:
https://videocardz.com/newz/nvidia-neural-texture-compression-offers-4-times-higher-resolution-than-standard-compression-with-30-less-memory
Link zum Nvidia Paper:
https://d1qx31qr3h6wln.cloudfront.net/publications/Random-Access%20Neural%20Compression%20of%20Material%20Textures.pdf
Beispiele:

[anorakker]

Wer braucht das seitdem wir dank NVIDIA nur noch DLSS und Pathtracing Matsche haben?

[Monger]

Wer braucht das seitdem wir dank NVIDIA nur noch DLSS und Pathtracing Matsche haben?
Speicher ist teuer, nicht wahr? Das ist ein Grund, warum sich grafisch bei Spielen grad wenig tut.

[Nuon]

@ anorakker: Diese beiden Dinge lassen sich je nach Vorliebe abschalten. ;)

[DrFreaK666]

Bin ich in einer Satire-Runde geraten, oder war jeder Kommentar bisher tatsächlich ernst gemeint?

[Nuon]

Die Frage ist, ob die hochauflösenden Texturen auf RTX4000er wegen Tensor Cores beschränkt sind?

[basix]

NTC Diskussion startete bereits hier im Ada Thread:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13298399#post13298399

Prinzipiell ist NTC sehr interessant:
- 3x höhere Kompression bei hohem Texturdetailgrad (ohne visuellen Unterschied)
- Bei sehr tiefen Bitraten und selber Texturgrösse (in MByte) ist die Qualität viel höher als bisher, wo man nur noch Matschtexturen hatte

Momentan werden die Tensor Cores für die Dekompression verwendet und es sind Nvidia spezifische Extensions nötig (im Paper wird sogar was von einem Custom DirectX Compiler erwähnt). Verglichen mit einem Fixed Function Accelerator hätte eien Tensor/Matrix Core Lösung aber den Vorteil, dass sie schneller am Markt angelangen könnte und die bisher nur wenig benutzten Tensor Cores für die Decompression verwendet werden könnten. Da Tensor Cores bei Nvidia parallel zu den Vector-Units und RT-Units arbeiten können, könnte man das evtl. zu guten Teilen via Async Compute verstecken. Zudem kann schneller auf der Technologie iteriert werden, wenn man General Purpose Matrix Units nutzt anstatt irgendwelche Fixed Function HW.

Zusammen mit anderen Technologien ergibt sich ausserdem ein sehr hoher Faktor an potentiellen VRAM-Einsparungen (bei gleicher Qualität):
- Sampler Feedback Streaming (DX12U)
- Direct Storage
- Virtualized Geometry (Nanite, Meshlets, ...)

DirectStorage hat in der Theorie noch den zusätzlichen Vorteil, dass man Assets komprimiert im Speicher lassen könnte und on-the-fly einliest und dekomprimiert (Dekompressionsrate in VRAM-Bandbreite = x-hundert GByte/s, ebenfalls über die Tensor Cores?). Dadurch liesse sich VRAM einsparen als auch die Effektivität der Last Level Caches steigern (AMD = Infinity Cache, Nvidia = L2-Cache). Die durchschnittliche Kompressionsrate bei Kraken liegt bei ~2x. Würde also in 2x VRAM-Bedarf Reduktion münden und gleichzeitig 2.8x Boost der effektiven Bandbreite von diesen Assets (2x VRAM-Bandbreite direkt, sqrt(2) durch effektiveres Caching des LLC). Das Potential ist mMn zu hoch, als dass es zukünftig nicht genutzt wird. Und bei noch besseren Kompressionsverfahren (siehe NTC oder anderen neuralen Kompressionsalgorithmen) wird der Hebel noch grösser. Und allgemein limitiert immer mehr die Speichermenge (Kosten) und die Bandbreite (Energieverbrauch) das Potential der GPUs. Hier also >2x Einsparungen zu realisieren wäre extrem wertvoll.

Die Frage ist, ob die hochauflösenden Texturen auf RTX4000er wegen Tensor Cores beschränkt sind?
Nein, sind sie nicht. Nur wird das auf die Performance von schwächeren Karten gehen. Bei heutigen GPUs ist bessere Texturauflösung fast gratis, da via Fixed Function HW beschleunigt. Einzig Speichermenge und Speicherbandbreite werden belastet. Hier mit NTC kommt noch die Rechenleistung dazu. Das kann man via Tensor, Matrix oder Vektor Units erledigen. Die Rechenleistung muss man aber liefern können. Tensor hat mMn aber den grossen Vorteil, dass sie sehr viele FLOPS liefern und da es flexibler ist kürzere Innovationszyklen liefern kann, wenn man es mit Fixed Function HW vergleicht. Und irgendwann wird man mehr als genug Rechenleistung haben, womit der prozentuale Anteil der Dekompression an der Frametime immer geringer wird.

Edit:
Texture Compression mit Neural Networks ist ausserdem nicht komplett neu. Hier ein Patent von 2020 (Electronic Arts)
https://www.freepatentsonline.com/y2020/0051287.html

[Nuon]

@basix: Vielen Dank für die ausführliche Antwort, ich bin schon gespannt, wann NTC zum erstenmal zum Einsatz kommt.

[BlacKi]

wenn nv denkt, das es die eigenen verkäufe ankurbeln wird, dann wohl recht schnell. ich meine, es ist proprietär, oder?

[Nuon]

Da die Dekompression auch per Vektor Units erledigt werden kann, dürften die anderen GPU Hersteller bald mit auf den Zug aufspringen. Hier dürfte die Patentlage entscheidend sein, wenn man sich das Patent, das basix erwähnt hat, anschaut.

[Argo Zero]

Es deutet sich ein kleiner Technologiesprung bei Nvidia an, bald werden die Texturen 4 fache Auflösung bei teilweise weniger VRAM-Verbrauch als bei herkömmlicher BCx Texturkompression haben:
https://videocardz.com/newz/nvidia-neural-texture-compression-offers-4-times-higher-resolution-than-standard-compression-with-30-less-memory
Link zum Nvidia Paper:
https://d1qx31qr3h6wln.cloudfront.net/publications/Random-Access%20Neural%20Compression%20of%20Material%20Textures.pdf
Beispiele:

Sehr geil. Für SP Games durchaus vertretbare Verzögerungen. :)

[Ex3cut3r]

Ist schon wirklich sehr noice.

Die Frage ist aber. Kommt das realtiv zeitnah? Und wenn ja, welche Arch kann es?

[Tobalt]

Laut Paper braucht es 3 mal so lange für Decompression als diese BC Methode. Gut genug?

[Nuon]

Laut Paper braucht es 3 mal so lange für Decompression als diese BC Methode. Gut genug?
Ich denke, wenn die Dekompression nur eine knappe Millisekunde auf die Renderzeit pro Frame aufschlägt, kann man damit leben.
Es kommt dann auf den Anteil der Texturen an, die mit dem NTC Verfahren komprimiert sind.
Weiterhin gibt es bei neueren Nvidia GPUs die Möglichkeit, die Dekompression parallel zu den anderen Rechenoperationen in den Tensor Cores auszuführen:
Da Tensor Cores bei Nvidia parallel zu den Vector-Units und RT-Units arbeiten können, könnte man das evtl. zu guten Teilen via Async Compute verstecken.

[basix]

Im Paper erwähnen sie bereits, dass in einem Spiel der Unterschied mit hoher Wahrscheinlichkeit kleiner sein wird als im Paper gezeigt, da durch andere Berechnungen der Game-Engine maskiert und eben auch Async Compute. Man überlappt ja heute bereits verschiedene Berechnungen, um die Auslastung der GPU zu erhöhen. Das ist nichts neues.

Ausserdem werden die Tensor Cores immer schneller, womit auch die Dekompression immer weniger Zeit in Anspruch nimmt. Und theoretisch kann man es auch in HW giessen, wenn das Verfahren und allenfalls sogar der Algorithmus standardisiert würden.

Sehr geil. Für SP Games durchaus vertretbare Verzögerungen. :)
Auch für alle anderen Spielen, wenn das noch etwas schneller wird ;)

Die Frage ist aber. Kommt das realtiv zeitnah? Und wenn ja, welche Arch kann es?
Zeitnah vermutlich nicht. Das muss in irgendeiner Form standardisiert werden. Entweder von Seiten Algorithmus (man kann bestehende APIs nutzen) oder von Seiten APIs (DX12, Vulkan, ...). Sonst ist es für Spiele-Entwickler einfach nicht interessant genug. Via NVAPI oder Vulkan Extensions könnte Nvidia das sicher schneller bringen, als Spieleentwickler wäre ich daran aber nicht interessiert. Man wird die Texturen für ein Spiel nicht in zwei verschiedenen Kompressions-Formaten an die Kunden ausliefern ;)

Prinzipiell kann das jede GPU-Architektur ausführen. Vermutlich aber nur die mit Tensor/Matrix Units sind genug schnell. Auf Konsolen wird man das also nicht sehen, ausser man kann hier nochmals extrem am Algorithmus optimieren. Nur schon das spricht gegen eine baldige Umsetzung. Ich sehe das aber als interessantes Thema für PS6 und Co., da man hier das entweder in HW giessen kann (Accelerator) oder die Matrix-Units stark aufbohren wird (was ich als gesetzt ansehe). Bei der PS6 sehe ich nämlich 32 GByte als realistisch an, mehr Speicher wird es vermutlich nicht werden. Jetzt kann man nochmals an der SSD schrauben (z.B. PCIe 6.0 und >20 GByte/s) und nochmals verbesserten Streaming-Aglorithmen (weiss nicht, ob die PS5 etwas wie Sampler Feedback Streaming kann), doch Speicherplatz wird immer wertvoller. Deswegen sehe ich hier folgenden Ansatz als vielversprechend: Bessere Kompression und alle Daten im VRAM bleiben so lange wie möglich komprimiert. Ersteres ist relativ "einfach" und wäre sowas wie NTC. Bei letzterem müsste man mit extrem hoher Bandbreite dekomprimieren können (TByte/s), was eigentlich nur mit Accelerators realistisch klingt. Vorteil könnten aber x-Faktoren an VRAM-Speicherplatz Einsparungen sein. Bei der PS5 wird bei SSD -> VRAM dekomprimiert. Bei der PS6 könnte man das erst bei VRAM -> Cache machen, womit man eben deutlich an Speicherplatz sparen könnte. Und DirectStorage am PC wäre für ein solches Konzept ebenfalls prädestiniert, da die Dekompression auf der GPU läuft. Wird spannend :)

[aufkrawall]

Würde eher annehmen, Microsoft und Sony setzen auf anderweitige interne, möglichst platzsparende Weiterentwicklungen von FF-Dekompression und die Nvidia-Lösung wird, abseits von PR-Meldungen, 100% bedeutungslos bleiben, wenn wirklich die Assets in verschiedenen Formaten ausgeliefert werden müssten. Wenn dann irgendwann die Brotkrumen von den Konsolen auf den PC abfallen, wird man schon froh sein können (wie DirectStorage momentan mal wieder zeigt, Async Compute könnte man da auch nennen).
Tippe auf 100% CPU-Last 32 Threads in The Last of Us Part 3 für 2028. :freak:

[basix]

Ja, verschiedene Auslieferformate sind definitiv ein Showstopper. Das wird nicht passieren. Das heisst aber nicht, dass der Ansatz von NTC "in der Bedeutingslosigkeit versinkt". mMn dient das jetzt als Input für Lösungen der Zukunft und da sehe ich PS6 und Co. als nächsten Stopgap / Meilenstein, wo eine solche (disruptive) Änderung kommen könnte. PS5 Assets liefert man mit Kraken Kompression aus, PS6 mit NTC oder was in der Art. PC wird schwieriger, weswegen eine Fallback-Implementation nötig sein wird. Und hier wäre Dekompression via Tensor eine mögliche Variante. FF/Accelerators kann man bei den dGPUs dann immer noch einbauen.

FF-Dekompression in Konsolen ist sicher am wahrscheinlichsten. Energieeffizient und platzsparend. Aber was heisst hier FF? Auch FF kann parametrisiert werden. Nvidias Lösung via Tensor Cores ist einfach "maximal parametrisierbar", da der Algorithmus selbst frei angepasst werden kann. Hat man sich beim Algorithmus mal auf einen akzeptablen Stand geeinigt, kann man es standardisieren (und dann in FF-HW in dGPUs giessen - was man bei Konsolen ja dann eh schon gemacht hat - oder als Fallback auf den Vektor/Tensor-ALUs laufen lassen - wie DirectStorage Dekompression heute). Hier müsste primär Microsoft aktiv werden, da sie am meisten von Xbox sowie PC übergreifenden gemeinsamen Features profitieren. Leider ist Microsoft relativ langsam mit dem...

Und es ist gut, dass wir noch 3-4 Jahre bis zur nächsten Konsolen-Generation haben. In dieser Zeit kann der Algorithmus-Ansatz reifen und entsprechende Umsetzungen in Konsolen-Chips vorbereitet werden. NTC wird leider also nicht bereits übermorgen erscheinen, aber beim nächsten Konsolen-Zyklus kann es bereit sein. Das ist deutlich besser als das, was wir bei der PS5/XBSX mit Raytracing gesehen haben, wo das Release-Datum die RT-Umsetzung von AMD bei RDNA2 auf ein Minimum hat eindampfen lassen.

Am PC könnte man NTC eigentlich schon früher sehen, wenn jemand dahingehend pusht. Aber ausserhalb von gesponserten Games / Techdemos (z.B. von Nvidia) sehe ich das nicht als gangbar an. Bis eben die neuen Konsolen dann erscheinen werden, welche die Technologie "salonfähig" machen könnten. DirectStorage ist hier eigentlich ein Trauerspiel und Microsoft hätte den heutigen Stand mit DirectStorage v1.1 bereits vor dem Erscheinen der Xbox Seris X/S umgesetzt haben müssen. Dann wäre die Adoption deutlich zügiger vonstatten gegangen. Soweit ich weiss war DirectStorage initial nichtmal im Xbox SDK enhalten...

[Achill]

NTC klingt auf jeden Fall interessant, wenn ich das Paper richtig verstehe, dann wurde die Umsetzung von NTC auf einer NV GPU gezeigt. Der Ansatz ist aber nicht von NV (@dildo4u (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13298399#post13298399)).

Laufzeit:
- Laut Paper war es zwischen ~0,5ms und ~1,4 ms auf einer RTX 4090

Offene Fragen:
- Wie verhält sich TNC auf kleineren GPUs (die es wegen VRAM nötig hätten)?
- Wie viel (mehr?) Energie benötigt das Verfahren?
- Wie verhält sich das Verfahren, wenn andere Operation (wie DLSS) auf den Matrix-Einheiten laufen?

Limitierungen
- Das Paper (da nicht Marketing sondern Wissenschaftlich) hat am Ende noch einen "Limitations" Absatz (hier noch gar nicht erwähnt), ich selbst kann nicht einschätzen ob dort etwas aufgezählt wird was den Einsatz erschwert oder z.B. Anpassungen an Game-Engines benötigen würde. Es wird wahrscheinlich nicht einfach Transparent mit dem Treiber eingeführt werden kann können.

Meine Einschätzung bzgl. Einsatzweck
- Unwahrscheinlich dies für die letzte oder aktuelle GPU Generation zu sehen
- Die Kosten (Berechnung, Energie) müssen in das Segment von Mainstream passen, da dort m.E. auch die Grafikkarten mit eben knappen VRAM zu finden sind.

[basix]

Ich habe mal kurz überschlagen, wie schnell man dekomprimieren kann:
- NTC 1.0 "Paving Stones" Textur = 17 MByte
- Dekomprimierung + Rendering = 1.33ms
- Dekompressionsrate = 1000ms / 1.33ms * 17 MByte = 12.8 TByte/s

Dasselbe für die andere NTC Levels:
- NTC 0.20 = 3.0 TByte/s
- NTC 0.50 = 5.8 TByte/s
- NTC 2.25 = 19.8 TByte/s

Die Performance-Werte beinhalten auch das Rendering, weswegen die kleineren Grössen deutlich schlechter abschneiden.

Auf was ich aber eigentlich hinauswill: Die Werte sind viel höher als die L2-Cache Bandbreite der RTX 4090 oder die Infinity Cache Bandbreite einer 7900 XTX. Beide sind bei ~5.0 TByte/s. Man kann also ohne Probleme die Daten komprimiert im Last Level Cache lassen und solange kein Writeback der Textur in den LLC passiert, spart man sich also den Speicherplatz auch im LLC. Ich kenne mich mit den genauen Textur-Abläufen in GPUs zu wenig aus (wo und wie oft wird dekomprimiert oder in eine Textur zurückgeschrieben), scheint aber auf modernen GPUs gangbar zu sein. Und wie gesagt, Tensor Core Decompression kann man via Accelerator substituieren, wenn sich das lohnt.


Zu neuartigen Texturkompressionsverfahren kann ich auch dieses Paper empfehlen:
http://richg42.blogspot.com/2016/10/gst-gpu-decodable-supercompressed.html

Und im selben Blog etwas zu EA & Microsoft und Neural Network Texture Compression:
http://richg42.blogspot.com/2023/03/eamicrosoft-neural-network-gpu-texture.html
https://onlinelibrary.wiley.com/doi/am-pdf/10.1111/cgf.13534

[=Floi=]

kann das mal jemand näher erklären?
wird da direkt ein muster generiert oder wird es in einfachere texturen umgewandelt. zb wie bei bumpmapping.

[Tobalt]

Wenn die Dekompression per Async Compute passieren soll, dann musst du die dekomprimierten Texturen (für die ganze Szene) zwangsläufig irgendwo zwischenspeichern.

[basix]

Im Idealfall sind das aber Register/L0/L1/Local Data Share und nicht der LLC ;)

Wo liegen eigentlich die heutigen Dekompressionsenheiten? In den TMUs? Edit: Ja, in den TMUs

[Tobalt]

Ja aber sind dekomprimierte Texturen für eine ganze Szene nicht viel größer als die Low Level Caches ?

[basix]

Wären sie ja heute schon. Texturen sind komprimiert im VRAM und werden auch komprimiert im VRAM gelassen (z.B. DXT Format). Texturen müssen also in kleinen Blöcken geladen und verarbeitet werden können. Nicht die Textur als ganzes. Ich glaube genau das ist eine der Key-Innovationen von NTC, dass dies auch mit einem neuronalen Netzwerk Ansatz funktioniert (wenn ich das richtig verstanden habe, kann mich aber täuschen)
At the same time, our method allows on-demand, real-time decompression with random access similar to block texture compression on GPUs, enabling compression on disk and memory.

Bin noch kurz über das RDNA1 Paper (https://www.amd.com/system/files/documents/rdna-whitepaper.pdf) geflogen und die Texturdaten werden im L0 und LDS gespeichert. TMUs können bei Bedarf noch direkt in den L2 zurückschreiben, das hat aber jetzt nicht direkt was mit NTC zu tun hat (sondern anderen Rendering-Techniken, wo in eine Textur geschrieben wird).

Edit:
Die Blockgrössen für Texturen sind typischerweise 128-256 Byte gross, was ohne Probleme in die Low Level Caches passt. Das ist dann "Texels" und nicht die ganze Textur
You may have already caught the term in the paragraph above, but this is a strictly block based compression algorithm, meaning each block of the compressed data can be uncompressed or even recompressed independently, which is a key requirement due to how randomly textures and other graphics resources are accessed by the GPU. These blocks are usually fairly small, 128 or 256 bytes being the most common.
https://www.patreon.com/posts/look-at-modern-44656655

[basix]

Hier gibt es ein weiteres SIGGRAPH Paper von Nvidia, welches sich um Optimierungen von Texturen dreht. Hier geht es primär um Performanceverbesserungen bei immer komplexer werdenden Materialien.
https://research.nvidia.com/labs/rtr/neural_appearance_models/

Neben der höheren Shading Performance kann sich auch eine Reduktion der Speichermenge ergeben (wird so im Paper erwähnt). Das hat keinen direkten Zusammenhang mit NTC, aber das Resultat in dieser Hinsicht sollte ähnlich sein oder kann im besten Fall sogar kombiniert werden.

Ich denke hier gerade auch an UE5 "Substrate", welches deutlich komplexere Materialien ermöglicht. Was die Qualität erhöht aber auch auf die Performance gehen kann.

Ich finde es genial, dass jetzt so viele Innovationen rund um Texturen gezeigt werden. Ein Grossteil der visuellen Qualität wird nämlich von Texturen bestimmt. Geometrie und Beleuchtung sind sicher ebenfalls sehr wichtig aber ohne qualitativ hochwertige Texturen lässt man viel Potential liegen.

[Gast]

Naja, wird auch Zeit, DXTC hat jetzt ja schon einige Jahre am Buckel.

[Geldmann3]

Halte es für eine tolle Innovation, aber bin ich der einzige, der hofft, dass Nvidia das beim nächsten Mal nicht wieder als Ausrede für geringe Vram-Mengen in Grafikkarten nutzt? Das haben sie schon so oft getan, mit ihrer Texture-Compression, doch am Ende geht eben nichts über Vram...

Finde an sowas wie eine RTX 4090 oder 7900XT gehören eigentlich 32GB Vram und unter 8GB sollte gar keine Karte mehr produziert werden.

[Gast]

Das haben sie schon so oft getan, mit ihrer Texture-Compression, doch am Ende geht eben nichts über Vram...



Ähm nein, haben sie nicht, und Nvidia hat auch keine spezielle Texturcompression, die verwenden die selben Assets wie jeder andere auch.

[Crazy_Borg]

Ja, seit S3TC (aufgegangen in DirectX als DXTC) vor ca. 25 Jahren hat sich da nicht viel getan.

---Edit---
Ui, sehe gerade die letzte DirectX Texturenkompression ist noch gar nicht "so" alt, BC7 in DirectX 11 von 2009.

[Taigatrommel]

Na ist doch super, dann kann nVidia auch in Zukunft bedenkenlos acht und zwölf Gigabyte VRAM anbieten, ggf. auch weiterhin bei der 80er Serie knausern. Den Preis kann man auch wieder erhöhen und mit R&D Kosten begründen. Wenn die Kompression wirklich so gut ist, kann man vielleicht sogar wieder die Hälfte des Speichers verbauen und es passend vermarkten.

[Argo Zero]

Na ist doch super, dann kann nVidia auch in Zukunft bedenkenlos acht und zwölf Gigabyte VRAM anbieten, ggf. auch weiterhin bei der 80er Serie knausern. Den Preis kann man auch wieder erhöhen und mit R&D Kosten begründen. Wenn die Kompression wirklich so gut ist, kann man vielleicht sogar wieder die Hälfte des Speichers verbauen und es passend vermarkten.

Es kommt halt drauf an wie kompatibel das Feature am Ende sein wird.
Wenn sie es beispielsweise einfach in DLSS mit einbauen ohne das Entwickler zusätzliche Arbeit leisten müssen, hätten diese Spiele schon mal deutlich weniger Speicherhunger.
Schade, dass dazu noch nichts gesagt wird.

[aufkrawall]

Dreimal darfst du raten, weshalb nicht.

[Crazy_Borg]

nvidia muss erst Geldmittel bündeln, um die Entwickler ausreichend buttern zu können...

[Argo Zero]

nvidia muss erst Geldmittel bündeln, um die Entwickler ausreichend buttern zu können...

Zum Aufwand steht im Paper nichts. Was weißt du, was wir nicht wissen? :)

[The_Invisible]

Finde an sowas wie eine RTX 4090 oder 7900XT gehören eigentlich 32GB Vram und unter 8GB sollte gar keine Karte mehr produziert werden.

Wieso, wo limitieren 24GB den? Die meisten Games brauchen noch immer net mal 12GB und ich hätte es noch nicht geschafft das bei der 4090 der VRAM vor Leistung limitiert (Mal abgesehen von irgendwelchen unsinnigen Texturmodsspielereien).

Anders aussehen tuts bei Blackwell, wenn die wirklich doppelte Perf liefert könnte man schon wieder in Berreiche kommen wo 24GB limitieren. Aber ansonsten wird eh mal sehr lange auf 12/16GB optimiert bis da Konsolenmäßig wieder was passiert