News Smart Access Memory: Resizable BAR auf AMD Ryzen Threadripper 3000 nutzbar

Ist ja alles schön und gut,aber wenn ich SAM aktiviere schmiert mein Rechner regelmäßig ab,sprich der Rechner startet im Bios einfach neu.

Habs jetzt wieder deaktiviert und das Problem ist behoben.
 
Bei Intel wird es vermutlich erst mit Chipsätzen ab 4xx kommen, bei AMD bringen das ggf. die Hersteller auch wegen AM4 Support für Zen 3. Aufgrund der ständigen Sockelwechsel bei Intel, gibt es weniger bedarf ältere Boards mit aktuellen Bios Updates zu versorgen.
 
Kurze unwissende Frage bevor ich ein Biosupdate mache.
Bringt es mir mit einem AMD 3990x und einer Nvidia RTX 3090 überhaupt etwas oder betrifft das nur AMD Grafikkarten? Danke!
 
@Benni82 deshalb ist das ganze ja auch noch ein Beta BIOS ;)

Ich warte mit der Aktivierung auch bis es für mein boad eine BIOS Version gibt welche als recommended markiert ist.
 
PS828 schrieb:
@Benni82 deshalb ist das ganze ja auch noch ein Beta BIOS ;)

Ich warte mit der Aktivierung auch bis es für mein boad eine BIOS Version gibt welche als recommended markiert ist.

Für mein Bios ist es doch keine Beta mehr ?!

F31 ist das neueste,glaube f31q war n beta bios
 
  • Gefällt mir
Reaktionen: PS828
@Benni82 dann war ich für dein Board nicht auf dem neusten Stand. ^^ aber gut zu wissen
 
@SV3N kann es vielleicht mit der neuen Konsolengeneration zusammenhängen dass es erst jetzt kommt?
Vermute mal dass AMD im Zuge der neuen Konsolenchip Entwicklung herumexperimentiert hat und auf den Leistungszuwachs gestoßen ist. Vorher hat sich einfach keiner die Mühe gemacht.
 
JJ31 schrieb:
Bringt es mir mit einem AMD 3990x und einer Nvidia RTX 3090 überhaupt etwas oder betrifft das nur AMD Grafikkarten? Danke!

Wenn du diese CPU-/GPU-Kombination tatsächlich zum Spielen benutzt bringt es dir etwas sobald Nvidia Resizable BAR in seinen Treiber integriert hat.

Das soll dem Vernehmen nach im Februar geschehen.

P.S.: Das stand bzw. steht so aber auch im Artikel. ;)

Liebe Grüße
Sven
 
  • Gefällt mir
Reaktionen: JJ31
Dankeschön @SV3N !
Ich benutze die Kombi zum zocken und arbeiten, dann warte ich mal ab bis es relevant ist.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SVΞN
Jakxx schrieb:
Schon lustig wie ein PCIE 3.0 feature, welches bereits seit Jahren verfügbar ist, jetzt plötzlich einen 2. Frühling erlebt und in aller Munde ist.
Ja und nein: Der BAR-Support kommt eigentlich bereits aus dem PCI-Zeitalter. Damals hatte eine BAR aber nur 32Bit abzgl. der Device-ID und ggf. in welcher Page man sich befindet. Daraus resultieren die oft beschriebenen 256 MiB VRAM-Zugriff. In PCIe1 und PCIe2 gab es dann 5 oder 6 * 32Bit BARs, ich hab gerade die genaue Zahl nicht im Kopf.

Mit PCIe2.1 kam dann die Möglichkeit diese 32 Bit BARs in 64 Bit BARs umzumünzen, so dass man statt den 6 * 32 Bit nun eben die 64Bit hat und man inklusive Device-ID auf der BAR nun eben mehr als 256 MiB pro Page abbilden kann.

Das Feature wurde dann 2008 verabschiedet vollständig, wie @SV3N anmerkt und dann mit PCIe3 um 2010 vollständig eingeführt, die Entwicklung um diese 64Bit BARs zu nutzen kam aber erst wesentlich später. In Linux sind die ersten wirklich öffentlichen Bemühungen von rBAR ab ca. 2015 sichtbar.

Das Feature hat eigentlich erst an Relevanz gewonnen, als man eine gewisse Größe beim VRAM überschritten hat, da man vorher ja doch recht überschaubar viele Schritte gebraucht hat.

