Smart Access Memory: Screenshots belegen Support für ältere Ryzen-CPUs

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu Smart Access Memory: Screenshots belegen Support für ältere Ryzen-CPUs

Bei der Vorstellung von AMDs neuen Radeon-RX-6000-Grafikkarten ging es auch um das neue Smart Access Memory-Feature. Dadurch sollen CPUs der aktuellen Ryzen-5000-Reihe gänzlich auf den VRAM der Grafikkarte zugreifen können, um so im Idealfall Overhead-reduzierte Optimierungen wie auf den Konsolen zu ermöglichen. Neue Screenshots legen nun nahe, dass das Feature sehr wohl auch von Ryzen 1000 und Ryzen 3000-CPUs unterstützt wird, wenn sie auf einem aktuellen Mainboard mit 500er-Chipsatz betrieben werden.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

lastpost-right.png
Zurück zum Artikel: Smart Access Memory: Screenshots belegen Support für ältere Ryzen-CPUs
 
Re-Size BAR war aber doch nur die Grundlegende Technik, aber nicht direkt SAM. SAM ist doch eine spezielle Implementierung der Re-Size BAR in ZDN3+RDNA2 oder irre ich mich?
Die Re-Size BAR sollte bei allen PCI-E 4.0 Boards funktionieren, egal welche CPU oder GPU drinsteckt. Darunter auch die PCI-E 4.0 Ready Intel Boards...
Ergo die Re-Size BAR sollte auch bei älteren Ryzen funktionieren, da diese ja PCI-E 4.0 haben. Nur braucht man noch eine Treiber Implementierung dafür...
 
Re-Size BAR war aber doch nur die Grundlegende Technik, aber nicht direkt SAM. SAM ist doch eine spezielle Implementierung der Re-Size BAR in ZDN3+RDNA2 oder irre ich mich?
Die Re-Size BAR sollte bei allen PCI-E 4.0 Boards funktionieren, egal welche CPU oder GPU drinsteckt. Darunter auch die PCI-E 4.0 Ready Intel Boards...
Ergo die Re-Size BAR sollte auch bei älteren Ryzen funktionieren, da diese ja PCI-E 4.0 haben. Nur braucht man noch eine Treiber Implementierung dafür...
So war auch mein Eindruck.
 
Re-Size BAR war aber doch nur die Grundlegende Technik, aber nicht direkt SAM. SAM ist doch eine spezielle Implementierung der Re-Size BAR in ZDN3+RDNA2 oder irre ich mich?
Die Re-Size BAR sollte bei allen PCI-E 4.0 Boards funktionieren, egal welche CPU oder GPU drinsteckt. Darunter auch die PCI-E 4.0 Ready Intel Boards...
Ergo die Re-Size BAR sollte auch bei älteren Ryzen funktionieren, da diese ja PCI-E 4.0 haben. Nur braucht man noch eine Treiber Implementierung dafür...
Ja, du irrst dich. ;-)
Das hier grundlegend verwendete Feature ist die Resizeable BAR-Funktionalität aus der PCIe-Spezifikation. (Beispielsweise AMD war da übrigens schon in 2015 mit ihren GPUs dran, hat das Thema dann aber offensichtlich wieder fallengelassen.)
Was AMD hier als SAM implementiert ist lediglich deren plattformspezifische Lösung zur Freischaltung der ResBAR-Funktionalität im Zuge derer laut F.Azor einige Bugs auf der Plattform gefixt werden mussten, damit alles ordnungsgemäß funktioniert. Dieser AMD/plattformspezifische Lösungsansatz muss von Herstellern wie nVidia und Intel berücksichtigt werden (in Treibern/Firmware) damit ihre Karten auf den AMD-Plattformen mit dieser Funktion einwandfrei zusammenarbeiten. (Ob es sich bei den Bugs um eher AMD-spezifische Bugs oder Schwächen in der PCIe-Spezifikation handelte, ließ F.Azor offen.)

Letzten Endes kann man auf allen Plattformen mit der freigeschalteten Funktionalität einen vergleichbaren Leistungszugewinn erwarten, denn im Endeffekt werden dadurch schlicht unnötige Kopiervorgänge von Speicherblöcken vermieden, da bisher alles durch ein 256 MiB-Fenster von der CPU auf die GPU geschoben werden (und danach vielfach intern umkopiert werden) musste.
Einzig zu beachten ist, dass die Zugewinne softwareabhängig sind. Es gibt Titel, denen SAM bzw. eine nutzbare ResBAR nahezu egal ist und es gibt Titel, die hier tatsächlich bis zu etwa +11 % hinzugewinnen können. Asus sprach auf einem Z490 bspw. in Verbindung mit einer RX 6800 XT in Forza 4 gar von +13,3 % (übrigens mit PCIe 3.0; die ResBAR hat nichts mit der PCIe-Geschwindigkeit zu tun).

