Eine Frage, kommt SAM bzw das offene Pendant jetzt eigentlich auch für X470er-Boards mit Zen3-CPUs?
SAM ist an sich ja offen. Es ist ein PCIe Feature mit Marketing Namen von AMD.
Wenn du die Nvidia Variante meinst, wird dir das nur Nvidia beantworten können.
Eventuell braucht es PCIe4, um relevant zu sein.
Zwar nutzen selbst Halo Karten PCIe3 x16 nur etwas mehr als halb, aber eventuell kann es da dennoch zu Bottlenecks kommen... Da braucht es mehr Informationen und Messungen speziell zu diesem Thema.
Ein "offener Standard" *) ist das Resizable BAR-Feature in der PCIe-Spezifikation, das dort bereits seit gut 10 Jahren schlummert (
AMD hat an dem Thema mit seinen GPUs bereits vor etwa 5 Jahren gearbeitet, es dann offensichtlich aber mangels Interesse schleifen lassen und nicht vollends implementiert, denn seit 2015 findet man Postings der Linux-Kernel-Entwickler, die sich aufgrund dessen mit diesem Thema beschäftigen und auch Microsoft war an dem Thema schon in 2017 dran).
SAM selbst ist gemäß F. Azor eine AMD-spezifische Implementation, die primär das PCIe-Feature umsetzt, auf dem Weg dahin jedoch einige Bugs und Glitches korrigieren und umgehen musste und die Art wie sie das gemacht haben, muss von anderen Herstellern berücksichtigt werden, da es auf der AMD-Plattform (X570, BIOS/Firmware) eine AMD-spezifische Implementaiton ist.**) Offensichtlich ist das jedoch kein nennenswertes Problem, denn sowohl nVidia-Karten als auch Asus-MBs mit Z490 laufen bereits mit Beta-BIOSen und beide Hersteller erklärten vergleichbare Leistungszugewinne in ihren ersten Tests zu sehen, was auch nicht sonderlich wundert, da die zugrundeliegende technische Basis die gleiche ist, das Resizable BAR-Feature der PCIe-Spezifikation.
Darüber hinaus ist das Feature auch nicht an PCIe 4 gekoppelt, was ebenfalls in der Natur der Sache begründet liegt, weil das Problem hier ist, das mit dem 256 MiB-Fenster intern viele Daten in Richtung VRAM mehrfach umkopiert werden müssen, was mit dem ResBAR-Feature vermieden werden und in Abhängigkeit konkreter Game-Engines zu mehr oder weniger großen Performancezugewinnen führen kann.
Asus hat bei den Intel Z490-Board bereits erklärt, dass sie exemplarisch auf einem ROG Maximus XII HERO mit einem 10700K und einer RX 6800XT in Forza 4 bis zu +13,4 % erzielen konnten. (
Hier wurde implizit PCIe 3 verwendet, da Comet Lake PCIe 4 nicht unterstützt und zudem Asus einer der wenigen Hersteller ist, der bei ihren 400er-Boards auf eine "PCIe 4 readiness" weitestgehend oder gar vollständig verzichtet hat). Mittlerweile hat bspw. auch MSI erklärt, seine gesammte 400er-Serie zu aktualisieren (inkl. H470, B460 und H410). Darüber hinaus erklärte MSI auch RX 6000- und RTX 3000-Karten vollumfänglich zu unterstützen und man sah bei wccftech auch bereits ein MSI Z490 GODLIKE mit einer RTX 3000er-Karte laufen, was bspw. die Frage aufwirft, ob hier nVidia wirklich was nenennswert anpassen muss (zumindest auf Intel-Plattformen), wenn die Boardhersteller die Karten in ihren BIOS-Tests jetzt schon mit dem aktivierten Feature betreiben. Möglicherweise geht es bei dem von nVidia erklärten "
späteren Aktivieren" auch eher um eine Validierung und möglicherweise um eine Anpassung an die AMD-Plattform, denn bspw. bei Zen fehlte bisher anscheinend noch Funktionalität in der ISA für eine effiziente Unterstützung dieser PCIe-Funktionalität.
*) Genaugenommen ist es schlicht ein "einzelnes" Feature im PCIe-Standard, dass bisher kaum genutzt wurde, zumal es primär nur für Karten mit großem lokalen Speicher wirklich relevant ist, also auf Consumer-Produkten ausschließlich bei GPUs. Erste Erwähnung im Standard findet es seit dem Jahr 2008.
**) Hier ist unklar ob es sich um kleinere Bugs in der PCIe-Spezifikation handelt (
immerhin ist das Feature bisher in der Praxis so gut wie nicht zur Anwendug gekommen) oder ob es sich ggf. zum Teil auch um AMD-spezifische Bugs auf deren eigener Plattform handelt, die gelöst oder umgangen werden mussten. Wie auch immer, die individuelle Problemlösung auf der Plattformseite erfordert, dass bspw. nVidia und Intel sich mit AMD abstimmen damit AMDs Implementation im Treiber/BIOS/Firmware der jeweiligen GPUs berücksichtigt werden kann.
[Super-Resolution Upscaling] Das kommt wohl drauf an, ob das Feature Hardware der 6000er braucht.
Bei "reinem" GPU Compute sollte es kein Problem sein.
Theoretisch sollte es hier keinerlei Abhängigkeiten geben, denn der RDNA2-Launch liegt schon längere Zeit zurück und bisher hat AMD nichts bzgl. einer diesbezüglich spezifisch angepassten ISA oder speziellen HW-Einheiten bei RDNA2 verlauten lassen (
letztegenanntes nur der Vollständigkeit halber; dass es diese gibt ist quasi ausgeschlossen, da AMD das Thema schon längst angeschnitten hätte). Möglich wäre, dass es wie bei Intel's Xe mit DP4A ein entsprechendes Äquivalent in der ISA gibt, das die Verarbeitung etwas beschleunigen kann, dagegen dedizierte Funktionseinheiten wie die Tensor Cores gibt es bei AMDs RDNA2 jedoch nicht.
Dementsprechend sollte das Super-Resolution Feature grundsätzlich lauffähig sein (
wie es DLSS übrigens tendenziell auch ist, wenn man es über die Shader implementiert, wie es nVidia bspw. anfänglich mit der DLSS2-Beta machte), d. h. es liegt nur an AMDs "
Vertriebsdruck" ob und wie weit zurück sie das Feature für ihre GPUs anbieten wollen.
Leicht absehen lässt sich jedoch, dass das Feature bei kleinen GPUs mit wenigen TFlops eher weniger bringen wird, weil der nachgelagerte ML-Durchlauf zu viel Zeit in Anspruch nehmen wird (bzw. zu viel auf die Frametimes aufschlägt) und damit dem Ziel einer Erhöhung der Fps entgegenarbeitet. (
Alternativ könnte man natürlich versuchen die visuelle Qualität zu verringern um doch noch einen Fps-Zugewinn zu erzielen.)
*) Darüber hinaus ist noch die Frage, ob man bei diesem speziellen Workload mit einer noch geringeren Präzision arbeiten und bspw. von FP16 auf INT8 ausweichen könnte, was RDNA2 noch einmal zugute käme. Da die bisherigen Demos zu DirectML und auch nVidia das jedoch nicht machen, scheint INT8 hierfür jedoch ggf. eine zu geringe Präzision aufzuweisen und möglicherweise nicht infrage zu kommen.