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

Wenn ich schon wieder das viele Gemecker und Enttäuschung sehe... Leute irgendwann muss man mal neue Features einführen. Nicht alles kann immer abwärtskompatibel sein, wo sind wir denn hier?
Man könnte solche Spielereien auch garnicht erst entwickeln, aber das wäre dann ja auch rückständig. Ich finde es nett, dass sowas in Zukunft möglich ist mit AMD Hardware.
 
  • Gefällt mir
Reaktionen: therealcola und Mario2002
0x8100 schrieb:
"sam" ist die marketing-bezeichnung für resizeable bar. das ganze wird unter linux seit jahren unterstützt - und damit auf hardware vor zen3. "_pdep_u32" ist keine bedingung für resizeable bar (das feature ist von 2008, da gab es noch kein haswell), aber sicherlich hilfreich, wenn man es performant verwenden will. insofern finde ich den artikel irreführend.
… bitte, BITTE beschäftigt euch mal mit der Thematik, statt ständig mit Halbwissen prahlen zu wollen und damit die Leute aufzuhetzen.

BAR mit 32 Bit wurde mit PCI definiert, wurde nach PCIe1 übernommen und mit PCIe2.1 erweitert, sodass dann pro Device bis zu 6 BARs genutzt werden können oder ein 64 Bit BAR - 2 werden verbunden.

Und ja, Linux unterstützt rBAR seit einigen Jahren … es ist aber erst seit 2017 offiziell im Kernel, wenn man genau ist seit dem 24. Oktover 2017. Natürlich hat da die Entwicklung länger gedauert, aber da schrumpfen die Zeitspanne »seit Jahren« mal recht schnell auf 3 zusammen. Über die ersten Patches hat man 2015 gesprochen.

Jetzt überlegen wir mal, welche CPU als erstes PEXT und PDEP unterstützte und wann diese auf den Markt kam: Haswell, 2013. Und dann überlegen wir mal, wann die großen Xeons mit Haswell in den Markt kamen: 2015.

Kannst du eins und eins zusammenzählen? Jetzt kommt das nächste: Die ersten Karten die mehr als 4GB VRAM hatten, kam als FirePro W9000 auf den Markt (6GB) 2012 auf den Markt von AMD, bei NVIDIA 2011 als Tesla C2070 mit 6 GB, davon aber im ECC-Modus nur 5,25 ansprechbar.

Wie ich mehrfach bereits erklärte, nur weil etwas bereits in PCIe definiert wurde, bedeutet es nicht, dass das die einzige Voraussetzung ist um eine Funktion zu nutzen, sondern es kann auch mehr benötigt werden.
 
  • Gefällt mir
Reaktionen: LukS, Colindo, Tanzmusikus und eine weitere Person
Enurian schrieb:
Schön, dass ihr euch etwas zusammenreimt, was vielleicht sogar stimmt. Es ist halt nur nichts wert, wenn es nicht bewiesen wird. Ansonsten bleibt es eine Theorie und Vermutung, das ist doch exakt worum es geht. Der Beweis wurde nicht erbracht.

Ja, es ist am Ende des Tages erstmal nur eine Theorie. Aus meiner Sicht ist es eine sehr wahrscheinliche Annahme, da die Implementierung von Zen 2 sehr langsam ist.

@Teralios Würde man eigentlich dynamisch auf diese Swizzle Funktion zugreifen oder werden die Adressräume einmal beim Booten statisch gemapped?
 
Zuletzt bearbeitet von einem Moderator:
@ZeroStrat
War das Sarkasmus?^^
Du bist doch gaussmath im PCGH, blöde Frage :)
 
bad_sign schrieb:
Neee, ich bin gerade shocked, dass die Daten so falsch interpretiert werden. Die Leistung skaliert unterhalb des Standardtaktes nahezu linear, was ein 100%iges Indiz dafür ist, dass es limitiert. Das müsste weit vorher schon deutlich abknicken. Dass es nach dem Standardtakt abfällt, könnte auch an Speicherkorrekturmechanismen liegen und dass sogar abfällt letztlich, liegt 100%ig an Speicherkorrekturmechanismen.
 
Zuletzt bearbeitet von einem Moderator:
Teralios schrieb:
… bitte, BITTE beschäftigt euch mal mit der Thematik, statt ständig mit Halbwissen prahlen zu wollen und damit die Leute aufzuhetzen.