Wurde nicht kürzlich angeblich von AMD selbst gesagt, dass die älteren Prozessoren das nicht in Hardware berherrschen????
Im Sinne einer absatzfördernden Maßnahme lässt man das natürlich erst mal so (unkommentiert) im Raum stehen. Beispielsweise im Lauchevent erwähnte man in gleicher Art mit keiner Silbe, dass SAM letzten Endes lediglich ein AMD-Marketingname für das PCIe-Resizeable-BAR-Feature ist. ;-)
Unterm Strich darf nach aktuellem Stand jedoch angezweifelt werden, dass das Feature sinnvoll auf älteren AMD-CPUs genutzt werden kann, bzw. dort würden die Leistungszugewinne voraussichtlich deutlich sinken oder sich gar ins Gegenteil verkehren (wenn die nachfolgende Aussage zutreffend ist).
Hintergrund ist hier, dass gemäß CapFrameX ein PDEP/PEXT (parallel bit deposit and extract) erforderlich ist und diese sind auf älteren Zen-CPUs nur via Microcode implementiert. Laut Anandtech haben diese bspw. auf Zen2 eine Latenz von 300(!) Taktzyklen. In Zen3 hat man diese Funktionalität nun hardwareseitig implementiert (bei Intel ist das schon seit vielen Jahren der Fall) und dort haben die Befehle nun nur noch eine Latenz von 3(!) Taktzyklen.

Update zu PDEP siehe hier ...
 
Zuletzt bearbeitet:
... wohl auch von Ryzen 1000 und Ryzen 3000-CPUs unterstützt wird, wenn sie auf einem aktuellen Mainboard mit 500er-Chipsatz betrieben werden.

ich dachte, dass 1000-er Ryzen nicht lauffähig sind in 500-er chipsätzen...:ka:

war mir SO auch neu!
wie ist das denn: wenn man das bios-update für nen Ryzen der 1. Gen. aufspielt, läuft ein 5xxx dann mit dem bios auch oder muss dann gefrickelt werden?
 
Nicht schlecht, dann könnte quasi mein 3800XT Unterbau problemlos diesen Schub generieren wenn Nvidia irgendwann die Funktion freischaltet. Das Bios ist ja bereits auf dem Mainboard.
 
Hintergrund ist hier, dass gemäß CapFrameX ein PDEP/PEXT (parallel bit deposit and extract) erforderlich ist und diese sind auf älteren Zen-CPUs nur via Microcode implementiert. Laut Anandtech haben diese bspw. auf Zen2 eine Latenz von 300(!) Taktzyklen. In Zen3 hat man diese Funktionalität nun hardwareseitig implementiert (bei Intel ist das schon seit vielen Jahren der Fall) und dort haben die Befehle nun nur noch eine Latenz von 3(!) Taktzyklen.
jein - also 3 zyklen sind es nicht - da sagt auch jeder compiler was deutlich höheres - woher anandtech ihre Zahlen haben wollen ist unbelegt. Aber ist auch relativ egal da die beiden Befehle absolut nicht für resizeableBAR benötigt werden. Die sind nur für einfache Bitmanipulationen notwendig die zusammen mit rBAR verwendet werden können aber selbst dann nur fürs setup und damit entsprechend extremst selten.

war mir SO auch neu!
wie ist das denn: wenn man das bios-update für nen Ryzen der 1. Gen. aufspielt, läuft ein 5xxx dann mit dem bios auch oder muss dann gefrickelt werden?
Ne, entweder oder. Und downgraden auf ein älteres UEFI das die 1ste Gen unterstützt wird generell NICHT unterstützt - da muss man bei jedem Board einzeln nachschaun ob der Hersteller eine Softwarelösung dafür bietet.
 
jein - also 3 zyklen sind es nicht - da sagt auch jeder compiler was deutlich höheres - woher anandtech ihre Zahlen haben wollen ist unbelegt. [...]
Das mit den 3 Taktzyklen müsstest du mit AMD ausdiskutieren. Gemäß deren eigener Dokumentation stehen erst mal 3 Zyklen im Raum. ;-)
"The AMD family 19h processor has native ALU support for PDEP/PEXT, so one such instruction can be sustained per cycle, with a three-cycle latency for producing the result."

