News Smart Access Memory: Ryzen 3000 und Vorgängern fehlt es an Hardware-Support

foo_1337 schrieb:
Was ist an dem Artikel falsch
der artikel verknüpft smart memory access aka resizable bar zwingend mit der cpu-instruktion "_pdep_u32". das sind allerdings zwei unabhängige sachen. man kann ohne probleme rbar implementieren, ohne diese instruktion zu verwenden. und das ganze funktioniert auch schon seit einiger zeit auf hardware pre zen3/rx6000.

auf twitter wurde gepostet, dass "_pdep_u32" in directx verwendet werden kann und da diese instruktion erst mit zen3 performant im vergleich zu den vorgängern ist, wird hier gleich ein riesen fass aufgemacht, dass rbar nur mit zen3 funktioniert. rbar ansich ist aber nicht nur für gamingkisten relevant - auch wenn einige in diesem forum glauben, dass gaming der nabel der welt ist...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: elvis2k1
Ich würde ob des Budgets von Nvidia erwarten, dass das sukzessive in den Treiber implementiert wird. Mal guggn
 
"Smart Access Memory: Ryzen 3000 und Vorgängern fehlt es an Hardware-Support" - was soll man da anders interpretieren?
 
0x8100 schrieb:
"Smart Access Memory: Ryzen 3000 und Vorgängern fehlt es an Hardware-Support" - was soll man da anders interpretieren?
Du sprichst von resizable Bar. Der Artikel von SAM. SAM bedeutet aber Performance Boost durch resizable BAR. Der ist aber ohne PDEP/PEXT nicht gegeben.
 
0x8100 schrieb:
"Smart Access Memory: Ryzen 3000 und Vorgängern fehlt es an Hardware-Support" - was soll man da anders interpretieren?
Wenn die Performance der Emulation völlig unzureichend ist, dann kann man es durchaus als fehlenden Support betrachten, obwohl die Funktionalität grundsätzlich existiert. Am Ende es Tages zählt die Praxistauglichkeit als KO-Kriterium.
 
  • Gefällt mir
Reaktionen: Col.Maybourne und foo_1337
die microsoft doku selbst schlägt "_pdep_u32" nur als eine möglichkeit vor, um einen standard swizzle zu berechnen - das ist kein "must". ich bezweifle jetzt einfach mal, dass ihr einen benchmark habt, der die adressberechnung mit "_pdep_u32" mit einer optimierten alternative vergleicht.
 
  • Gefällt mir
Reaktionen: elvis2k1
DSOGaming hat den Tweet von @ZeroStrat auch aufgegriffen und einen sehr guten Artikel dazu verfasst:
https://www.dsogaming.com/news/amd-...tel-cpus-since-4th-generation-are-compatible/

Auszug:

PDEP/PEXT is used in conjunction with resizable BAR to quickly move the data to and from the GPU. Resizable BAR on the other hand is used to map the GPU’s VRAM to a corresponding CPU-addressable space, and then PDEP/PEXT is used to move the data to and from it.

Without PDEP/PEXT, just having a resizable BAR isn’t very helpful in terms of GPU performance.


Auch interessant:
https://github.com/dolphin-emu/dolphin/commit/f36c73585636dcd81119bd46f0b0c13982570f15
 
  • Gefällt mir
Reaktionen: LukS, bad_sign, Tanzmusikus und 2 andere
super, einen artikel, der sich auf euren tweet bezieht als beweis für euren tweet heranziehen... und getestet wurde dort auch nichts.

den dolphin-commit kannst du auch wieder vergessen. der zeigt nur, dass PDEP/PEXT auf pre-zen3 cpus langsam ist, das hat noch nichts mit sam zu tun. die instruktionen dort werden für die emulation der cpu der wii benutzt, nicht für die grafikausgabe.
 
Lies doch einfach mal, was über dem Dolphin Link so steht. Und dann beweise du bitte mal zur Abwechslung, dass PDEP/PEXT hier irrelevant ist. Was ist eigentlich dein Claim? Dass AMD lügt und einfach künstlich alles <Zen3 blockiert?
 
Wahnsinns Leistung von @foo_1337, @Teralios und @MichaG und ein Artikel, der endlich mal Licht ins Dunkle bringt. Danke Männer, super Arbeit.

Liebe Grüße
Sven
 
  • Gefällt mir
Reaktionen: eddi99, bad_sign, Colindo und 3 andere
Klar, um die 16GB VRAM einer 6800XT dynamisch adressieren zu können, braucht's keine native, performante Swizzle Funktion... :freak:
 
  • Gefällt mir
