Topflappen schrieb:
Der grünen Fraktion traue ich durchaus zu, alles andere als die 3x Serie links liegen zu lassen.
Macht AMD quasi auch nicht anders, nur dass es AMD durch "kleinere" Schritte in der Architektur wesentlich einfacher fällt alte Hardware bei neuen Optimierungen mitzuschleppen.
Topflappen schrieb:
Das läuft treibertechnisch bei denen schon so lange ich denken kann, dass also nur die jeweils aktuellsten Produkte auch den vollen Support bekommen.
Was bei NVIDIA daran liegt, dass NVIDIA wesentlich öfters ihre Architektur stark verändern und nicht nur anpassen.
Die einzigen "GPU"-Kerne, die relativ lange konstant sich ähnlich verhalten haben, waren die 8x00 - GTX 5x0, weil hier nicht die Architektur angepasst wurde, sondern primär um neue Funktionen erweitert wurden.
Seit dem Zeitpunkt baut NVIDIA regelmäßig die Architektur so um, dass Optimierungen für neue Generationen quasi keine Relevanz mehr für die alten Karten haben:
32 Shader pro SM asynchron getaktet => 192 Shader pro SM synchron => 128 Shader Synchron => 64 FP + 64 INT synchron => 64 FP + 64 FP/INT synchron.
Alles benötigt im Treiber vollkommen eigene Optimierungen, weil die Shader alle immer über einen Datenpfad angesprochen werden - SIMD. Erst arbeitet NVIDIA mit 32 Werten pro gesendeten Befehl für die GPU, dann 192, dann 128, dann 64, jetzt wieder "128" aber über zweimal 64.
AMD hat bei GCN sehr lange "64"-Waves genommen. Optimierungen im Treiber, die nur die Verarbeitung der Threads im Treiber für die GPU betroffen haben, konnten so auf allen Karten der GCN-Ära auswirken.
boonstyle schrieb:
Das ist Blödsinn... Das Feature ist Teil der pcie Spezifikation und irgendeiner ist immer der erste der es umsetzt. In diesem Fall haben sowohl amd, Intel und Nvidia das Feature seit Jahren nicht genutzt und es ist absolut verständlich, dass Nvidia und Intel nachziehen, wenn amd vormarschiert.
Na ja, man kann schon sagen, das AMD hier als Erstes dran war, egal ob jetzt Windows oder Linux, denn die ersten rBAR-Diskussionen und Umsetzungen stammen auch im Linux-Kernel von AMD.
Die Option "rBAR" in PCIe beschreibt nämlich erst mal nur, dass man statt 5/6 * 32Bit-BAR eben eine oder zwei 64Bit-BAR zur Verfügung hat.
Es reicht aber nicht, dass PCIe die Möglichkeit der entsprechenden Wortbreite bei der BAR zur Verfügung stellt, das ist EIN Teil der Kette, jedoch nicht die Kette vollständig. Neben der Protokoll-Eigenschaft von PCIe muss die CPU auf der MMIO ein Modus bieten, der neben den bisher üblichen 32Bit - seit PCI [sic!] - BARs auch mit einer 64Bit BAR umgehen kann. Das sind die Hardware-Voraussetzungen.
Dann muss das Betriebssystem aber auch entsprechende Möglichkeiten bieten, den RAM zu verwalten und entsprechend muss das OS um entsprechende Funktionalitäten zubieten und dann muss der Treiber damit auch umgehen können.
Es steckt also etwas mehr dahinter als einfach nur "rBAR kommt vonPCIe".
boonstyle schrieb:
Es scheint tatsächlich abhängig von der Speichergröße zu sein, wobei es vermutlich auch vor all m um die Umsetzung Softwareseitig geht (BIOS/uefi etc.).
Ist es auch, weil die Adressen etwas "komplexer" verarbeitet werden müssen in der CPU, aber auch im OS. Man kann sich ja gerne mal die Speicherverwaltung von Linux ansehen und was da für Anpassunge auch wegen rBAR vorgenommen wurden.
Im Endeffekt ist es auch halt eine Frage der "Läufe". Mit den klassischen BARs, kann man ja auch sehr viel abbilden, braucht halt nur ab einem Zeitpunkt länger, da man die BARs etwas "missbrauchen" muss um zu wissen in welcher Page man ist.
256MiB pro Page => 32 Pages bei 8GiB VRAM. Bei 16 sind es halt schon 64 Pages, die man beachten muss. Bei 4 GB sind es nur 8. Entsprechend profitieren höhere VRAM-Mengen stärker.
boonstyle schrieb:
m Thread auf CB (
www.computerbase.de/2020-12/amd-smart-access-memory-test-radeon-rx-6800 ) fällt auf, dass Karten wie die 6000er mit 16gb deutlich mehr profitieren aber interessanterweise der Videospeicher bei den Karten bei Nutzung von SAM (rebar) auf exakt 16.082 MB beschränkt zu sein scheint.
Nein, letzteres hat nichts mit SAM zu tun, besser nur bedingt: Du hast auf deiner GPU niemals die vollen 4, 6, 8, 10, 11, 12, 16, 20 oder un 24 GiB VRAM, sondern bewegst dich darunter.
Die GPU benötigt ein Teil des RAMs als Verwaltungsspeicher sowie auch zur Bildausgabe. Früher hattest du dafür den RAMDAC, in denen das fertige Bild geschriebe wurde um dann umgewandelt ausgeben zu werden, heute wird das fertige Bild in den VRAM geschrieben, bis es fertig ist und dann ausgeben.
orlof schrieb:
Es ist keine AMD-Idee!!! Was ist daran so schwer zu verstehen?Wieso sollte Nvidia alles raushauen, wenn sie es gar nicht müssen? Als ob die Ingenieure bei Nvidia das Feature nicht kennen würden...
Klar kennen sie es, ändert aber zumindest nichts daran, dass rBAR im Linux-Kernel fast vollständig auf AMD-Entwickler zurückgeht.
Klar, der Modus für 64-Bit-Worte bei der BAR ist in PCIe mit 2.1 und 3.0 implementiert worden, aber erst AMD hat quasi den Nutzen gesehen und deswegen auch in Linux die Implementation vorgenommen. Man kann ja mal die Kernel-Entwicklung nachverfolgen und die initialen Commits kamen von AMD, erst als da sich dann abzeichnet, dass es was bringt, hat NVIDIA als auch Intel sich da ins quasi gemachte Nest gesetzt haben.
orlof schrieb:
Und umgekehrt kann man das auch nicht nachweisen
Tatsache ist, dass es ein PCIe-Feature ist und kein AMD-exlusives Feature.
… und auch wenn PCIe die Möglichkeit bietet, ändert es nichts dran, dass einiges mehr da beachtet werden muss und auch das OS damit umgehen können muss.
Falc410 schrieb:
Dein B350 unterstützt auch kein Zen 3. Der Resizeable BAR Support kam auf den B450 Boards gemeinsam mit der Unterstützung für Zen 3. Dass es eine Hardwarelimitierung gibt weil den Boards irgendein ROM fehlt wie von syfsyn behauptet, halte ich für ein Gerücht
Man muss da immer etwas unterscheiden: Auch wenn PCIe3 die Möglichkeit bietet, müssen halt alle Beteiligten damit umgehen müssen, egal ob Hardware und Software und wenn das BIOS die Möglichkeiten nicht bietet, dann kann man da durchaus auch von einer Hardware-Limiterung sprechen, weil das Board es nicht kann.
Manche von euch stellen sich die Welt im Bereich Software + Hardware viel zu einfach vor.
