News Ryzen 5000 und Radeon RX 6000: AMD zeigt Benchmarks zu Smart Access Memory

[xammu]

Also 5 - 10% Mehrleistung. Nun bin ich am Überlegen, ob dass, abgesehen von längeren Balken bei Benchmarks, in irgendeiner Situation Sinn macht.

Irgendwo im CB Forum gibt es einen Artikel über das Übertakten von ein paar wenigen Prozent und dessen weitestgehender Sinnlosigkeit.

Sehe ich hier genau so. Wo machen 10% den Unterschied zwischen Unspielbar und Spielbar aus? Wir reden hier außerdem von den Topmodellen einer Generation, welche eigentlich jedes aktuelle Spiel akzeptabel und flüssig meistern sollten.

Wenn aus 40 FPS nun 44 werden. Ist das viel besser?
Oder aus 100 FPS 110?

Und da selten Windows und Spiele alleine laufen, wird in der Realität dieses Effekt meiner Meinung nach verpuffen.
Dann lieber die Grafikregler eine Stufe nach links, kostet nichts und der Effekt wird größer sein

AMD wird bei diesem Benchmark auch die Spiele mit den größten Unterschieden heraus gesucht haben, also dürfte sich das bei um die 0-5% einpegeln.

Allerdings gebe ich zu, dass man Abwarten sollte, wie die Spieleentwickler dieses Feature annehmen werden.

Und hier wieder meine Meinung, da es dazu eine spezielle Kombination aus CPU und GPU benötigt, eher gar nicht.

 

[mad-onion]

Sorry aber woher nimmst du die Info?? AMD selber schreibt 500er Chipsätze, dazu zählt auch der A520?!?

MfG

Entschuldige bitte, ich habe tatsächlich nicht mitbekommen, dass es bereits 20 A520 Mainboards im deutschen Markt gibt, daher habe ich diesen Chipsatz nicht aufgeführt. Meine Infos erhalte ich direkt von den üblichen Quellen, wie z.B. AMD. Nun da ich davon Notiz genommen habe, frage ich mich selbst auch, ob der A520 unterstützt wird. Offiziell heisst es ja 500 Series, von den üblichen Newsseiten werden in den von mir gelesenen Artikeln oder gesehenen Videos bisher nur X570 und B550 genannt, wahrscheinlich weil den A520 viele für einen Office-Ableger halten, der im Gaming-Sektor keine wirkliche Rolle spielen dürfte. Aber generell stimmt was du sagst. 500 Series beinhaltet auch den A520.
Ich denke, unter Umständen, sollte es genug Relevanz haben, werden wir auch das zum Launch der RX6000 in den Tests erfahren

 

[dastash]

Überlanges Zitat entfernt

Alles gut. :-)
Ich finde die Frage nur deshalb so interessant, weil der A520 quasi identisch dem B450 ist und da geht SAM ja nicht also stellt sich mir die Frage, ist das gewollt um die neuen Boards/CPUs zu pushen oder aber und auch das schließe ich nicht aus, gibt es technische Gründe, warum das nur dort supportet wird, mit oder ohne A520.

MfG

 

[foo_1337]

Intel wird mit Sicherheit nicht Nvidia unterstützen.

Da es sich hier um generische x86 bzw. PCIe Features handelt, hat das alles relativ wenig damit zu tun, ob Intel einen GPU Hersteller "unterstützt", oder nicht. Es liegt allein an nvidia, das entsprechend in den WDDM Treiber zu implementieren. Via Xeon und Quadro/Tesla/A100 ist das schon länger so in Benutzung. Nur eben in einem völlig anderen Kontext.
So sieht das ganze im vCenter und einer V100 aus. Man sollte immer den doppelten Wert vom VRAM nehmen.

 

[Teralios]

So sieht das ganze im vCenter und einer V100 aus. Man sollte immer den doppelten Wert vom VRAM nehmen.

Ich muss ehrlich sagen: Ich finde es spannend, was bei AMD in letzter Zeit passiert und das AMD langsam aber sicher aus ihrer HSA Entwicklung, als auch eben aus den Bemühungen ziehen kann.

