Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSmart Access Memory: Ryzen 3000 und Vorgängern fehlt es an Hardware-Support
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.
Das ist eine sehr esotherische Funktion deren volle Ausnutzung ohnehin nicht einfach ist. Kann schon seit daß in zehn Jahren keine Anwendung ohne SAM oder Raytracing oder SIMD auskommt. Aber in den nächsten funf Jahren kommt man prima ohne beides zurecht. It is about the software, stupid.
Viel interessanter finde ich die wahrscheinliche Implementierung von High-Bandwidth-SRAM-Memory auf kommenden Ryzen-Generationen. Dabei handelt es sich im Prinzip um HBM aber statt DRAM mit SRAM welches als 4th-Level-Cache auf einem gesonderten Die residiert. Gerüchte laufen schon seit Ryzen 1 durch die stillen Kämmerlein und Apple macht ja aktuell mit dem M1 etwas ähnliches, erkauft sich das aber mit einem extrem limitierten Speicherausbau. Mit diesem Trick könnte man den Bandbreitenhunger von Ryzen etwas bändigen ohne daß man zu rarem und teurem Overclocker-RAM greifen muß.
Mit PDEX und PDDP kannst du nun die "64 Bit" in 2 32Bit-Blöcke aufsplitten oder eben diese beiden 32Bit-Blöcke in einen 64 Bit Block wieder kombinieren.
Wenn du eine so komplexe Encodierung verwendest wie in deinem Beispiel, wo du einen 64-bit Wert in zwei neue 32-bit Werte zerlegst, die jeweils die geradzahligen und ungeradzahligen Bits des 64-bit Wertes enthalten, koennen PEXT/PDEP durchaus erhebliche Performance-Vorteile bieten, verglichen mit Alternativen (allerdings nicht Faktor 600 - tatsaechlich ist es nur Faktor 18 (https://en.wikipedia.org/wiki/Bit_manipulation_instruction_set Quelle 12: https://www.agner.org/optimize/instruction_tables.pdf)).
Allerdings gibt es keinen erkennbaren Grund, warum man so eine komplexe Encodierung verwenden sollte: Du kannst naemlich stattdessen auch einen 64-bit Wert einfach in zwei 32-bit Werte zerlegen, wovon sich einer aus den hoeheren 32 bit und der andere aus den niedrigeren 32 bit des 64-bit Wertes ergibt. Denn dann reichen einfache SHL/SHR und AND Operationen aus, und du hast dasselbe Ergebnis und die Performance ist auch dieselbe.
Ergänzung ()
0x8100 schrieb:
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.
Genau!
Sofern ganz bestimmte Encodierungen bzw. Algorithmen verwendet werden, moegen PDEP und PEXT durchaus erhebliche Performance-Verbesserungen bieten - aber damit ist eben noch nicht belegt, dass es nicht auch Alternativen geben kann, die dieselbe, oder zumindest nahezu dieselbe, Performance erreichen koennen.
also mal ehrlich leute, 1.2 prozent auf uhd issn schlechter witz. bei mir bleibt alles, wie es ist. wenn die grafikkarten, so wie star citizen, dann mal erscheinen, hohl ich mir eine. aber kein star citizen, weil es leider nie fertig werden wird.
Allerdings gibt es keinen erkennbaren Grund, warum man so eine komplexe Encodierung verwenden sollte: Du kannst naemlich stattdessen auch einen 64-bit Wert einfach in zwei 32-bit Werte zerlegen, wovon sich einer aus den hoeheren 32 bit und der andere aus den niedrigeren 32 bit des 64-bit Wertes ergibt. Denn dann reichen einfache SHL/SHR und AND Operationen aus, und du hast dasselbe Ergebnis und die Performance ist auch dieselbe.
Bitte bedenke in dem Fall: Die Adressen müssen in dem Fall durch die MMIO. Es ist richtig, man könnte es einfach in 2 32Bit teilen, aber dann kannst du unter umständen die Adressen nicht mehr dem richtigen Device zu ordnen oder bestimmte Adressen verdoppeln sich.
Die Zerlegung in High und Low funktioniert bei Zahlen und Wörtern problemlos, bei Adressen aber nicht.
Ergänzung ()
@0x8100 erst mal danke, sehe ich mir jetzt die zwei Werte die mich interessieren an:
Das RAM Setup an, dann ist für sie Erkennung der PEXT emuliert langsamer als der klassische Weg. 3,3 gegen 2,9. Also ca. 10%.
Die Renderzeit finde ich da interessanter, aber 7,92 gegen 7,96 ist jetzt unter einem Prozent, die 8,56 gegen 9,16 sind da mit 10% dann schon wieder interessanter.
Dass lässt durchaus die Frage zu, warum AMD SAM nicht auf Zen 2 zulässt, da es ja durchaus was bringen kann. Zumindest bei einer Emulation. Man müsste das jetzt echt mal auch mit anderen Spielen testen und ob da eventuell doch Spiele gibt, die drauf negativ reagieren könnten.
Muss ich doch eventuell mal die Tage Linux aufsetzen.
Im AC Valhalla Benchmark hat man selbst mit der RTX 3090 und Highend CPU Frameeinbrüche (4k Ultra Details) abhilfe schafft hier nur die Reduzieren der Texturendetails auf mittel bei den Charakterdetails. Entweder ein Problem der Engine, dass nicht genug Textureren voher in den VRAM geladen werden oder vielleicht auch ein Engpass bei der Speicher/CPU Leistung. Naja, mal sehen wie das mit der nächsten oder übernachsten Gen (2022) wird, die auf DDR-5 Speicher setzt. Diese ruckler erinnern mich an Fallout 4, wo das Upgrade vom DDR 3/4970k auf DDR 4 / 9900k ebenfalls die Lösung war.
Da ich eh keine RX 6xxx habe, juckts micht nicht sonderlich, wenn wieder verfügbar gibt's vielleicht im nächsten Jahr ein SAM Hardwarepaket aus 5800X und RX 6/7xxxx....Und das auch nur vielleicht.
Ergänzung ()
Benni82 schrieb:
Kommt mir jetzt so vor als wäre mein 3700X Oldschool
Quatsch,lass dir das bloss nicht einreden. Solange die Leistung reicht ist doch alles gut, den Neuen Kram kriegst du eh erst wahrscheinlich wieder im Frühling zu normale Preisen, also locker bleiben!
Da ich eh keine RX 6xxx habe, juckts micht nicht sonderlich, wenn wieder verfügbar gibt's vielleicht im nächsten Jahr ein SAM Hardwarepaket aus 5800X und RX 6/7xxxx....Und das auch nur vielleicht.
Ergänzung ()
Quatsch,lass dir das bloss nicht einreden. Solange die Leistung reicht ist doch alles gut, den Neuen Kram kriegst du eh erst wahrscheinlich wieder im Frühling zu normale Preisen, also locker bleiben!
Es ist richtig, man könnte es einfach in 2 32Bit teilen, aber dann kannst du unter umständen die Adressen nicht mehr dem richtigen Device zu ordnen oder bestimmte Adressen verdoppeln sich.
Nein, das ist so nicht korrekt. Auf 64-bit Systemen hast du 64-bit Adressen, und somit gibt es auch keine doppelten Adressen, weil genuegend Adressraum fuer jedes Device vorhanden ist. Somit existiert auch keine Motivation, ein komplexes Encodierungs-Schema zu verwenden.
@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.
Die Neuen AMD GPU könnnen RT ein bischen ABER im Vergleich zur RTX ab 3700 eben nicht gut.
Da nutzen auch 16GB Vram nix.
Ich Spiele in 2560x1080 somit wurden 10GB Vram wohl reichen
ABER
meine 1080TI hat schon 11GBVram. Irgentwie ein Rückschritt.
Wie ich schon gesagt
Wer kein RT will kann AMD nehmen.
Da ich aber Gsync im Montor habe und kein Freesync und RT benutzen möchte kommt AMD eben nicht in die Auswahl.
Hinzu kommt das ich jetzt keine GPU kaufen würde die RT nicht gut kann.
Wenn AMD sagen würde 450€ weil die RT Leistung eben schlechter ist wär es OK.
Aber die GPU kosten im Prinzip das gleiche und dann würde ich ne RTX nehmen.
WENN ES DENN ÜBERHAUPT HIGH END GPUS GEBEN WÜRDE DIE KEIN MONATSEGEHALT KOSTEN !!!
Dir ist aber schon klar, dass in einem Spiel (war es CoD?) die AMD-Karten schneller als die RTX waren? PCGH hatte dazu, glaube ich, auch einen Test. Das hängt zurzeit deutlich vom Spiel ab, und kann damit zukünftig von Treiberverbesserungen oder Spielepatches profitieren.
Bei Horizon:ZD war die Vega im Launchtest ja auch furchtbar langsam und wurde nach einem Patch plötzlich wieder so schnell wie gewohnt. Da kann immer viel passieren, wenn etwas neu ist.
ich habe das ganze jetzt jeweils 10mal ausgeführt (und nach 40 zelda intros kann ich das erstmal nicht mehr sehen ):
render time
rBAR
no rBAR
PEXT
8.65
9.031
workaround
7.36
7.382
wie schon bei der einzelmessung ist rbar mit dem workaround am schnellsten. leider kann ich mangels intel oder zen3 prozessor nicht sagen, wie gross der unterschied ziwschen einem nativen pext und dem workaround ist, man sieht also erstmal nur, dass das emulierte pext auf cpus vor zen3 wirklich langsamer ist. allerdings sieht man auch, dass trotz dessen rbar hilfreich ist.
Nein, das ist so nicht korrekt. Auf 64-bit Systemen hast du 64-bit Adressen, und somit gibt es auch keine doppelten Adressen, weil genuegend Adressraum fuer jedes Device vorhanden ist. Somit existiert auch keine Motivation, ein komplexes Encodierungs-Schema zu verwenden.
… doch, dass was ich schreibe ist korrekt und wir haben sogar bereits hier nun gezeigt, dass das PCI-Subsystem von Linux in dieser Art arbeitet - natürlich ausgefeilter. Siehe Linux-Quelltext.
Und dann solltest du dich mal bitte damit beschäftigen, wie der Adressraum des PCIe-Device in den Adressraum der CPU eingebunden wird und wie das aufgebaut ist. Ich wiederhole mich: MMIO. Und diese MMIO hat nur 32 Bit und diese 32 Bit stehen noch nicht mal vollständig zur Verfügung, da hier über ein Indikator noch die richtigen Devices markiert werden müssen.
Die BAR von PCI spricht 64Bit, die MMIO die diese BAR einbindet, nur 32 Bit, was dann wieder in die 64 Bit der CPU abgebildet wird.
Der paart MMIO 32 Bit Adressraum <-> CPU 64 Bit Adressraum ist dabei auch nicht das Problem. Das Problem ist, dass die 64 Bit der BAR in die 32 Bit der MMIO abgebildet werden muss und DAS ist nicht mit einem einfachen High- und Low-Wort Teilung getan.
Um dir das Problem zu verdeutlichen einmal mit 8 Bit:
8 Bit Wort - Adresse
High 4Bit
Low 4Bit
0100 1111
0100
1111
1000 1111
1000
1111
Bei einer Zahl oder einem Wort funktioniert dass ohne Probleme. Jetzt kommen wir aber zu einer 4 Bit MMIO, die entsprechend 2 Geräte anspricht. Damit man weiß, um welches Gerät es sich handelt benötigen wir einen Indikator im Wort, bei 4 Bit bietet sich nun das vierte Bit an. Die Adressen sehen in dem Fall dann so aus: dAAA. d ist dabei das Bit fü das Device, AAA sind die Bits die für Adressen zur Verfügung stehen:
8 Bit BAR
4 Bit MMIO (low)
4 Bit (High)
BAR Device ID
MMIO Device ID (Low)
MMIO Device ID (High)
MMIO <-> BAR
1000 1111
1111
1000
1
1
1
1 -> beide Adressen erkannt
0100 1111
1111
0100
0
1
0
1 & 0:
Low gehört zu BAR 1,
High gehört zu BAR 0.
PCI sowie die MMIO nutzen ein Teil ihrer Bits als Präfix um zu wissen um welches Gerät es geht. Zerteilt man die 64 Bit des BARs einfach in 2 * 32 Bit, geht genau diese Zuordnung jedoch verloren und das ist bei Adressen der absolute Worstcase, weil man nicht mehr weiß, wo man etwas schreibt oder liest.
Es hat also ein Grund, warum man im PCI-Subsysytem von Linux eben nicht mit einfacher Trennung des BAR-Wortes arbeitet, sondern es über eine Maske teilt.
Wir haben mit dem Workaround mit »rBAR« einmal 7,36 und ohne rBAR (also 16Bit für Adresse) 7,38? Das wären dann 0,2 % Unterschied, das deckt sich ja mit meiner ersten Theorie, dass »rBAR« nichts bringen würde.
Die Testreihe mit PEXT wiederum finde ich dann wesentlich interessanter, weil wir hier sehen, dass rBAR durchaus was bringt - 4 % - gleichzeitig zeigt deine Testreihe aber auch, dass meine Theorie »rBAR« könnte unter Zen 2 Leistung kosten - auch stimmen kann, denn 16Bit-BAR gegen 64Bit-Bar sind hier 7,38 gegen 8,65 und damit benötigt die rBAR hier ganze 17 % mehr Zeit.
Was wir aber jetzt wissen ist, dass der Mikrocode Workaround deutlich schlechter ist als der Software-Workaround und damit haben wir nun PEXT? > Workaround > Sim PEXT.
Beziehe ich das jetzt alles ins Wissen ein, muss ich sagen: rBAR würde auf Zen2 und davor - dank Workaround - laufen, aber es würde halt, wie erwartet, nichts bringen. Und dass AMD dann es nicht für Zen 2 freischaltet, ist zwar dann durchaus ärgerlich, aber auch verständlich, da der Nutzen nicht gegeben ist.
@ZeroStrat das betrifft nur die code-teile, die @foo_1337 händisch anfassen wollte:
Code:
$ grep -R bFastBMI2 Source
Source/Core/Core/PowerPC/Jit64Common/Jit64AsmCommon.cpp: if (cpu_info.bFastBMI2)
Source/Core/VideoCommon/VertexLoaderX64.cpp: if (cpu_info.bBMI1 && cpu_info.bFastBMI2)
Source/Core/VideoCommon/VertexLoaderX64.cpp: if (cpu_info.bFastBMI2)
Source/Core/VideoCommon/VertexLoaderX64.cpp: if (cpu_info.bFastBMI2)
Source/Core/Common/x64CPUDetect.cpp: bFastBMI2 = bBMI2 && !bZen1p2;
Source/Core/Common/CPUDetect.h: bool bFastBMI2 = false;
@Teralios ja, zumindest in diesem isolierten beispiel (k.a. wie repräsentativ die wii-emulation in dolphin jetzt in bezug auf andere software/aktuelle spiele ist) sehen wir, dass es keinen unterschied zwischen aktivierten und deaktivierten rbar gibt - wenn der programmierer weiss, was er tut und den assembler-code händisch optimiert hat. hoffen wir mal, dass alle das auch machen wenn das nicht gemacht wird, ist der unterschied beim rbar und pext schon grösser. was ich leider nicht zeigen kann, ist, wie ein natives pext bei rbar on/off aussieht...
Japp und in der Anfanszeit der Computer war es furchtbar langsam, wenn man einen größeren Adressraum in einen kleineren Abbilden wollte. Hab vor kurzem mal ne Doku gelesen dazu, dass man dann auf einem PC statt eben den 64kB dann 128kB hatte, aber die ersten 48kB für zeitkritische Systeme da war, während halt der Rest schneller war als das Band, aber eben um den Faktor 5 oder 6 langsamer als die ersten 48kB.
Ergänzung ()
@0x8100
das mit dem Assembler und optimierten Code. Aber ich genieß jetzt das Wochenende. Danke für deine Fakten.
Dir ist aber schon klar, dass in einem Spiel (war es CoD?) die AMD-Karten schneller als die RTX waren? PCGH hatte dazu, glaube ich, auch einen Test. Das hängt zurzeit deutlich vom Spiel ab, und kann damit zukünftig von Treiberverbesserungen oder Spielepatches profitieren.
Bei Horizon:ZD war die Vega im Launchtest ja auch furchtbar langsam und wurde nach einem Patch plötzlich wieder so schnell wie gewohnt. Da kann immer viel passieren, wenn etwas neu ist.
und dir ist schon klar das ich von der RT Leistung rede !
Für normales Gaming ist auch meine 1080TI mehr als schnell genung.
Nur fürs Spielen in 2560x1080 brauche ich keine RTX 3080 oder AMD 6800XT
ABER
Ich möchte RT nutzen grade wegen Cyberpunk.
Deshalb rüste ich auf oder will aufrüsten.
Nur deshalb !!!
Auch meine 1080TI kann RT per Software . Da aber die Hardware es nicht kann ist es Sinnlos.
SAM bringt bei RT nix wenn die GPU RT nicht kann.
Und das ist schein ein Hardware problem zu sein und kein Treiber Problem.
Was aktuell bei den RT-Test vieler Seiten vergessen wird, ist der Punkt, dass RT bisher ausschließlich auf RTX programmiert wurde und daher auch dafür optimiert ist - NVIDIA hat es ja oft direkt implementiert.
Erst jetzt mit der RX 6x00 kann man auch die Arbeitsweise von AMD hin optimieren und wenn man das macht, ist eben die Leistung nicht viel schlechter als von Ampere.
Daraus kann man Schlussfolgern, dass RDNA2 keine RT Schwäche pauschal hat, sondern dass die bis jetzt entwickelten Spiele RDNA2 einfach nicht liegen.
Oh je, da hab' ich ja was los getreten
Aber nach Recherche ist das die einzige Gemeinsamkeit zw. Zen 3 und Intel, die Zen/+/2 nicht haben. Und die eben für gewisse Featues wie Standard Swizzle siginfikante boosts bringt.
Danke @MichaG für die weitere Elaborierung.
):
wenn das nicht gemacht wird, ist der unterschied beim rbar und pext schon grösser. was ich leider nicht zeigen kann, ist, wie ein natives pext bei rbar on/off aussieht...
