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

[Teralios]

komm mal von der aggro-spur runter... nichts was du schreibst widerspricht dem von mir gesagten.

Gut, es war unangebracht, dass ich dich so angegangen bin, entschuldige. Aber ich würde dich an der Stelle bitten auch zu lesen, was ich geschrieben habe und ebenso bitte ich, dass du auch auf die Zeitpunkte eingehst, denn das ist jetzt wichtig.

Vorweg: Was ich jetzt schreibe geht nun tief in die Technik hinein und in dem Fall muss ich auch sagen, dass ich dir auf der einen Seite widerspreche, gleichzeitig aber auch zustimme. Es ist jetzt aber wichtig: Es kommt drauf an!

Fangen wir an: Ja du hast recht Resizable BAR wurde bereits 2008 mit PCIe2.1 oder halt eben PCIe3 eingeführt. Wobei wir jetzt etwas genauer sein müssen: Wir sprechen von der Möglichkeit, dass man per PCIe eben nun neben 32Bit-Adressraum - bis zu 6 - auch einen großen 64Bit-Adressraum. Die bis zu 6 BARs sind wichtig für die »Gast-Virtualisierung«, deswegen benötigt VFIO auch eine Virtualisierungsunterstützung bei i386/x86/x64 eben AMD-VI oder Intel Vt-d. Aber damit genug.

Die MMIO - übernimmt das Addressmapping in der x86-CPU - ist 32Bit-Breit, BAR 64Bit. Man muss nun also aus einem 64Bit-BAR Wort eben 2 32Bit Worte für die MMIO machen. Wie das funktioniert anhand von einer Maskierung habe ich hier gezeigt 64Bit-Wortes auf 2 32Bit-Worte hier gezeigt.

Und genau das ist nun mein (1.) Punkt: Genau diese Maskierung wird im Linux-Kernel genutzt und - auch durch deinen Twitter-Einwurf - vermutlich auch unter Windows. Sie dazu pci.c. Sobald man auf PCI schreibt - PCIe baut auf PCI auf, deswegen heißt es so - findet man hier sehr viele vfio_mask und vfio_unmask Funktionen und in den entscheiden Bestandteilen für die BAR findet man auch entsprechende Wortbreite der BAR, dass entsprechende Fallunterscheidungen genutzt werden. Natürlich weitaus ausgefeilter und eleganter als ich es beschrieben habe. Wir wissen also, welches Prinzip hier genutzt wird um mit den BAR-Adressen hantiert wird. Jetzt kommt der nächste Punkt: Die Entwicklung für den 64Bit-BAR wurde ab 2015 eingeleitet und erst 2017 offiziell in den Linux-Kernel aufgenommen - also zu einem Zeitpunkt, als sowohl AMD als auch Intel pdep sehr wohl als in die x86-ISA aufgenommen wurde.

Natürlich hast du recht: Diese Maskierung lässt sich auch per Bit-Operationen und Byte-Operationen nachbauen und auch das passiert im Linux-Kernel, gleichzeitig haben wir hier aber auch ein nächsten Beweis, dass, sofern möglich in der x86-Welt eben pdep verwendet wird:

https://github.com/qemu/qemu/blob/master/target/i386/translate.c
https://github.com/qemu/qemu/blob/master/target/i386/int_helper.c
https://github.com/qemu/qemu/blob/master/disas/i386.c

Du kannst dir das nun ansehen. Man hat mit der Einführung der Maskierungsfunktionen von x86 mit der Arbeit an dem erweiterten BAR-Support begonnnen und für Hardware, die diese Funktionen nicht habe, entsprechende Helfer definiert, sodass es funktioniert.

Und damit kommen wir halt zum letzten Punkt: Natürlich kannst du die 64-Bit BAR auch nutzen, wenn eine CPU keine pdep oder eine ähnliche Funktion hat - man implementiert es ja für die µArch, nur die Frage ist dann: Bringt es den erhofften Leistungsschub. Wir bisher nur: pdep wird seit Haswell als Hardware-Funktion mit einer gergingen Latenz - ich nehm jetzt einfach mal die 3 von Zen3, wenn wer die genaue Latenz kennt, bitte sagen. Excavator bis Zen 2 benötigen aber 300 Cyle und damit um den Faktor 100 mehr, in Software könnte es noch schlimmer sein, aber da habe ich keine Zahlen und jetzt auch keine Lust es zu ermitteln, wie lange es braucht. Wir wissen also: Nativ > per Microcode > per Software.