Ebenso spannend ist, dass immer mehr Techniken aus dem Bereich der Virtualisierung, die dort primär dazu dienten die Leistung best möglichst mit den Gastsystemen zu nutzen, auch von AMD aufgegriffen werden um eben auch ihre Hardware direkt im System besser ansprechen und auslasten zu können.

Egal was man sagt, AMD zeigt durchaus, dass sie pfiffig sind, was solche Sachen angeht und sie dann Wege einschlagen, bei denen man sich fragt, warum sie eigentlich noch kein andere gegangen ist, weil es eigentlich so offensichtlich ist.

Ein Dozent hat mal gesagt, dass wir in der Entwicklung oft zu sehr auf »Komplexe« Entwicklungen hinarbeiten und deswegen die offensichtlichsten Wege übersehen.

 

[foo_1337]

Egal was man sagt, AMD zeigt durchaus, dass sie pfiffig sind, was solche Sachen angeht und sie dann Wege einschlagen, bei denen man sich fragt, warum sie eigentlich noch kein andere gegangen ist, weil es eigentlich so offensichtlich ist.

Jap, definitiv!

 

[Teralios]

@foo_1337

ich glaub, ich hätte noch eine Möglichkeit, warum man SAM eventuell nicht auf Zen, Zen+ und Zen 2 bietet. Geh gerade den Test hier durch und seh mir die Folien an und:

Vorletzter Punkt: »MPK: Memory protection keys, user data access/write permission via 4-bit key in leaf page table.«

Was denkst du?

 

[foo_1337]

Interessant, dass AMD das vorher nicht hatte. Ich sehe jetzt zwar keinen direkten Zusammenhang, aber es ist eben eine zusätzliche Sicherheitsschicht um den Speicher zu schützen. Gut Möglich, dass AMD dann SAM nur damit in Kombination erlaubt, da das ganze tatsächlich auch kritisch unter dem Aspekt der Sicherheit zu sehen ist.

 

[Xargan]

Hier steht u.a. zu MPK und Co. noch was drin, vielleicht hilft das bei euer Suche, ich versteh da zu wenig von
https://www.amd.com/system/files/TechDocs/24593.pdf

 

[Coeckchen]

Schön dass AMD nur titel zeigt die gern ins GPU Limit gehen. Wie siehts bei Anno aus?

 

[LordSoth]

Ich hoffe sehr, dass das der Beginn einer Entwicklung hin zu gemeinsamem System-Speicher ist, man also irgendwann in der Zukunft nur noch dick RAM auf's Board klatschen muss und es keinen gesonderten VRAM mehr gibt.

Das wird so schnell nicht passieren, dafür ist der normale RAM einfach (noch) viel zu langsam.
Sollte man schnellen VRAM allerdings in großer Stückzahl und ausreichender Größe schnell über einen RAM Sockel an die CPU anbinden können, wäre das natürlich ziemlich cool.

 

[Teralios]

Interessant, dass AMD das vorher nicht hatte.

Stimmt schon, aber das ist halt auch einer der möglichen Punkte.

Auch wenn man per Linux und Windows »abstrahiert« entsprechende Funktionen anbieten kann, unterhalb dieser Funktionen sind halt die Prozessoren und deren Möglichkeiten und Eigenheiten und im »Treiber« liegen dann halt manchmal auch die Details.

Gut Möglich, dass AMD dann SAM nur damit in Kombination erlaubt, da das ganze tatsächlich auch kritisch unter dem Aspekt der Sicherheit zu sehen ist.

Genau das ist für mich da der Punkt. Vor allem oder gerade wenn man da an die letzten Meldungen denkt: https://www.techpowerup.com/273113/...ave-a-createallocation-security-vulnerability

Bildet man den VRAM in den normalen Adressraum für die CPU ab, dann gibt es so einigen bösen Schabernack, den man dann anstellen kann.

So etwas sollte man natürlich gegen unberechtigte Zugriffe auch auf CPU-Ebene dann absichern, und so könnte es durchaus auch ein berechtigter Grund sein, warum man erst Zen 3 unterstützt.