BAR mit 32 Bit wurde mit PCI definiert, wurde nach PCIe1 übernommen und mit PCIe2.1 erweitert, sodass dann pro Device bis zu 6 BARs genutzt werden können oder ein 64 Bit BAR - 2 werden verbunden.

Und ja, Linux unterstützt rBAR seit einigen Jahren … es ist aber erst seit 2017 offiziell im Kernel, wenn man genau ist seit dem 24. Oktover 2017. Natürlich hat da die Entwicklung länger gedauert, aber da schrumpfen die Zeitspanne »seit Jahren« mal recht schnell auf 3 zusammen. Über die ersten Patches hat man 2015 gesprochen.

Jetzt überlegen wir mal, welche CPU als erstes PEXT und PDEP unterstützte und wann diese auf den Markt kam: Haswell, 2013. Und dann überlegen wir mal, wann die großen Xeons mit Haswell in den Markt kamen: 2015.

Kannst du eins und eins zusammenzählen? Jetzt kommt das nächste: Die ersten Karten die mehr als 4GB VRAM hatten, kam als FirePro W9000 auf den Markt (6GB) 2012 auf den Markt von AMD, bei NVIDIA 2011 als Tesla C2070 mit 6 GB, davon aber im ECC-Modus nur 5,25 ansprechbar.

Wie ich mehrfach bereits erklärte, nur weil etwas bereits in PCIe definiert wurde, bedeutet es nicht, dass das die einzige Voraussetzung ist um eine Funktion zu nutzen, sondern es kann auch mehr benötigt werden.
komm mal von der aggro-spur runter... nichts was du schreibst widerspricht dem von mir gesagten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Backet
Igor sagt doch selbst, mit seinem 2100 MHz OC, erreicht er nicht mehr Leistung und erst ab 2150MHz gibts Speicherfehler.
 
PS828 schrieb:
Same :D wobei es für mich kein Beinbruch ist^^ die Zuwächse sind nichts was ich in irgendeiner Anwendung merken würde^^
Trotzdem! :D Geht um's Prinzip, ich habe immer noch ein Trauma, nachdem ich ein erst ein Jahr altes Board rausschmeißen musste, nur weil der Zen2 Threadripper damit dann doch nicht kompatibel war.
Wehe das ist beim Zen3 TR auch so. :utrocket:
 
  • Gefällt mir
Reaktionen: PS828
@letsdoscience unwahrscheinlich^^ die neuen CPUs werden auf sTRX4 laufen :D aber aufrüsten werde ich nicht deshalb ^^ 4 Jahre darf die CPU ruhig noch bleiben
 
Ich schau nicht auf sein Gerede, ich schau auf seine Zahlen
Über Standardtakt > keine Skalierung
Von OC Problemen redet er erst ab 2150 MHz
Hätte CB auch so ein großes Problem mit Speicher, müssten ihre Werte ja deutlich negativ sein.

@letsdoscience so wie es aussieht, hilft SAM eher in niedrigen Auflösungen und verbessert die Auslastung. Wobei eine klare Linie sehe ich nicht wirklich^^
 
na dann ist der ball ja jetzt bei intel. erwarte freudig ein entsprechendes microcode/BIOS update meines Z97 boards.
 
Enurian schrieb:
1. Ich habe ein abgeschlossenes Studium in Informatik und mache seit vielen Jahren täglich "Code-Analyse" (lol) bzw. schreibe ihn selber. Dadurch ist man aber nicht zwangsläufig allwissend, insbesondere in Hardwarenähe (und das meine ich auf dich als auch auf mich bezogen).
Ach, dafür dass du angeblich ein Studium hast, produzierst du ziemlich viel pauschales Geblubber in dem du einfach nur pauschal widersprichst, wie es nur Leute tun, die ganz klassisch unter Dunning-Kruger-Effekt fallen, wenn wir denn schon mit irgendwelchen »Laws« um uns werfen wollen.

Alle von uns, egal ob @foo_1337 @Colindo @ZeroStrat sowie ich haben von Anfang an gesagt, dass wir nur eine Vermutung anstellen, die wiederum auf nachweisbaren Sachverhalten basiert. Wir nehmen uns bekannte Fakten und verknüpfen diese zu einer Theorie, die wir sogar vollkommen wissenschaftlich richtig als »Vermutung« deklarieren.