Das bis jetzt sind die Fakten! Ab hier wiederum bewegen wir uns durchaus in den Vermutungen und bilden aus den Fakten als auch unserem Wissen Indizien und jetzt bitte beachten: Keiner von uns, weder @ZeroStrat noch @foo_1337 als auch haben bisher gesagt, dass es wirklich so ist, sondern dass es eine Theorie ist und in der Wissenschaft ist es erlaubt eine Theorie auf Fakten sowie auch Vermutungen aufzubauen, sofern man es argumentativ verbinden kann!

Also ja, du hast recht, dass theoretisch alle CPUs einen Support für Resizable-BAR bieten kann, sofern sie PCIe2.1 oder 3.0 beherrscht, man kann in Software sehr viel nachbilden. Die Frage ist dann aber immer: Ist es sicher (vfio sichert den VRAM als auch den RAM per AMD-VI als auch Intel Vd-t ab), ist es sinnvoll (ich könnte auch eine 16Bit-CPU mit einem 64Bit-Adressraum schaffen oder eine MMIO mit nur 16 Bit nutzen, um die 64Bit des BAR abzubilden, wird dann nur ein Code-Monster) und ob es auch schnell genug.

Und genau dieses »Schnell genug« ist in dem Fall der wichtige Punkt und das ist etwas, was ich von Anfang angesagt habe: Ja BAR/SAM kann man vermutlich auch bei Zen 2 und davor nutzen, die Frage ist dann aber, ob es was bringen würde. Wir sehen bereits jetzt - auf Zen 3, sowie Rocket Lake? Canon Lake? ich komm da durcheinander gerade - dass SAM eben nicht in jeden Fall etwas bring (0 %) oder eben durchaus auch mal 10 % und mehr. Zen 3 braucht für die Maskierung pro Aufruf 3 Cycle und wir haben 0 % - 10 % und laut AMD im Mittel 5%. Alle Intel - seit Haswell - brauchen 3 Cycle (Ja ich weiß, ich nehme es an, wer die genaue Zahl weiß, bitte schreiben) - es zeigt sich auch hier, dass es Intel auch bis zu 10 % bringen kann. Daraus ergeben sich nun folgende Indizien:

Indiz 1: pdep wurde zwischen Zen 2 und 3 massiv beschleunigt - Faktor 100. Es ist durchaus valide daraus zuschließen, dass SAM also in Windows pdep nutzt - Linux nutzt es ja, sofern möglich.

Indiz 2: pdep wird bei allen Intel CPUs, die nun SAM nutzen können, auch schnell ausgeführt, auch hier beobachten wir die bis zu 10 %. Erneut ist es valide daraus zuschließen, dass SAM genau diese Funktion nutzt.

Indiz 3: Tests zu BAR unter Linux zeigen - entschuldige, ich finde den Link gerade nicht - zeigen für BAR teilweise - auf älteren Plattformen - im Schnitt »keine« Verbesserung oder maximal 1 % - ich weiß nicht ob jetzt @foo_1337 oder @Colindo diese Ergebnisse gefunden hatte.

Indiz 4: Ist die Grafikkarte für die CPU »zu schnell«, dann zeigt BAR auf Zen 3 seine Stärken, weil die üblichen Abfragen mit 256 MB (16Bit-BAR) hier durchaus Zeit fressen. BAR mit 64Bit wiederum können bis zu 10 % bringen. Daraus ergibt sich der Schluss, dass BAR im CPU-Limit etwas bringen kann.

Und daraus kann man nun sehr wohl - alle Fakten und die Indizien - nun zumindest die These aufstellen: Sollte eine CPU pdep nicht nativ unterstützen oder zu langsam, dann ist der Gewinn gegenüber dem bisher verwendeten 16Bit-BAR mit 256 MB bei »Grafik« nicht vorhanden oder zu vernachlässigen.

Eine »Erweiterung« der These - auch das ist valide: Sieht man sich an, dass Zen 2 um den Faktor 100 mehr Latenz hat, kann man durchaus sich Fragen, ob der klassische 16Bit-BAR nicht eventuell schneller arbeitet. Auch hier gilt: Zen 2 benötigt mindesten 300 Cycle für pdep. Entscheidend ist hier, wie viele 256 MB-Blöcke kann die CPU in der Zeit effektiv abfragen und wie viele benötigt sie im Schnitt.