Ach, schade das ich damals nur Compiler-Entwicklung in der Uni belegt habe. XD

Das wird so schnell nicht passieren, dafür ist der normale RAM einfach (noch) viel zu langsam.

Die »Geschwindigkeit« ist nur ein Teil des Problems, denn »normaler« RAM selbst liefert durchaus auch die benötigte Bandbreite, Intel hat sich ja bei Xe DG 1 für LPDDR4 entschieden. Früher hat man zudem auch »normalen« RAM genutzt, eine »Trennung« fand eigentlich erst »wirklich« mit GDDR3 statt, bis dahin wurde oft eher DDR oder eben DDR2 verwendet. Als dann GDDR3 genutzt wurde, hat man dann auf günstigeren Karten gerne mal GDDR2 verbaut.

Sollte man schnellen VRAM allerdings in großer Stückzahl und ausreichender Größe schnell über einen RAM Sockel an die CPU anbinden können, wäre das natürlich ziemlich cool.

Selbst wenn man GDDR6 oder 6X per DIMM an die CPU hängen könnte, würde es nicht wirklich etwas bringen bei dGPU, die per PCIe mit der CPU verbunden sind, selbst wenn man den kleinen CPUs Quad oder gar Octa-Channel-Interfaces spendieren würde.

PCIe4 schafft auf 16 Lanes aktuell 32 GiB/s, PCIe5 ist bei 64 GiB/s. Um den Datenhunger einer modernen GPU zu stillen, reicht beides nicht. Selbst wenn man auf 32 oder gar 64 Lanes erweitern würde, wir wären bei PCIe dann bei 256 GiB/s.

Nur kommen dann eben auch Latenz-Probleme bei PCIe hinzu, um die Bandbreite von PCIe effektiv zu nutzen, muss man sehr gut »vorausplanen« können, kann man das nicht mehr, bricht die Bandbreite drastisch ein, zu mal sich hier dann sogar die Latenzen noch addieren.

Man müsste für die Anbindung »CPU« - »GPU« in dem Fall einen neuen Standard schaffen, der wesentlich höhere Bandbreiten ermöglicht, gleichzeitig jedoch auch möglichst geringe Latenzen hat, und wenn man bedenkt, dass aktuelle GPUs an 1 TiB/s knabbern und HPC-Karten sich bereits 2 TiB/s nähern, denn das ist mit PCIe 4 sowie 5 bei weitem nicht realistisch erreichbar, man bräuchte einen theoretischen bei PCIe5 einen x512 Slot und PCIe4 wären es ein x1024er.

 

[Piktogramm]

@Teralios & @foo_1337
Zu den MPK Befehlen:
https://www.systutorials.com/docs/linux/man/7-pkeys/
https://www.kernel.org/doc/html/latest/core-api/protection-keys.html

Das ist prinzipiell kein neues Feature, sondern erlaubt es die Rechteverwaltung im Speicher wesentlich effizienter abzuwickeln. Das ist für resizable BAR nicht notwendig und auch für die Performance in diesem Fall nicht. Denn wie schon richtig angemerkt wurde, PCIe ist sowieso vergleichsweise lahm. Da macht die teure Methode das Kraut nicht fett.

 

[Teralios]

Das ist für resizable BAR nicht notwendig und auch für die Performance in diesem Fall nicht. Denn wie schon richtig angemerkt wurde, PCIe ist sowieso vergleichsweise lahm.

Da lass ich aber dann mal kurz den »Entwickler« raushängen:
Auch wenn es nicht notwendig ist, egal warum, kann es aber z.B. durchaus so sein, dass es (1.) die Entwicklung vereinfacht und auch (2.) sicherer macht und der Code (3.) später besser zu pflegen ist, als wenn man ggf. die »komplexeren« Wege wählt, um den Support auf früheren Systemen zu ermöglichen, was am Ende dann ja auch wieder »Geld« ist.

Zumal: Ja PCIe ist durchaus »lahm«, aber das bedeutet allerdings nicht unbedingt, dass die Aufgabe in der CPU nicht doch »zeitkritisch« ist. Aber da könnte man jetzt lange diskutieren.

 

