Matrix-/WMMA-Berechnungen in Spielen

[basix]

Hallo zusammen

Das vor kurzem veröffentlichte DX12 Agility SDK ermöglicht es, Wave Matrix Multiply-Accumulate Funktionen mit einer allgemeinen API anzusprechen.
https://videocardz.com/newz/microsoft-dx12-agility-sdk-update-to-speed-up-gpu-ml-applications-and-av1-encoding

Das heisst, dass entsprechende HW-Einheiten über eine einheitliche API angesprochen werden können:
- Nvidia = Tensor Cores seit Turing
- AMD = WMMA Extension ab RDNA3
- Intel = Xe Matrix Extensions (XMX) seit Xe Arc

Wave Matrix driver support:

AMD: AMD will be releasing a preview AMD Software: Adrenalin Edition™ driver with WaveMMA support in the coming weeks, watch here for an updated link to that driver.
Intel: For Intel drivers, please contact your developer representative
NVIDIA: For NVIDIA drivers, please reach out to your developer engagement representative
Qualcomm: Future support is planned


AMD hat einen interessanten Blogeintrag veröffnetlicht, wo es um den Einsatz von Matrix Befehlen bei Spielen geht.
https://gpuopen.com/learn/matrix-compendium/matrix-compendium-intro/

Für mich sieht es danach aus, dass Matrix Operationen zukünftig viel öfters verwendet werden können. Mir ist aber nicht klar, wie gross das Potential ist:
- Ist FP16 ausreichend für viele Algorithmen? Nur AMD kann FP32 via WMMA beschleunigen
- Welche Algorithmen bieten sich an? Oder anders gefragt: Wie hoch ist der Anteil an Spiele-Algorithmen, welche neu via Matrix anstatt Vektor berechnet werden können?

Der Idealfall wäre, wenn viele Algorithmen mit Bfloat16/FP16-WMMA laufen würden. Hier hätte man verglichen mit FP32 Vektor das grösste Beschleunigungspotential. Bfloat16 hätte den Vorteil, dass es falls für die Algorithmen erforderlich ist, den FP32 Wertebereich beibehält (aber an Genauigkeit einbüsst).

[whatever]

Dann kann Nvidia ja endlich DLSS Super Resolution von ihrer proprietären API auf einen Herstellerübegreifenden Standard portieren.
/s

[Tobalt]

Dann kann Nvidia ja endlich DLSS Super Resolution von ihrer proprietären API auf einen Herstellerübegreifenden Standard portieren.
/s
:lol:

Super. DX als Sammelstelle für die ganzen Matrix Sachen hatte ich hier ja schon mehrfach beworben.

Mal sehen wie weit die Graka Hersteller künftig noch gehen werden, um die Engine Leutz trotzdem noch zu überreden, dass sie 3 parallele proprietäre TAA Varianten einbauen.

Obwohl genau dieses Problem hier ja nicht wirklich gelöst wird, oder? Dafür müsst DX ja eine Art generelles TAA anbieten, was die Graka Treiber dann mit dem jeweiligen Algo/Modell umsetzen, angepasst auf die eigene Hardware.

[basix]

Temporal Superresolution ist sicher einer der naheliengensten Algorithmen-Beispiele. Läuft bei Nvidia via Tensor Cores (zumindest der DNN Anteil), XeSS via XMX / DOT4a und FSR2 sowie UE5 TSR nutzen FP16 Rapid Packed Math.

Doch was ist mit anderen Algorithmen? Post Processing Filtern? Raytracing Denoising? UE5 spezifisch einige Teile von Lumen oder Nanite? usw.

[Tobalt]

Schon klar. Worauf ich hinaus will: Das sind keine generischen Matrixberechnungen, sondern mitunter eben relativ komplexe DNN Algos. Der Algo ist vom GPU Hersteller also auf die physische Ausführungseinheit trainiert, zB im Hinblick auf die Netztopologie oder die Anzahl der Weighting Parameter.

Diese ganzen Algo-specifics kann der Engineschreiber ja nicht wissen, wenn er einen DX Befehl für eine Matrix FMA einbaut. Sowas kommt ja erst im Grafiktreiber der GPU Hersteller.

Deshalb braucht DX hier IMO zusätzlich high level Befehle wie "mache TAA", welcher dann im Grafiktreiber in die hardwarespezifischen low level Befehle übersetzt wird. Natürlich sollte DX auch bestrebt sein einen guten Fallback für das TAA parat zu haben.

Ich finde den Schritt trotzdem gut. Ein Schritt Richtung Industriestandard wird helfen, die fetten low precision Einheiten zum Standard zu machen

[basix]

Ja, die DX12 Integration von WMMA-Befehlen über eine allgemeine API ist der wichtige Schritt, dass Matrizen-Operationen ohne Hersteller-Extensions umgesetzt werden können.