Die Kombination dieser beiden Thesen ist also: Auf Zen 2, Zen+ sowie Zen könnte es sein, dass SAM keine Leistungssteigerung bringt und im schlimmsten Fall könnte es sogar Leistung kosten.

Und jetzt kommen wir zu dem entscheiden Punk: Wir sprechen hier natürlich immer über Spiele. Bei der »Virtualisierung« - hier arbeitet man aber eher mit den bis zu 6 BARs des PCIe-Protokolls - als auch bei HPC-Anwendungen kann das schon wieder ganz anders aussehen, da stimme ich dir sogar zu und da könnte es schon wieder anders aussehen und selbst ein langsames pdep als auch eines per Software könnte was bringen, aber: Darum geht es in dem Fall nicht!

Wir haben - also @ZeroStrat, @foo_1337 und ich - nun unsere Argumente - Fakten und Indizien - auf den Tisch gepackt und auf diesen aufbauend eine These entwickelt. Es ist nun an dir als auch die andere Person, wenn ihr diese These für falsch haltet, entweder (1.) neue Fakten zuliefern, die unsere These und/oder Indizien überholen, (2.) zu beweisen, dass unsere Indizien falsch sind oder (3.) dass unsere Schlussfolgerung auf fehlerhafter Logik beruht.

Es reicht dabei aber nicht, dass du als auch die andere Person jedes Mal behaupten, dass alles falsch ist, was wir schreiben und wir es beweisen müssen, denn das haben wir bereits getan mit den Fakten als auch Indizien und wie bereits geschrieben: In der Wissenschaft ist es valide eine Theorie auf Fakten sowie Indizien aufzubauen, sofern man es nicht besser weiß.

Deswegen jetzt als ganzes: Entweder ihr beiden schafft es nun auf einer ordentlichen Ebene argumentativ euch mit unserer These auseinander zusetzten und ihr bringt nun wirklich Gegenargumente mit Fakten sowie eigenen Indizien, dann bin ich auch gerne bereit mit dir als auch dem anderen auf einem sachlichen und auch höflicherem Niveau zu diskutieren.

-- Da es bis jetzt gedauert hat, bleibt es so stehen aber ich reagiere direkt auf deinen Beitrag

Danke, dass du diesen alternativen Code-Pfad hier anbringst, aber ich gebe da jetzt ein paar Sachen zu bedenken, ich habe den Code gesehen.

1. Brauchen wir hier die Latenzen der Befehle.
2. Brauchen wir hier auch noch die Latenz, die durch die Verwendung der SSE/AVX-Register anfällt.
3. MConst und R müssten wir noch auflösen, welche Befehle dahinter stehen.

Das heißt, ich lasse das durchaus gelten als Einwurf, aber es ist halt eben auch kein Beweis, dass unsere Schlussfolgerung falsch ist.

@foo_1337 ich bin jetzt einfach zu müde, hast du nicht Lust mal den Code durch die Maschine zu jagen?

 

[janer77]

@Berserkervmax : irgendwo gab es nen Test mit aktuellen Spielen die nicht speziell auf RTX zugeschnitten waren, da sieht die RX6xxx Serie gar nicht schlecht aus in RT.

 

[TxKreator]

ich hab mich auch schon mit foo gestritten das es was anders sein könnte (und eben darauf aufbaut), Ich wurde darauf hingewiesen, dass es das ist : Punkt Ende aus.. jetzt sind es plötzlich nur Vermutungen.
Herrlich.
Zugegeben ist es schlüssig, auch nachdem ich mich in das Thema eingearbeitet habe.
Aber wie man sieht spielt die HW halt auch eine rolle.
Was wiederum zeigt SAM (Marketingname) ist halt doch was anderes als rBAR weil es eben (für AMD zu mindestens) die neue HW voraussetzt.

Auf der offiziellen AMD Seite steht in der Fußnote übrigens auch :

AMD Smart Access Memory wird nur von Grafikkarten der AMD Radeon RX 6000 Serie unterstützt. Nicht für andere Grafiklösungen validiert.

Was so viel heißen könnte wie geht nicht weil wir es nicht testen wollten.

 

[0x8100]

@Teralios ein schöne zusammenfassung. und sie sagt, dass es technisch geht, aber nicht unbedingt was bringen muss. und genau das widerspricht dem artikel, der sagt, dass es hardware-technisch mit pre-zen3-cpus nicht geht.