Reaktionen: Colindo
danyundsahne schrieb:
Gibt auch schon Tests mit der Z490 Platform. Bringt schon ordentlich Leistung wie ich finde....wesentlich mehr als manche hier mit 1-2% ankommen.
Es sind schon wesentlich mehr:
https://www.techpowerup.com/275538/...-platform-with-resizable-bar-amds-sam-enabled
kommt immer darauf an, wie sie testen. bei CB warens nur 1 stellige % bereiche und wenn ich eh schon 100 fps+ habe, dann jucken mich 5-10-20 fps mehr auch nicht wirklich, als durchschnitt. natürlich eignet sich so eine implementierung fürs marketing und nen ordentlichen preisaufschlag. ich frage mich nur, warum geht es angeblich nur ab amd 5000 cpus und warum kann das intel und nvidia nun auch? geht es nur mit 5000er cpus, damit sie sich besser verkaufen, da ja die ryzen 3000er technisch nicht anderster aufgebaut sind wie die 5000er
 
AMD könnte die älteren Ryzen dafür auch freischalten aber das wäre reichlich sinnlos wenn dadurch sogar Leistung verloren geht.
zudem ist die Leistungssteigerung vor allem bei min FPS und nicht bei den eher unwichtigen Max/Average
 
foo_1337 schrieb:
Lies doch einfach mal, was über dem Dolphin Link so steht. Und dann beweise du bitte mal zur Abwechslung, dass PDEP/PEXT hier irrelevant ist. Was ist eigentlich dein Claim? Dass AMD lügt und einfach künstlich alles <Zen3 blockiert?
niemand behauptet, dass PDEP/PEXT irrelevant ist. aber es geht eben auch ohne. sonst würde dolphin nicht einen workaround für die langsame amd-variante benutzen. zudem benutzt man es in dolphin hauptsächlich für die cpu-emulation - die berechnung der meist relativ simplen grafik alter konsolen ist nicht das problem. man muss diese instruktion für sam nicht benutzen, mit einer performanten implemetierung geht es aber einfacher.

zu dem verlinkten artikel: "However, it appears that the PCI-Express root complex of Ryzen 5000-series processors introduces a PCI-E physical-layer feature called full-rate _pdep_u32/64, which is required and necessary for resizable-BAR to work."

wie kann bitte eine cpu-instruktion teil des physical-layers von pci-e sein?! und zum drölzigsten mal: "_pdep_u32" ist NICHT "necessary for resizable-BAR to work."

mein claim hier ist übrigens: sam aka resizable bar ist ein alter hut. nur weil es jetzt für grafikkarten unter windows benutzt wird und amd das als marketing für aktuelle produkte hernimmt, tut man hier so als wäre das der neueste geile scheiss. ob amd lügt, überlasse ich dir. unter linux jedenfalls haben amd-entwickler es schon lange auch für ältere hardware implementiert.
 
  • Gefällt mir
Reaktionen: nazgul77, Tanzmusikus und elvis2k1
Der Link zum Dolphin Repo sollte verdeutlichen, wie langsam die Emulation ist. Dass Resizable Bars ein alter Hut ist, ist nichts neues und wenn du nach bar und meinem Nickname hier im forum suchst, wirst du auch sehen, dass ich das bereits unmittelbar nach der SAM Vorstellung hier thematisiert habe (https://www.computerbase.de/forum/t...nchmarks-in-4k-und-wqhd.1977954/post-24813476). Damals bin ich noch, vermutlich ähnlich wie du jetzt, davon ausgegangen, dass das eine künstliche Limitation ist.
BTT: Dass die CPU Zugriff auf den vollen(!) VRAM der Grafikkarte bekommt ist ja nett, aber die CPU muss ja auch irgendetwas damit machen. Und genau jetzt kommt PDEP/PEXT ins Spiel. Und der Dolphin "Workaround" hilft hier eben nicht, wie auch?
Und PDEP/PEXT aufgrund der Microcode "Emulation" nun schnarchlangsam ist, hat man genau was gewonnen? Richtig: Nichts und deshalb gibt es kein SAM für <Zen3.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: LukS, 4nanai, Zarlak und 2 andere
foo_1337 schrieb:
Der Link zum Dolphin Repo sollte verdeutlichen, wie langsam die Emulation ist.

und jetzt nehmen wir mal den code und die gegenüberstellung von twitter:

Code:
 if (cpu_info.bFastBMI2)
  {
    // Extract bits 0-1 and 5-34
    MOV(64, R(RSCRATCH), Imm64(0xc7ffffffe0000000));
    PEXT(64, RSCRATCH, RSCRATCH2, R(RSCRATCH));
  }
  else
  {
    // We want bits 0, 1
    MOVAPD(XMM1, R(XMM0));
    PAND(XMM1, MConst(double_top_two_bits));
    PSRLQ(XMM1, 32);

    // And 5 through to 34
    PAND(XMM0, MConst(double_bottom_bits));
    PSRLQ(XMM0, 29);

    // OR them togther
    POR(XMM0, R(XMM1));
    MOVD_xmm(R(RSCRATCH), XMM0);
  }

EmshLqmXcAAWPr1.png


statt eines MOV und PEXT haben wir also 7 andere operationen. da diese aber nicht per microcode emuliert werden, haben wir hier sicherlich nicht die 300 takte latenz. also kann man mit einer PEXT alternative immer noch gut mit rbar arbeiten.
 
  • Gefällt mir
Reaktionen: elvis2k1
Zurück
Oben