Enurian schrieb:
3. Ich stelle im Gegensatz zu euch keine Behauptungen auf, die ich nicht belegen kann. Ich fordere lediglich dazu auf, Beweise für Dinge zu liefern, die man als Tatsachen hinstellt.
… in der Wissenschaft sind solche »Theorien« (Vermutungen) sehr wohl valide, auch wenn sie auf Indizien aufbaut, sofern man diese korrekt miteinander verknüpft.

Wenn du dieser Theorie nicht zustimmst, dann ist es an dir - wenn wir hier schon von Geltungsbedürfnis sprechen oder von einem »Cunningham's Law« - uns nachzuweisen, dass unsere Theorie falsch ist, in dem du entweder (1.) unsere Indizien entkräftest, (2.) nachweist, dass unsere Logik fehlerhaft ist oder (3.) neue Argumente an bringst.

Wir sind ab den Moment, wenn du unsere Theorie als Falsch hinstellst, NICHT in der Bringschuld von Beweisen - wir haben Indizienbeweise sowie Beweise geliefert, was in der Wissenschaft sehr wohl valide ist - sondern DU musst durch passende Gegenargumente unsere Theorie widerlegen und da reicht es nicht zu sagen, dass etwas nicht stimmt, bis man mit 100 % Sicherheit beweisen kann.

Enurian schrieb:
Sonst geht´s dir gut, ja? Meine Fresse blast ihr euch auf, weil ihr hier irgendwelche .pdfs durchlest und meint was gefunden zu haben. Das wirkt nicht nur arrogant, das ist Geltungsbedürfnis vom Feinsten.
Mir geht es sehr gut, aber ich kann solche Leute wie dich nicht ausstehen, die jedes Mal ohne Argumente meine jemand anderes zu sagen, dass die Person falsch liegt und jegliche Regeln einer wirklich sachlichen Diskussion und Debatte vermissen lassen und denken, dass es ja reicht, dass sie einfach nur Widersprechen, ohne das sie ein Argument anbringen, sondern nur auf einen »ultimativen« Beweis pochen. So etwas ist unhöflich und zeugt von einem ganz miesen Diskussionsstil und ja, da werde ich aggressiv, weil so etwas nicht dazu beiträgt, dass man mehr Wissen erlangt.

Wenn es dir - und jetzt kommen wir zum Geltungsbedürfnis kommen - wirklich darum gehen würde, die richtige Antwort zu bekommen, dann würdest du dir die Mühe machen zu zeigen, warum unsere Theorie falsch ist. Das machst du aber nicht und damit bist du einfach nur ein Troll, der jetzt von mir Ignoriert wird.
 
  • Gefällt mir
Reaktionen: eddi99, LukS, Sweepi und 3 andere
Teralios schrieb:
Alle von uns, egal ob @foo_1337 @Colindo @ZeroStrat sowie ich haben von Anfang an gesagt, dass wir nur eine Vermutung anstellen, die wiederum auf nachweisbaren Sachverhalten basiert. Wir nehmen uns bekannte Fakten und verknüpfen diese zu einer Theorie, die wir sogar vollkommen wissenschaftlich richtig als »Vermutung« deklarieren.
Ach ja? Artikel gelesen?
Das hier gelesen?
foo_1337 schrieb:
Erm... das war keine "Vermutung", sonst hätte ich das nicht geschrieben.
So viel zum "Geblubber".
Teralios schrieb:
Wir sind ab den Moment, wenn du unsere Theorie als Falsch hinstellst, NICHT in der Bringschuld von Beweisen - wir haben Indizienbeweise sowie Beweise geliefert, was in der Wissenschaft sehr wohl valide ist - sondern DU musst durch passende Gegenargumente unsere Theorie widerlegen und da reicht es nicht zu sagen, dass etwas nicht stimmt, bis man mit 100 % Sicherheit beweisen kann.
Ich habe an keiner Stelle geschrieben, dass das falsch ist. Und nein, so funktioniert das nicht. Wenn du etwas nicht belegen kannst, muss nicht plötzlich jemand anderes beweisen dass du Unrecht hast. Wohin sollte das führen?
Natürlich darfst du Theorien aufstellen, das führt wieder zurück zu dem Punkt, dass das in dem Artikel an keiner Stelle deutlich wird. Schon die Überschrift lässt keinen Zweifel daran, dass es sich hier um Fakten handelt.
Du antwortest ja auch nicht auf Fragen, die mich daran zweifeln lassen. Beispiel: Selbst wenn ihr mit allem Recht habt und die Instruktion tatsächlich dort genutzt wird, muss als nächstes bewiesen werden, dass es überhaupt eine relevante Performanceauswirkung hat, ob das nun 6 oder 600 Zyklen dauert. Darauf zielten meine Fragen bezüglich der real world Auswirkungen der entsprechenden BIOS-Option ab.