"Nachdem AMD mit Smart Access Memory (SAM) für mehr FPS in Spielen durch Vollzugriff der Ryzen-5000-CPUs auf den Videospeicher der Radeon RX 6000 sorgt, stellte sich die Frage, ob dies auch mit älteren CPUs funktioniert. Auf Seiten von AMD ist dies zu verneinen."

"Sorry, I didn't know that but this is technically impossible. Maybe they could emulate it, but it would be extremely slow."

es wäre eben nicht "extremely slow", weil man nicht das per microcode emulierte pext benutzen muss, sondern alternativen hat.

Was wiederum zeigt SAM (Marketingname) ist halt doch was anderes als rBAR

wenn mit alex deucher ein amd-mitarbeiter und gpu-entwickler sagt, dass sam == rbar ist, dann glaube ich ihm das
"Smart Access Technology works just fine on Linux. It is resizeable BAR support which Linux has supported for years (AMD actually added support for this), but which is relatively new on windows. You just need a platform with enough MMIO space. On older systems this is enabled via sbios options with names like ">4GB MMIO"."

 

[foo_1337]

@TxKreator Da ging es darum, dass SAM = rBAR und nicht darum, weshalb <Zen3 davon nicht profitiert. Und das bestreitet hier auch keiner (außer ggf. Du).

@Teralios Ich habe nur ein lahmes Haswell Macbook, aber ich teste das mal.. So lahm wie der compiliert, dauert es aber vermutlich bis morgen, denn ich muss ja nochmal ohne PDEP/PEXT für intel compilieren. Aber immerhin scheint mein Build Env ok zu sein:

 

[TxKreator]

@foo_1337
ich bestreite gar nichts das liest gerade nur du

 

[ZeroStrat]

es wäre eben nicht "extremely slow", weil man nicht das per microcode emulierte pext benutzen muss, sondern alternativen hat.

Und eben genau das könnte ja dennoch um ein Vielfaches langsamer sein, also "extremely slow". Das "technically impossible" ist allerdings eine falsche Aussage.

 

[foo_1337]

@foo_1337
ich bestreite gar nichts das liest gerade nur du

Ich hab mich auch schon mit foo gestritten das es was anders sein könnte (und eben darauf aufbaut), Ich wurde darauf hingewiesen, dass es das ist : Punkt Ende aus.. jetzt sind es plötzlich nur Vermutungen.
Darauf bezog ich mich. Und da ging es ja eben nicht um das Thema hier aktuell, sondern um rBAR selbst. Und das war und ist eben keine Vermutung

 

[0x8100]

Und eben genau das könnte ja dennoch um ein Vielfaches langsamer sein, also "extremely slow". Das "technically impossible" ist allerdings eine falsche Aussage.

wenn man jetzt den dolphin-code als referenz nimmt, dann sind es 2 vs. 7 instruktionen. zen3 hat bei PEXT 3 takte latenz, mit dem MOV also min. 4 takte. angenommen der workaround braucht vllt. nur 1 takt pro instruktion, dann hätten wir 4 vs. 7 takte latenz. nun muss man noch wissen, wie oft das ganze denn überhaupt vorkommt - von extremely slow würde ich nicht sprechen.

 

[ZeroStrat]

Ich hätte halt gerne mal ein paar Benchmarks, am liebsten mit einer manipulierten PEXT inkl. künstlicher Wartezyklen vs. Standard. Und dann ein paar Games testen. Aber wie soll das gehen?

 

[Teralios]

Was so viel heißen könnte wie geht nicht weil wir es nicht testen wollten.

In dem Fall empfehle ich dir mal Kernel.org sowie auch in einigen Linux-Communitys die Fragen von Entwicklern als auch Anwendern dazu und du wirst da schnell auch die Aussage finden, dass für eine »fehlerfreie« Nutzung die Kette GPU <-> Mainboard <-> CPU <-> Softwarestack durchaus getestet und validiert werden muss um zu sehen, ob es wirklich funktioniert oder ob dir das System - nur mal so als Übertreibung - in Flammen aufgeht. Nein, natürlich ist das schlimmste was dir da passiert, dass das System nicht über den Boot-Screen hinaus kommt - das habe ich bei einem Freund an HU verifiziert - oder im besten Fall sehr instabil läuft.

ein schöne zusammenfassung. und sie sagt, dass es technisch geht, aber nicht unbedingt was bringen muss. und genau das widerspricht dem artikel, der sagt, dass es hardware-technisch mit pre-zen3-cpus nicht geht.