Basti__1990 schrieb:
Soll das heißen, dass ich womöglich mit meiner RTX 2080 und R7 2700X auch in den Genuss von BAR komme?
Richtig, sollte NVIDIA ihre "VRAM"-Verwaltung im Treiber für rBAR fit machen, kannst du es auch mit einem 2700X verwenden.
Makso schrieb:
Frage mal so in die Runde: Das heißt eigentlich BAR es gibt es schon seit 2008, aber erst 2019 wurde es auf dem Markt gebracht, freigeschaltet? Was ich mich frage nur warum jetzt? Warum nicht schon bei Zen1 bei AMD. Und warum haben Intel und NV es nicht früher gebracht?
Weil 2008 erst die Hardware-Spezifikation umgesetzt wurde. Was viele hier immer noch vergessen: rBAR ist nicht nur eine Sache von PCIe, sondern durchaus auch von der CPU und ebenso dann von der Software und dem Speichermanagement und welchen Weg da die Software wählt.

Im Endeffekt muss man sich das wie eine Kette an "Anforderungen" vorstellen, die alle erfüllen müssen. Die 64Bit-BAR ist ein Puzzelteil, das bereits lange existiert und erst jetzt kann halt auch Windows mit den 64Bit Bars umgehen, weswegen AMD nun auch rBAR im Treiber nutzen kann.

SV3N schrieb:
Resizable BAR wurde als offener Standard gemeinsam mit PCIe 3.0 im Jahr 2008 verabschiedet und um 2010 rum eingeführt.
Man hat 2008 im PCIe-Protokoll die Möglichkeiten geschaffen auch 64Bit BAR zu nutzen, ob die anderen Gegenstellen damit umgehen konnte, ist dann ja wieder ein anderes Ding.

SV3N schrieb:
Weshalb keiner der GPU-Hersteller bislang davon Gebrauch gemahnt hat? Vielleicht hat man den Nutzen erst jetzt fürs Gaming entdeckt?
Wenn selbst in Linux erst 2015 wirklich rBAR in den Kernel langsam Einzug hielt, kann man eher davon ausgehen, dass einfach die Möglichkeiten auf Software/OS-Ebene noch nicht soweit wahren, dass man es nutzten kann.

Erst mit WDDMv2 für Windows 10 wurden die VRAM-Möglichkeiten ausgebaut und erst mit WDDMv2.4 wurden entsprechende "Sicherheitsmöglichkeiten" geschaffen und mit WDDMv2.7 wurde die Möglichkeit der Allokation weitreichend ausgebaut.

nordic_pegasus schrieb:
Resizable Bar ist kein PCIe 3.0 Feature, es ist ein PCIe Feature. Es ist die Umsetzung der "AGP Aperture Size" für den altehrwürdigen AGP-Slot auf PCIe. Damals war es tatsächlich auf 256MB begrenzt, was aber kurz nach der Jahrtausendwende eine durchaus großzügige Menge war. Seither ist die technisch unbegründete Grenze von 256MB einfach immer mitgeschleppt worden.
Nein, nicht richtig!

BAR ist bereits im PCI-Standard definiert: 32 Bit, 4 Bit für Device-ID, 28 Bit für Adressen: 256 MiB. PCIe führte dann die Möglichkeit mehre BARs für das gleiche Device zu nutzen, wodurch man über die BARs auch mehr Speicher ansprechen konnte, aber eben nur in den 256 MiB happen.

Erst PCIe2.1/3.0 führte dann, als Alternative für die x 32Bit-BARs pro PCIe-Device die Möglichkeit ein ein 64Bit-BAR zu nutzen, was dann in Linux als "rBAR" eingeführt wurde.

Was du als AGP-Feature ansprichst, hat dabei nicht soviel mit der BAR-Breite zu tun, denn die BAR dient dem Ansprechen des Device RAMs. AGP-Aperture-Size wiederum kann man eher als Überlaufpuffer verstehen - stark vereinfacht: Mit der Einstellung konnte man angeben, wie viel System-RAM sich der Treiber nehmen darf, wenn der VRAM vollgelaufen ist. Die eigentliche BAR-Breite bei AGP hatte aber auch 32 Bit und der VRAM wurde über diese 32Bit-Wörter angesprochen.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Xul, LukS, konkretor und 5 andere
Man könnte auch sagen, es ist eine schnelle Auslagerungsdatei. Es sollte also auch da was bringen wo kein Gaming statt findet aber der Rechner oft an der Grenze des RAM Arbeitet. Es müsste sich hauptsächlich bei Video schauen bemerkbar machen oder?
 
Bekannt war es den Herstellen ganz sicher. Ich hab die Option in einem knapp 10 Jahre alten dual g34 Opteron Board.
BIOS ist auch schon 8 Jahre alt.

Ist übrigens PCIe 2.0, kann also nicht ein reines PCIe 3.0 Feature sein.