[Piktogramm]

Ich weiß nicht genau was du mit "der Code" meinst. Aber sowohl Anwendungen die auf den GPU Speicher zugreifen wollen als auch Treiber werden an der Stelle Syscalls nutzen. Die Syscalls abstrahieren die Rechteverwaltung der Speicherberwaltung. Weder die Entwickler der GPU-Treiber noch der Anwendung im UserSpace sollten sich mit diesen Details beschäftigen müssen.
Oder anders, wie oft kümmerst du dich als Entwickler um die Details der Speicher- und Rechteverwaltung auf Ebene von Assemblerbefehlen?

Edit1
Und die allwissende Datenhalde:
https://en.wikipedia.org/wiki/Intel_MPX
Wenn AMDs MPK nicht komplett etwas anderes macht, gibt es keinen Grund wieso man da resizable BAR an diese Funktion knüpft.

Und was Anderes, wenn man den GPU Speicher komplett ansteuert. Welchen Grund sollte es haben die Rechte auf diesen Speicherbereich all zu häufig zu ändern? Für Spiele eher unwahrscheinlich. Wenn überhaupt wäre das in meinen Augen relevant wenn man auf einer GPU mehrere getrennte compute Jobs laufen hat und/oder die GPU an Host + VM (oder mehrere VMs) durchreicht.

Edit2
Na gut, ich gehe davon aus, dass AMDs Implementierung weniger buggy ist

 

[foo_1337]

Die angesprochenen Syscalls sind u.a. mmap() und mprotect(). Und genau da helfen eben die MPK. Sieht man auch in deiner verlinkten manpage:

Protection keys work in conjunction with the existing PROT_READ/ PROT_WRITE/ PROT_EXEC permissions passed to system calls such as mprotect(2) and mmap(2), but always act to further restrict these traditional permission mechanisms.

Ob und wie das dann im Zusammenhang mit resizable bars steht ist nochmal ein anderes Thema.
Die Treiber selbst, also in diesem Fall das amdgpu drm modul, kann sich hier natürlich nicht nur auf syscalls verlassen, sondern muss direkt mit der hw "sprechen". Das Modul wiederum stellt dann entsprechende Syscalls für das xorg Modul bereit.

 

[tackleberry]

Gibt es von AMD irgendwelche Aussagen zur Performance der neuen Radeon Karten in Software für Kreative z.B. Videoencoding, Blender, etc.?

Wird es Smart Access Memory auch für die Zen3 Threadripper geben?

 

[ComputerJunge]

Gibt es von AMD irgendwelche Aussagen zur Performance der neuen Radeon Karten in Software für Kreative z.B. Videoencoding, Blender, etc.?

Danke für die Frage. Meine diesbezügliche ging in einem der Rot-vs.-Grün-Threads wie erwartet unter.

 

[mc_ace]

Info an die Fake News Fraktion:
Habe heute auch gelesen, dass AMD volle Raytracing Unterstützung für Cyberpunk 2077 direkt ab dem Launch erhält. Das zum Thema Gerüchte, dass Cyberpunk (ab Launch) kein RT für AMD bietet.
Dazu gab es nämlich keinerlei offizielle Informationen außer die Info aus einem veraltetem Interview. Quelle: PC Games Hardware.

 

[foo_1337]

Passt zwar nicht in den Thread, aber die Fakenews hat auch PCGH verbreitet

Uns liegt der Interview-Artikel aus der Printausgabe von PC Gamer vor, in dem laut den Berichten stehen soll, dass Cyberpunk 2077 zum Launch kein Raytracing auf Radeon RX 6000 bietet. Allerdings ist dieser Schluss im besten Fall nur indirekt möglich. Im Artikel wird die enge Zusammenarbeit von CDPR und Nvidia erwähnt, was ja bereits in den vergangenen Monaten durchgeklungen ist.

Das war damals schon alles andere als ein Fakt. Die Quelle jetzt ist Brian Burke von nvidia. Also durchaus vertrauenswürdig.