Also direkt vorweg, ich schreibe jetzt nicht, weil ich »Recht« behalten will oder so, ich stime dir an der Stelle auch durchaus zu, möchte da aber für dich eben etwas zu bedenken geben: Kennst du das Sender-Empfänger-Problem? Es gibt da noch ausgefeiltere Modelle, aber genau da könnten wir uns jetzt auch bewegen.

Ich würde zum Beispiel dem Artikel durchaus zustimmen, dass es nicht geht, weil es keinen Nutzen hat. Wie ich ja dargelegt habe, es gibt hier nun drei Optionen. 1. Es läuft und bringt nichts. (Wahrscheinlicher) 2. Es läuft und ist langsamer (Wahrscheinlich), 3. Es läuft, und bringt Leistung. (Halte ich für unwahrscheinlicher bei Spielen, im HPC-Markt kann das ganz anders sein!)

Wenn Option 1. und 2. zutrifft, bin ich durchaus geneigt dem Artikel zuzustimmen, denn wenn es keinen »Nutzen« bringen, dann kann man das durchaus auch als »geht nicht« interpretieren, denn man zieht aus der Hardware keinen Nutzen.

Ich kann aber in dem Fall halt auch deine Argumentation durchaus nachvollziehen und auch der zustimmen. Weil es funktioniert ja.

Aber da kommt halt: Funktioniert es dann in »Hardware«, wenn man es per »Software-Algorithmus nachbildet oder es als »Mikrocode« nachbildet.

Wir können hier also durchaus darüber sprechen, ob die Formulierung so glücklich gewählt ist, aber hier kann man schon verschiedene Standpunkte einnehmen.

 

[TxKreator]

Und das war und ist eben keine Vermutung

Das bis jetzt sind die Fakten! Ab hier wiederum bewegen wir uns durchaus in den Vermutungen und bilden aus den Fakten als auch unserem Wissen Indizien und jetzt bitte beachten: Keiner von uns, weder @ZeroStrat noch @foo_1337 als auch haben bisher gesagt, dass es wirklich so ist, sondern dass es eine Theorie ist und in der Wissenschaft ist es erlaubt eine Theorie auf Fakten sowie auch Vermutungen aufzubauen, sofern man es argumentativ verbinden kann!

Und ich bezog mich drauf.

Und ich schrieb auch:

Zugegeben ist es schlüssig, auch nachdem ich mich in das Thema eingearbeitet habe.

Also Ihr feuert immer gleich gegen wenn euch was "nicht passt" das hat @Enurian ja auch schon festgestellt
Versucht mit dem ständigen gegenseitigen Quellen euch die Antworten zurecht zu richten.
Am ende kommt aber immer das gleiche raus.

Und das steht auch schön im Zitat von @Teralios

Was aber ja nicht heißt, dass ihr euch nicht damit beschäftigt und deshalb falsch liegt.
Im gegenteil. Ihr nähert euch ja anscheinend der Lösung.
Und habt am Ende wohl recht.
aber bis jetzt -> Zitat @Teralios

 

[foo_1337]

Ich werde dann zum Test diese 3 Blöcke anpassen:

 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
     avx_op(&XEmitter::VPAND, &XEmitter::PAND, XMM1, R(XMM0), 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);
   }

   if (cpu_info.bFastBMI2)
     {
       MOV(32, R(scratch2), Imm32(0x0F0F0F0F));
       PDEP(32, scratch1, scratch1, R(scratch2));
     }
     else
     {
       MOV(32, R(scratch2), R(scratch1));
       SHL(32, R(scratch1), Imm8(8));
       OR(32, R(scratch1), R(scratch2));
       AND(32, R(scratch1), Imm32(0x00FF00FF));

       MOV(32, R(scratch2), R(scratch1));
       SHL(32, R(scratch1), Imm8(4));
       OR(32, R(scratch1), R(scratch2));
       AND(32, R(scratch1), Imm32(0x0F0F0F0F));
     }

     if (cpu_info.bFastBMI2)
     {
       MOV(32, R(scratch2), Imm32(0xFCFCFCFC));
       PDEP(32, scratch1, scratch1, R(scratch2));
       MOV(32, R(scratch2), R(scratch1));
     }
     else
     {
       LEA(32, scratch2, MScaled(scratch1, SCALE_4, 0));  // ______RR RRRRGGGG GGBBBBBB AAAAAA__
       AND(32, R(scratch2), Imm32(0x00003FFC));           // ________ ________ __BBBBBB AAAAAA__
       SHL(32, R(scratch1), Imm8(6));                     // __RRRRRR GGGGGGBB BBBBAAAA AA______
       AND(32, R(scratch1), Imm32(0x3FFC0000));           // __RRRRRR GGGGGG__ ________ ________
       OR(32, R(scratch1), R(scratch2));                  // __RRRRRR GGGGGG__ __BBBBBB AAAAAA__

       LEA(32, scratch2, MScaled(scratch1, SCALE_4, 0));  // RRRRRRGG GGGG____ BBBBBBAA AAAA____
       AND(32, R(scratch2), Imm32(0xFC00FC00));           // RRRRRR__ ________ BBBBBB__ ________
       AND(32, R(scratch1), Imm32(0x00FC00FC));           // ________ GGGGGG__ ________ AAAAAA__
       OR(32, R(scratch1), R(scratch2));                  // RRRRRR__ GGGGGG__ BBBBBB__ AAAAAA__
       MOV(32, R(scratch2), R(scratch1));
     }