Nochmal für dich, Thema selektives Lesen: Meine Kritik an dem Artikel ist, dass an keiner Stelle erläutert wird, wie man auf die Idee kommt und wie dieser augenscheinliche Fakt belegt wird, wenn es AMD nicht selbst bestätigt.
Dann kommen unangenehme Leute wie du um die Ecke und motzen jeden an, dem dieser schlechte Journalismus sauer aufstößt. Du bist mir völlig egal. Es geht um CB.
 
  • Gefällt mir
Reaktionen: Iines, Kodak, Colindo und eine weitere Person
Es muss hier überhaupt nichts bewiesen werden. Glaub es, oder lass es. It's as easy as that.
Ich habe Vermutung absichtlich in "" gesetzt, weil es eine Antwort auf jenes von Dir geschriebene war:
Jetzt wird es aber unseriös.
Der Artikel ist geschrieben, als wäre das ein Fakt. Einzige Quelle sind Vermutungen von irgendwelchen Usern.
Das liest sich für mich als unterstellst du jenen Usern, dass sie einfach mal irgendwas ins Blaue vermuten würden. Daher die "" und daher die Distanzierung von Vermutungen "ins Blaue".
 
  • Gefällt mir
Reaktionen: LukS, Colindo und Tanzmusikus
Der Widerstand gegen unsere Theorie ist teils heftig. Die durchdachtestete Begründung, dass wir falsch liegen, ist übrigens Folgende.

Sry AMD will probably actually give you a statement if you haven't been completely clueless and being bigbrain shitting out nonsense because you can't understand it at all.

:D
 
  • Gefällt mir
Reaktionen: Col.Maybourne und foo_1337
Es ist schlechter Journalismus und der Kritik würdig. "It´s as easy as that." 🤦
Und jetzt wird abgewiegelt. Also seid ihr Wichtigtuer, die sich ein paar Gedanken gemacht haben, einverstanden.
So what? Ändert nichts daran, dass das unbestätigt ist.
 
  • Gefällt mir
Reaktionen: elvis2k1
Sind hier für mich alles keine Validen quellen Twitter und Redit und ein paar Leute die möglicherweise eine gewisse Ahnung in der technischen Materie besitzen und eine Vermutung haben aber gesichert ist hier nix und so finde ich es schade das sowas schon zur news wird...
 
@Enurian mir ging es Anfangs vor allem um deine Wortwahl. Wenn du einfach nur gesagt hättest, dass du gerne eine offizielle Bestätigung hättest, hätte ich damit kein Problem gehabt. Nur warum hast du es damit nicht einfach gut sein lassen? Stattdessen reitest du immer weiter darauf ohne jegliche Fakten für oder wider darzulegen.
@elvis2k1 Ja, wenn es nicht auf computer,bild.de steht, glaube ich auch nichts.

Gehen wir doch den Artikel mal durch:

Die Überschrift entspricht der offiziellen AMD Aussage. Weiter dann zu _pdep_u32: "Die Aussage lautet". Es ist also lediglich ein Hinweis auf diese Aussage. Keine Zustimmung oder Ablehnung. Danach wird erörtert, was es mit _pdep_u32 auf sich hat und wie die Implementierung bei Zen2 und Zen3 aussieht, inklusive Quellenangaben. Zum Schluß noch die Lage bei Intel sowie der Hinweis auf Nvidia. Wo ist nun das Problem? Was ist an dem Artikel falsch oder nicht belegt?
 
  • Gefällt mir
Reaktionen: LukS, Colindo und Tanzmusikus
Zurück
Oben