News Smart Access Memory: Hersteller bringen AMD-Feature für Intel-Mainboards

[BxBender]

Call of Duty bringt satte 15%!!!

 

[therealcola]

Schade hab gehofft es bleibt AMD only

 

[Ctrl]

dahinter verbirgt sich im BIOS/UEFI " Above 4G Decoding" und "Re-Size BAR Support" für die PCIe Anbindung an die CPU.. das ist eigentlich kein Feature das AMD erfunden hat.. das war schon 2008 Bestandteil der PCIe 2.0 Spezifikation, scheinbar hat AMD diese Funktionen nur als erster sinnvoll umgesetzt und vermarktet.

 

[borizb]

Und hier sehen wir wunderschön den Unterschied für uns Kunden zwischen dem ekligen proprietären Zugemauer, welches NVidia betreibt und dem offenen Ansatz von Firmen wie AMD und Co...
Jetzt muss es nur auch vom Kunden gewürdigt werden, da hakt es leider allzu oft...

Vorsicht! AMD hat gesagt, dass für SAM eine 6800er Karte und eine 5000er Ryzen CPU + 500er
Serie Motherboard benötigt wird, offensichtlich, weil sie dadurch die Verkäufe für Ihre neue
Hardware ankurbeln wollten. Nur durch Nvidia und Asus wissen wir, dass das so nicht stimmt.

Es geht offensichtlich mit fast jeder aktuellen Hardware und vielleicht auch noch mit älterer.

Und AMD nutzt open source nicht, weil sie nobel und mildtätig sind, sondern weil sie nach Jahren der
Erfolglosigkeit am Markt einfach keine Kohle für R&D haben. Warts mal ab, wenn die sich wie die Mit-
bewerber auch eine Armee an Ingenieuren und Forschern leisten können. Dann ist das ruckzuck vorbei.

 

[Hovac]

Die verspielen ihren Vorteil ? Was ist denn da passiert ?

Das sehe ich nicht so, nur weil Nvidia es nutzen darf/kann heißt es ja nicht das es dort genau so viel bringt.
Eine 6800er kann sicher 4GB schnellen Speicher an die CPU abgeben, eine 3070/80iger dürfte das nicht so eben können, ohne das die Leistung auf der anderen Seite durch den Speichermangel einbricht.

 

[foo_1337]

4GB schnellen Speicher an die CPU abgeben

Lesen, verstehen, posten
Hier wird nichts abgegeben.

 

[Jesterfox]

scheinbar hat AMD diese Funktionen nur als erster sinnvoll umgesetzt und vermarktet.

Jein... das Feature wahr wohl vor allem für den Einsatz im professionellen Server- / Compute-Umfeld gedacht und wurde da auch schob früher von Hardware unterstützt (z.B. Intel Xeon Phi). AMD kam jetzt als erster auf die Idee das für Gaming-GPUs zu verwenden.

 

[Shivalah]

Schade hab gehofft es bleibt AMD only

Ich hoffe, dass das nur ein dummer Witz ist, bei dem ich /r/whoosh/ed wurde. Weil wie beim Dreipunkt-gurt im Auto ist so etwas für alle nützlich. Wenn du so nen BS haben willst, besorg dir ne PlayStation.

Davon abgesehen ist die Chance, dass meine Hardware (i7 6700k+ Hero VIII) dieses upgrade bekommt leider 0. Schade.

 

[nille02]

Und AMD nutzt open source nicht, weil sie nobel und mildtätig sind, sondern weil sie nach Jahren der
Erfolglosigkeit am Markt einfach keine Kohle für R&D haben.

So einfach sollte man es sich da nicht machen. Man hat in den letzten 10 Jahren bei GNU/Linux und AMD gesehen das man da sehr viel Eigenleistung bringen muss. Vieles ist zu Speziell bzw. braucht mehr Insiderwissen als verfügbar ist. AMD hatte ja für diverse Features den ucode (Der Firmware Blob der die Hardware initialisiert) überarbeiten müssen, das hätte die "Community" nicht mal selbst erledigen können.
Dazu kommen noch die Diskussionen bei den Reviews.

FOSS macht erst mal viel Arbeit, der Gain ist eher auf lange Sicht Betrachtet interessant.

 

[xexex]

Eine 6800er kann sicher 4GB schnellen Speicher an die CPU abgeben, eine 3070/80iger dürfte das nicht so eben können,

Es gibt niemand an jemand anders Speicher ab! Nur weil die CPU direkt jede Adresse vom Speicher der GPU ansprechen kann, wird er nicht zum CPU Speicher und ist dort auch nicht reserviert.

Der Unterschied zum bisherigen Verhalten ist eben, dass dieser Speicher direkt adressiert werden kann. Bisher hat die CPU in ein "Speichefenster" geschrieben, dieser wurde dann auf die physikalischen Adressen gemappt und dieser Vorgang hat CPU Ressourcen beansprucht.

 

[foo_1337]

@nille02 Da wäre AMD auch selten blöd gewesen, wenn sie das nicht gemacht hätten. Hat aber nichts mit OSS zu tun. Das ist bei Intel selbstverständlich auch so. Beide haben Interesse daran, dass der Linuxkernel bestmöglich auf Ihren CPUs funktioniert.

 