Bin gespannt, was raus kommt. Wenn jemand nen Mac mit Haswell oder neuer hat, kann ich die 2 Binaries auch zur Verfügung stellen.

 

[Teralios]

Und ich bezog mich drauf.

Stopp, ich geh jetzt gleich schlafen, weil es mir zu viel wird, aber da muss ich einhaken, weil du da in meinen Augen ein paar Sachen durcheinander bringst.

Das SAM = rBAR ist, das ist quasi bestätigt durch einen AMD-Mitarbeiter, dazu gibt es hier im Forum bereits einige Links zu Kommentaren dieses AMD-Linux-Entwicklers, ich habe den Link aber nicht zur Hand, bitte Entschuldige das, aber mich ruft da jetzt auch etwas das Bett.

Wir - nicht nur @foo_1337 oder @ZeroStrat - haben ja hier uns die WhitePapers und Co angesehen und auch in den Quelltexten von Linux gefühlt oder Kommentare von AMD-Entwicklern gesucht und anderen, die damit arbeiten, da gibt es einige mehr. Die Grundfrage war dabei immer: Warum kommt es nur für Zen 3 + 6x00 und welche Gründe könnte es, abseits der absoluten Böswilligkeit von AMD haben und wir haben dann die Aussagen des AMD-Entwicklers genommen, ich hab mich dann mit Funktion von BAR beschäftigt und @foo_1337 dann mit etwas anderem und @ZeroStrat auch und @yummycandy und @Colindo sowie @Kacha. Wir haben dann diese Informationen zusammen getragen und überlegt, was kann sein. Da sind auch ein paar Tests nebenbei gelaufen usw.

Wir sind halt eben Hardware-Freaks, die auch gerne etwas mehr darüber wissen wollen und eben nicht sofort entweder in Jubelschreie verfallen oder direkt die Mistgabeln herausholen, wie es einige hier gemacht haben. Wir haben uns dabei im übrigen auch durchaus in die Wolle bekommen - kannst du nachlesen, wenn du die Zeit hast.

Nur - und genau das ist jetzt der Punkt, warum ich zum Beispiel auch so aggressiv auf Enurian reagiert habe und damit zu diesem Zitat von dir:

Also Ihr feuert immer gleich gegen wenn euch was "nicht passt" das hat @Enurian ja auch schon festgestellt
Versucht mit dem ständigen gegenseitigen Quellen euch die Antworten zurecht zu richten.

Enurian hat von mir, als auch den anderen keine Breitseite abbekommen, weil er uns widerspricht, sondern er hat von uns eine Breitseite abbekommen, weil er (1.) den Artikel als »unseriös« hingestellt hat, (2.) sich direkt im Ton vergriffen hat [Vermutungen irgendwelcher User] und darauf aufbauend mehrfach sogar (3.) sagte, dass es ja alles falsch ist und (4.) von uns Beweise gefordert, ohne dass er uns (5.) argumentativ widerlegt hat.

Ich habe es hier bereits ein paar mal schon geschrieben: Wer von mir mit Samthandschuhen angefasst werden möchte, der sollt selbst auch genau diese Samthandschuhe benutzen. Genau so - bitte schau dir nun die Diskussion von @0x8100 und mir an - habe ich kein Problem auch zusagen, dass ich vielleicht etwas zu schroff war und ich kann auch ebenso mit einem entsprechenden Echo leben.