Die Option heißt bei mir "resizeable PCIe BAR" und darunter "expand-above 4gb"
Lässt sich nur zusammen aktivieren.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Volvo480 und konkretor
Benni82 schrieb:
Ist ja alles schön und gut,aber wenn ich SAM aktiviere schmiert mein Rechner regelmäßig ab,sprich der Rechner startet im Bios einfach neu.
Was jetzt? Schmiert ab oder cycled einfach, weil er ggf. kein Bootmedium finden kann? Hast du deine Boot/Windows Disk vorher von MBR in GPT konvertiert?
 
Shoryuken94 schrieb:
für AMD Verhältnisse fix wieder fallen gelassen.

vorallem wenn man bedenkt, dass SP3 kompatibel von naples bis milan ist:

https://www.asrockrack.com/general/productdetail.asp?Model=EPYCD8-2T#CPU

https://www.overclock3d.net/news/cp...s_will_be_socket_compatible_with_zen_2_epyc/1

und der selbe sockel bei threadripper "aus technischen gründen" ab zen2 nicht mehr kompatibel sein soll. das ist nur ne marktsegmentierungsmaßnahme.

da dürfte die presse amd ruhig mal genauer auf die finger schauen - warum gehts mit epyc aber mit threadripper nicht, obwohls die selbe plattform ist?
 
  • Gefällt mir
Reaktionen: Epistolarius und Shoryuken94
foo_1337 schrieb:
Was jetzt? Schmiert ab oder cycled einfach, weil er ggf. kein Bootmedium finden kann? Hast du deine Boot/Windows Disk vorher von MBR in GPT konvertiert?

Er startet während des zockens einfach neu.Was konvertiert habe ich aber nicht.Der große Speicherbereich wurde angezeigt.

Dann muss ich mich darum wohl nochmal kümmern wenn ich Zeit habe....
 
Ne, passt. Ich hatte deine Aussage so verstanden, dass er direkt nach dem Bios screen neu startet, weil du geschrieben hast "im Bios". Wenn du nicht GPT hättest, hätte er gar nicht erst Windows gebooted. Also daran liegt's nicht. Lohnt sich das ganze bei dir mit der 5700XT überhaupt? Aus ähnlichen Gründen wurde unter Linux (Mesa) das ganze auf die RX6x00 eingeschränkt.
 
Maxxx800 schrieb:
Bekannt war es den Herstellen ganz sicher. Ich hab die Option in einem knapp 10 Jahre alten dual g34 Opteron Board.
BIOS ist auch schon 8 Jahre alt.

Ist übrigens PCIe 2.0, kann also nicht ein reines PCIe 3.0 Feature sein.

Die Option heißt bei mir "resizeable PCIe BAR" und darunter "expand-above 4gb"
Lässt sich nur zusammen aktivieren.
Da musst du ein wenig aufpassen, ich habe es ja schon angesprochen: rBAR wurde als Funktion in PCIe2.1 definiert und wurde 2009 dann "öffentlich".

PCIe2.1 beinhaltet dabei viele der Verwaltungsverbesserungen, die auch in PCIe3.0 definiert wurden, man könnte vereinfacht sagen: PCIe2.1 = PCIe2.0 Geschwindigkeit + PCIe3.0 Verwaltungsverbesserungen.

In deinem Fall kommt der Support auch nicht direkt vom Opertron oder dem Sockel G34, sondern in dem Fall vom Chipsatz. Opertrons waren per HyperTransport 3.1 an den Chipsatz angebunden und der stellte dann die PCIe-Lanes zur Verfügung, sofern der dann PCIe2.1 beherrschte, konnte er natürlich auch damit umgehen. In dem Fall muss aber auch das PCIe-Device mit PCIe2.1 umgehen können, steckt man in einen PCIe2.1 Slot Karten die nur PCIe2.0, 1.1 oder 1.0 beherrschen, funktioniert auch rBAR nicht.

Vereinfacht: PCIe1 kann es nicht, PCIe2 kann es vielleicht und erst PCIe3 ist es sicher, dass es rBAR kann.
 
  • Gefällt mir
Reaktionen: Maxxx800 und konkretor
Jakxx schrieb:
Korrekt, sobald NVIDIA einen Treiber veröffentlicht, welcher Resizeable Bar Nutzen kann, und du ein Motherboard hast, welches per BIOS update dieses auch unterstützt.
Sorry ich verfolge das nicht zu 100% :)

hab ne 2070s und einen R5 2600.

allerdings „nur“ einen A320 auf dem Board :)
Ist es realistisch das da was kommt ?

Ich meine..2-5%...kostenlos :)
Ansich rennt die Kiste für das was ich brauche noch ganz gut :)
 
Zurück
Oben