[nille02]

Eine 6800er kann sicher 4GB schnellen Speicher an die CPU abgeben

Da wird nichts abgegeben. Es geht nur um den Adressraum der hier mehr belegt wird. Man darf nicht vergessen wir haben davon 64bit. Damit kann man 17.179.869.184 GB an RAM Adressieren wenn man es denn voll ausschöpfen könnte. Von der maximalen Menge werden wird dann der GPU Speicher abgezogen, weil man dann halt den GPU Speicher darüber Adressieren kann.

 

[xexex]

Davon abgesehen ist die Chance, dass meine Hardware (i7 6700k+ Hero VIII) dieses upgrade bekommt leider 0. Schade.

Nicht zwingend! Technisch gesehen ist es nur eine Funktion die im UEFI freigeschaltet werden müsste. Es könnte also durchaus möglich sein, dass sich ältere UEFI Versionen patchen lassen, auch wenn den Mainboardherstellern eher wenig dran liegen dürfte, "alte" Boards zu pflegen.

 

[Hovac]

Lesen, verstehen, posten
Hier wird nichts abgegeben.

@xexex

Ich habe es so verstanden, dass von der GPU nicht belegter Speicher vom System genutzt werden kann. Das würde bei ohnehin knappem Speicher aber nur selten der Fall sein und damit wenig bringen.
Ergänzung (Praktisch wie der gemeinsame Arbeitsspeicher der PS5 und XBox)

Der direkte Zugriff, um reine Umwege an/in den Vram zu sparen, wäre natürlich eine andere Geschichte.

 

[Jesterfox]

Schlussendlich ist es eigentlich mit dem VESA 2.0 Standard für SVGA vergleichbar der damals unter DOS den Linear Frame Buffer Access brachte. Damit war auch der zugriff auf den vollen Framebuffer (der damals ja noch nicht so groß war) möglich, anstelle des 16kB 64kB Fensters das VGA vorsah.


PS: wär mal interessant ob die 256MB Beschränkung schon von da kommt oder ob es da noch was dazwischen gab.

 

[xexex]

Ich habe es so verstanden, dass von der GPU nicht belegter Speicher vom System genutzt werden kann.

Das ist so nicht richtig und würde an dieser Stelle auch nichts bringen. Ich habe schon mehrfach den Link hier gepostet, er erklärt alles was man zu diesem Thema wissen muss eigentlich ziemlich genau.
https://www.patreon.com/posts/44371506

Ergänzung (1. Dezember 2020)

PS: wär mal interessant ob die 256MB Beschränkung schon von da kommt oder ob es da noch was dazwischen gab.

Diese Beschränkung ist an sich variabel, ich denke die 256MB sind nur weit verbreitet. Auf diversen Intel Systemen kann man diese Größe auch ändern.
https://www.intel.com/content/www/us/en/support/articles/000028294/graphics.html

 

[nille02]

PS: wär mal interessant ob die 256MB Beschränkung schon von da kommt oder ob es da noch was dazwischen gab.

Wir kommen da aus einer Zeit als man nur 4GB Adressieren konnte. Da konnte man schon einiges mit 256MB anfangen. Der Aufwand war auch noch nicht so groß das ganze zu Managen. Wie lange waren 1GB noch State of the Art?

 

[Jesterfox]

Diese Beschränkung ist an sich variabel, ich denke die 256MB sind nur weit verbreitet.

Ah, ok. Deshalb find ich da auch nirgends ein Limit bei den VESA Spezifikationen. Wobei da auch steht weshalb man auf 256MB geht:

A large IGD Aperture Size is not a good idea 100% of the time, since this will increase BAR space in system address space.

Der Punkt ist aber: das Problem trifft nur auf 32Bit Systeme mit ihrem 4GB Adressraum zu. Auf 64 Bit Systemen hat man genug Adressraum.

 

[xexex]

Der Punkt ist aber: das Problem trifft nur auf 32Bit Systeme mit ihrem 4GB Adressraum zu. Auf 64 Bit Systemen hat man genug Adressraum.

Richtig! Dafür müssen eben alle Treiber und Software mit Above 4GB Decoding umgehen können und man hat es bereits in professionellen Sektor oft vorausgesetzt, zum Beispiel bei der Virtualisierung, aber im Desktop Bereich standardmäßig deaktiviert.

Jetzt wo es von NVidia zum Beispiel gar keine 32bit Treiber mehr gibt, kann man sich dieser Altlast entledigen. AMD war hier etwas mutiger und hat es nun werbewirksam vermarktet. Am Ende profitieren alle davon, egal ob NVidia, AMD oder Intel Hardware zum Einsatz kommt.

 

[Jesterfox]

Im Nachgang wird dann auch klar weshalb ein "resizable" BAR gebraucht/verwendet wird: würde man es fest auf einen gößeren Wert konfigurieren müsste man auch immer den above 4GB decode aktivieren um das ganze in den 64 Bit Adressraum zu legen und würde sich die Abwärtskompatibilität zu 32 Bit Systemen komplett verbauen. Das will man wohl nicht.