Für mich am wichtigsten ist bei all dem hier folgendes: Man kann mir gerne schreiben, dass ich Blödsinn schreibe, nur wenn man das macht, dann möchte ich auch gerne Wissen warum es Blödsinn ist, denn nur dann kann ich meinen Fehler finden und verbessern. Genau das hat er aber nicht gemacht, er hat es einfach als »Vermutung« und »unseriös« abgetan und »irgendwelche User« kann man hier durchaus auch als beleidigend empfinden, denn das ist schon eine eher direkte Wortwahl, und da nehme ich mir sehr wohl das Recht heraus auch entsprechend direkt zu antworten.

Und damit für dich zum Abschluss und als klärendes Wort:
SAM = BAR, das ist Fakt.
Alles Weitere, was wir schreiben, sind Theorie, die auf Fakten sowie Indizien aufbauen. Die Indizien sind dabei Erfahrungen sowie Logik-Verknüpfungen und jetzt kommt etwas sehr Wichtiges: Wissen ist etwas Fließendes und von der Zeit abhängig.

Man hat Fakten und Vermutungen zu einem Zeitpunkt X und baut daraus eine Theorie und versucht dann diese Theorie zu überprüfen - @foo_1337 macht das nun gerade, denn ich habe nur einen Zen+ und mein Laptop ist auch zu Alt dafür. Aus diesen Überprüfungen entstehen dann beim Zeitpunkt Y neue Fakten, die zu neuen Vermutungen führen, die dann in einer neuen Theorie enden.

Man darf - wenn man wirklich an Wissen interessiert - niemals stehen bleiben und noch viel wichtiger ist: Man darf niemals annehmen, dass eine Theorie unwiderruflich in Stein gemeißelt ist, denn jeder Tag bringt neue Erkenntnisse und kann eine Theorie, die gestern schlüssig war, morgen schon wieder vollkommen umdrehen.

Der größte Fehler, den viele machen, sobald sie mit der Wissenschaft als auch Wissen zu tun haben ist, dass sie denken, dass Theorien etwas Absolutes sind und immer stimmen müssen, dabei muss eine Theorie eben nicht immer stimmen und eine Theorie kann sich auch anpassen und das gilt selbst für so etwas wie die Physik, schau dir da mal die Diskussion zur Quantentheorie an, oder dunkle Materie und Co.

Und jetzt wünsche ich dir eine gute Nacht, ebenso auch @foo_1337 @ZeroStrat sowie auch dir @0x8100 und ebenso hoffe ich, dass wir morgen dann alle etwas schlauer aufwachen und mehr Wissen haben und vielleicht wissen wir bald mehr können dann sagen: Es stimmt so, wie wir es jetzt sagen oder vielleicht müssen wir es dann auch anpassen.

Nur, wenn ihr denkt, es ist Blödsinn was wir schreiben, dann bitte macht euch die Mühe und erklärt es uns, denn nur so können wir am Ende unsere Theorien überdenken!

 

[0x8100]

@foo_1337 eigentlich brauchst du https://github.com/dolphin-emu/dolp...0f15/Source/Core/Common/x64CPUDetect.cpp#L123 nur auf false setzen, dann ist die zen erkennung ausgeschaltet und es wird immer PEXT/PDEP benutzt. sollte reichen, um den unterschied zwischen per microcode emulierten PEXT/PDEP und workaround zu sehen.

 

[foo_1337]

@0x8100 Ich will ja nicht den Unterschied auf Zen2 zwischen emuliertem Microcode und dem Workaround, sondern ich will auf nem Intel (habe keinen Zen3) den Unterschied zwischen der nativen PDEP/PEXT Variante und dem Workaround messen.

 

[Teralios]

Uns fehlt die Hardware. XD

 

[0x8100]

ok, ich werde mal auf zen2 workaround und natives (emuliertes) PDEP/PEXT vergleichen. mal schauen, ob was zu sehen ist.

 

[TxKreator]

Das SAM = rBAR ist, das ist quasi bestätigt durch einen AMD-Mitarbeiter, dazu gibt es hier im Forum bereits einige Links zu Kommentaren dieses AMD-Linux-Entwicklers.