Darüber hinaus scheint sich die Fragestellung jedoch bzgl. zumindest dieser Abhängigkeit aufgelöst zu haben. Ian Cutress hat hier von AMD als Feedback erhalten:
"Smart Access Memory does not depend on the performance of the PDEP instruction."
So viel zu Thema Qualitätsjournalismus oder alle schreiben nur reihum unreflektiert voneinander ab? ;-) Vielleicht wird es dann doch noch was damit auf älteren Zen-CPUs. Auch darf man gespannt sein, ob die MB-Hersteller bei Intel-Hardware weiter zurückgehen werden als nur den aktuellen CML zu enablen.
Ich würde aber vermuten weiter zurück als zu Zen2 und vielleicht dem Coffee Lake Refresh werden sich beide Hersteller nicht bewegen, zumindest nicht freiwillig. ;-) (Und eine vergleichbare Fragestellung ergibt sich auch mit einem Blick auf Turing und RDNA.)
 
Zuletzt bearbeitet:
Spannendes Thema, gerade in Sicht auf weitere Optimierungsmöglichkeiten, hier hat eventuell AMD noch n fetten Spirtzer mehr aufm Sack als "Konkurrenten". Jetzt schau ma mal.
 
Also ich bezweifle dass AMD hier noch was relevantes für die älteren Prozessor-Modelle bringt.
(Allerdings erwarte ich da von Intel auch nicht viel...)
Wie einige Quellen ja bereits berichtet haben scheint das Feature bei älteren AMD Modellen nicht in Hardware vorzuliegen, wobei es bei Intel wohl bereits mit Haswell in implementiert wurde.

Ist auch nicht weiter verwunderlich, meines Wissens nach ist dieses Feature im Server- und Workstationbereich
schon länger gängig und wurde ja bereits mit der PCIe 3.0 Spezifikation eingeführt. Da sind auch massive Speichertransfers zu Karten mit Entsprechendem Speicherausbau an der Tagesordnung.

Gamingkarten hatten bis dato wohl einfach keine Speichermengen bei denen dieses Feature sinnvoll wäre.

Hinzu kommt noch der entsprechende Aufwand bei Implementierung in Fw und Treibern inklusive Validierung,
was natürlich alles zu zusätzlichen Kosten führt...
 
ich dachte, dass 1000-er Ryzen nicht lauffähig sind in 500-er chipsätzen...:ka:
Doch, mit entsprechenden Bios Update.
Auf Beta Bios ging es auf jedenfall noch und wurde anschließend gestrichen. Ich meine der Support kam zurück als ein Athlon auf Zen1 Basis released wurde da die den selben Microcode benötigen.
wurde -meines wissen nach- nie so gesagt.
Kein Support heist eben nicht unbedingt das die inkompatibel sind.
Mein alter 1700X lief wunderbar auf X570 I AORUS PRO WIFI (rev. 1.0) bis er rausgepatcht wurde.
(meine bis Bios F11)

OFFIZIELL sind laut AMD Ryzen-1000-CPUs und -2000-APUs inkompatibel zum X570 sowie alle Ryzen 1000, 2000 und -3000-APUs zu B550 und A520. Inoffiziell haben die ersten UEFI-Versionen (i.d.R. bis einschließlich AGESA Combo-Pi 1.0.0.3) aller von mir geprüften X570-Boards alle Ryzens akzeptiert. Während der rund 8 Monate nach dem X570-Launch, in dem die UEFI-Fertigentwicklung von 1.0.0.3a bis einschließlich 1.0.0.3abba lief, ging es dann bei keinem Hersteller.

Seit dem bugbereinigte UEFIs auch als final verfügbar sind, also seit AGESA 1.0.0.4 geht es wieder bei allen Herstellern außer Asrock. Die sind zugleich auch die einzigen, die die damals releasten Zen-1-basierten Athlon-APUs nicht in ihrer Kompatibilitätsliste führen und in der Praxis auch nicht unterstützen, obwohl diese laut AMD auf allen AM4-Plattformen laufen sollen.

Beim B550 wiederum sollten sowohl Zen als auch Zen+ laut AMD nirgendwo laufen können, praktisch habe ich Asus-, Biostar- und MSI-Mainboards damit gebootet. Asrock geht weiterhin nicht, Gigabyte ging vor einigen Monaten nicht – aktuelle Tests stehen gerade aus. Ich würde mich aber nicht wundern, wenn die nachgebessert haben, schließlich gibt es 4000er APUs weiterhin nur als OEM-Pro-Version und was soll man auf einem Retail-A520-Board sonst betreiben? Einen 5950X?

#aberbeiIntelherrschtSockelchaos
 
Zurück