SAM ist nur der Marketingname für rBAR
( für AMD [+ ggF. HW Feature das nur Zen3 hat
{das ist von mir eben auch nur eine "Vermutung" und baut sogar auf euren gelieferten Fakten und dem Artikel auf. }] [und auch nur auf Windows Basis?] )

D.h. ich habe nicht direkt etwas anderes behauptet, sondern eure Fakten etwas um meine Vermutung erweitert.

Damit ist eben mal SAM != rBAR
ist auch meine Vermutung muss nicht richtig sein!


Und im Ganzen gebe ich dir auch recht, jedoch kann er auch seine Meinung haben und seine Vermutung äußern das das unseriös ist weil es eben von euch kommt und nicht offiziell von AMD.

Was AMD Mitarbeiter in Foren schreiben und somit "privat" äußern ist eben die eine Sache.
(Auch wenn es wie ich schon geschrieben habe nachvollziehbar ist und bei rBAR eben wahr)
Offizielle Dokumentationen von AMD (Die auch dort publiziert werden und nicht irgendwo im Netz gefunden werden) sind eben das was die Leute als Quelle wollen.

Ich hab auch nichts gegen die Leistung von euch gesagt das Ihr das alles zusammengetragen habt und auch alles versucht und testet.
Ich hab im letzten Post schon eure Leistung anerkannt.

Was mir aber sauer aufstößt ist eben das was auch das es bei diesem Artikel eben nur Quellen gibt, die auf euch verweisen, aber keine, die offiziell ist.

Ich bin hier sowieso raus aus der Diskussion, weil es jetzt in Themen geht bei denen ich komplett raus bin.

Ich habe nur, zugegeben frech, gezeigt das :

Die Leute immer runter zu schmettern, dass Sie (überspitzt zitiert) "dumm" sind und keine Ahnung haben und deshalb lieber nichts schreiben sollen, ist eben nicht der Punkt mit dem man sich in seiner Sache in der man sicher ist verteidigt. Das klingt immer nach "Der wo am lautesten schreit hat recht"

 

[0x8100]

ich hoffe, ich habe zu dieser zeit keinen fehler gemacht... dolphin (linux, vega56, b450 + r7 3700x) -> internal resolution 4x, vulkan, speedlimit: unlimited, zelda: twilight princess intro gemessen:

$ dmesg | grep BAR
[    0.614456] pci 0000:0c:00.0: BAR 0: assigned to efifb
[    3.282094] amdgpu 0000:0c:00.0: BAR 2: releasing [mem 0x7ff0000000-0x7ff01fffff 64bit pref]
[    3.282095] amdgpu 0000:0c:00.0: BAR 0: releasing [mem 0x7fe0000000-0x7fefffffff 64bit pref]
[    3.282114] pcieport 0000:0b:00.0: BAR 15: releasing [mem 0x7fe0000000-0x7ff01fffff 64bit pref]
[    3.282115] pcieport 0000:0a:00.0: BAR 15: releasing [mem 0x7fe0000000-0x7ff01fffff 64bit pref]
[    3.282116] pcieport 0000:00:03.1: BAR 15: releasing [mem 0x7fe0000000-0x7ff01fffff 64bit pref]
[    3.282123] pcieport 0000:00:03.1: BAR 15: assigned [mem 0x900000000-0xbffffffff 64bit pref]
[    3.282124] pcieport 0000:0a:00.0: BAR 15: assigned [mem 0x900000000-0xbffffffff 64bit pref]
[    3.282126] pcieport 0000:0b:00.0: BAR 15: assigned [mem 0x900000000-0xbffffffff 64bit pref]
[    3.282128] amdgpu 0000:0c:00.0: BAR 0: assigned [mem 0xa00000000-0xbffffffff 64bit pref]
[    3.282136] amdgpu 0000:0c:00.0: BAR 2: assigned [mem 0x900000000-0x9001fffff 64bit pref]
[    3.282192] [drm] Detected VRAM RAM=8176M, BAR=8192M

render time -> rbar mit workaround/PEXT 7,920/8,579

$ dmesg | grep BAR
[    0.176674] pci 0000:0c:00.0: BAR 0: assigned to efifb
[    2.879852] [drm] Detected VRAM RAM=8176M, BAR=256M

render time -> kein rbar mit workaround/PEXT 7,964/9,155

das war jetzt nur eine messung pro szenario (und damit wenig aussagekräftig), aber scheinbar ist der workaround schneller als PEXT, rbar ist schneller als kein rbar. ich wiederhole das morgen mal mit ein paar mehr messreihen...